From owner-ipsec Sun Jun 1 16:53:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA03123 for ipsec-outgoing; Sun, 1 Jun 1997 16:50:06 -0400 (EDT) To: ipsec@ex.tis.com Path: not-for-mail From: daw@cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: New draft -- IPSEC AH Date: 1 Jun 1997 13:57:31 -0700 Organization: ISAAC Group, UC Berkeley Lines: 26 Message-ID: <5msnnr$6ko@joseph.cs.berkeley.edu> References: <199705302208.SAA15535@relay.hq.tis.com> <3.0.1.32.19970531092527.009531bc@ranier.altavista-software.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk In article <3.0.1.32.19970531092527.009531bc@ranier.altavista-software.com>, Matt Thomas wrote: > I think that we need to exclude (e.g. treat as zero) the flow-label and > priority/reserved bits as well, especially if they are allowed to be > changed inflight. How do QOS types feel about this? Are they relying on AH to authenticate packets and priority/flow fields for QOS control? > [Since the version field is constant I'd exclude that > as well so the first 32 bits of the IPv6 header are treated as zeroes.] Sounds dangerous to me. What protection is there against attacks that try to transmute AH'ed IPv4 datagrams into AH'ed IPv6 datagrams with different semantic meaning? (And even if there is some protection I'm overlooking, I think it's good to include the version field-- robustness.) Personally, I think the version field should be included. Moreover, I think the the IPv4 offset field should be included, too. In the latest draft, the MAC does not protect the offset field. Yes, I know receivers MUST discard AH packets with offset > 0. But this is a robustness / engineering concern. (There's no additional cost in MACing the offset + version, too -- once you've decided to incur the cost of MACing some header fields, you might as well MAC offset + version too.) From owner-ipsec Mon Jun 2 09:53:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA08249 for ipsec-outgoing; Mon, 2 Jun 1997 09:48:37 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.1.32.19970530194658.006affe8@pop3.pn.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 2 Jun 1997 09:38:03 -0400 To: Rodney Thayer From: Stephen Kent Subject: Re: new AH and ESP specs Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Rodney, I am the author for the documents. Karen Seo, who works with me here at BBN, has been responsible for consistiency checking (e.g., she noted that the AH length text was no longer correct now that the Sequence Number field is mandatory), checking the documents to make sure I've responded to the changes called for in previous WG messages, proof reading, and NROFF production (since I'm a MAC kind'a guy!). Charlie Lynn, also of BBN, has contributed text on the positioning of AH relative to IPv6 headers, as he has been involved with that work. Karen, with some help from Charile, has been working on the architecture document to develop the background analysis for different sections, e.g. the PMTU discussion that was posted a few weeks ago. Steve From owner-ipsec Mon Jun 2 09:53:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA08248 for ipsec-outgoing; Mon, 2 Jun 1997 09:48:36 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.32.19970530173507.00b4ee70@earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 2 Jun 1997 09:41:02 -0400 To: Bob Monsour From: Stephen Kent Subject: Re: another padding question ... Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bob, I'm happy to put back the previous padding description, describing it as the default, but that algorithms may define other padding schemes. I thought of doing that, but didn't. Steve From owner-ipsec Mon Jun 2 17:42:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA11570 for ipsec-outgoing; Mon, 2 Jun 1997 17:37:12 -0400 (EDT) Date: Mon, 2 Jun 97 14:39:48 PDT From: marc@mentat.com (Marc Hasson) Message-Id: <9706022139.AA02322@mentat.com> To: ipsec@tis.com Subject: Re: New draft -- IPSEC AH Sender: owner-ipsec@ex.tis.com Precedence: bulk I don't see any substantive problems but here are a couple of "nits" that I see as interoperability (or understanding) issues. On this: > > 2.2 Payload Length > > This 8-bit field specifies the length of AH, in 32-bit words (4-byte > units), minus "2," i.e., the fixed portion (as defined in the > original AH spec) of AH is not counted. (Since the Sequence Number > field is always present, the fixed portion of AH is now three 32-bit > words. However, the "minus 2" length adjustment has been retained > for backwards compatibility.) A "null" authentication algorithm may > be used only for debugging purposes. Its use would result in a "0" > value for this field, as there would be no corresponding > Authentication Data field. Two points on the above. What is the "backwards compatibility" issue here, can that be elaborated on at least by E-mail? Is there code out there based on the old RFC thats just looking to skip over the AH and can otherwise still function even though it no longer understands this header format? We have a legacy of firewalls, for example, that will let AH go by but may wish to filter other things later on in the packet? If this is the understanding then I guess that text there is fine... The other point is that if the length field should be "# 32-bit words minus 2" then I don't understand how the last sentence gets a result of "0" for the null authentication algorithm example. Shouldn't it be "1" since the fixed portion of AH is now 3 32-bit words? And in the more "standard" case of a 96-bit authentication value plus the 3 32-bit fixed portion the length field will be "4", correct? (Perhaps this is the problem Steve Kent's E-mail this morning was referring to when he mentioned that Karen Seo spotted a problem, my apologies for elaborating on this if thats so. I couldn't tell whether she did that in the past or against this latest draft which seems to have it incorrect.) A second issue: > > 2.5 Sequence Number > > This unsigned 32-bit field contains a monotonically increasing > counter value (sequence number). The counter is initialized to 1 > when an SA is established. The sequence number must never be allowed > to cycle; thus, it MUST be reset (by establishing a new SA and thus a > new key) prior to the transmission of 2^32-1 packets on an SA. > . . . > 3.2.2 Sequence Number Generation > > The transmitter increments the Sequence Number for this SA, checks to > ensure that the counter has not cycled, and inserts the new value > into the Sequence Number Field. A transmitter 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. Minor inconsistency or missed update in the above sections. As exchanged in E-mail between Adams and Kent (4/3 & 4/5/97) there is still the appearance that the first sequence number on the wire is 2, not 1. If section 2.5 (this *sounds* like the sender's version of the SA) would initialize its counter to 0, not 1, then 3.2.2 will "send" sequence #1 for the first packet. The 2^32-1 is then 2^32 in section 2.5, 2^32-1 packets may be transmitted successfully before cycling the numbers. My only concern is that I don't want receivers to be built that always drop the first packet of the SA (3.3.3 is a little vague about what the lowest valid sequence number is at SA startup that can be received, even though its receive counter is initialized to zero). SA startup can be slow enough without this additional packet loss. Thanks. -- Marc -- From owner-ipsec Tue Jun 3 00:40:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA13500 for ipsec-outgoing; Tue, 3 Jun 1997 00:39:23 -0400 (EDT) Hops: 0 Host: clinet.fi. Posted-Date: Tue, 3 Jun 1997 07:44:12 -0200 (GMT) Message-Id: <199706030445.HAA06331@del.tla.org> X-Mailer: exmh version 1.6.2 7/18/95 To: linux-ipsec@clinet.fi Cc: ipsec@tis.com Subject: Release 0.5 of JI's IPSEC implementation for Linux Reply-To: ji@hol.gr Organization: La maison qui rend fou. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Jun 1997 07:45:50 +0300 From: John Ioannidis Sender: owner-ipsec@ex.tis.com Precedence: bulk 0.5 is finally available. The new, long-awaited feature is transport mode. Look for it in ftp://ftp.funet.fi/pub/unix/security/net/ip/ in a few hours. If you can't wait to get your hands on it, look in http://prometheus.hol.gr/ipsec/ . In those directories you can also find Angelos Keromytis' ISAKMP implementation. There is also a totally unsupported IPSEC implementation for various BSD derivatives, written by the two of us. /ji PS: I would like to take this opportunity to express my disappointment at the vanishingly small number of comments I have received. I wonder if it is because the code works perfectly, or because nobody is interested in it. From owner-ipsec Tue Jun 3 07:55:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA16007 for ipsec-outgoing; Tue, 3 Jun 1997 07:52:25 -0400 (EDT) Message-Id: <3.0.32.19970602231250.00b27100@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 02 Jun 1997 23:12:53 -0700 To: Karen Seo From: Bob Monsour Subject: Re: New draft -- IPSEC ESP Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Nice work on the ESP doc. I have a few small comments questions. -Bob >2.3 Payload Data [snip...] > > If the algorithm used to encrypt > the payload requires cryptographic synchronization data, e.g., an IV, > then this data MAY be carried explicitly in the Payload field. Any > encryption algorithm that requires such explicit, per-packet > synchronization data MUST indicate the length and any structure for > such data, as part of an RFC specifying how the algorithm is used > with ESP. If such synchronization data is implicit, the algorithm > for deriving the data MUST be part of the RFC. Does this imply that the alg-specific per-packet sync data will be located at the start of the payload, immediately following the Sequence Number field? It's not clear, and I don't know if it should be a requirement or not. If it is intended to imply that it has to be located at the beginning of the payload, then that should be made explicit (not that I can imagine where else it would be located at the moment). > 3.1 ESP Header Location > [snip...] > AFTER APPLYING ESP > --------------------------------------------------------- > IPv6 | orig |hxh,rtg,frag|dest|ESP|dest| | | ESP | ESP| > |IP hdr|if present**|opt*|Hdr|opt*|TCP|Data|Trailer|Auth| > --------------------------------------------------------- > |<---- encrypted ---->| > |<---- authenticated ---->| > > * = if present, could be before AH, after AH, or both ^^ ^^ Shouldn't these be "ESP"? >3.2.5 Fragmentation > > If necessary, fragmentation is performed after ESP processing within > an IPsec implementation. Thus, transport mode ESP is applied only to > whole IP datagrams (not to IP fragments). An IP packet to which ESP > has been applied may itself be fragmented by routers en route, and > such fragments must be reassembled prior to AH processing at a ^^ Shouldn't this be "ESP" too? Lastly, when can we expect a revised Security Architecture document. There are a couple of references to it in the ESP doc where the referenced info would be of great help. From owner-ipsec Tue Jun 3 08:00:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA16109 for ipsec-outgoing; Tue, 3 Jun 1997 08:00:01 -0400 (EDT) Date: Tue, 3 Jun 97 11:49:32 GMT From: "William Allen Simpson" Message-ID: <5994.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: Perplexed by padding values (was "padding values") Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Bob Monsour > For those of us trying to implement somewhat flexible hardware to support a > variety of security protocols, including padding options/modes, this kind > of tweak matters. I propose that we do as DESE does and start with a value > of '1' unless there is a compelling security argument to be made. > A very important point. I had not considered that folks would want to do the padding computation in hardware. The PPP Self-Describing-Pad starts at 1 because it has no trailing pad-length field. The internal values need to be interpretable in the presence of variable trailing checksums in the framing. Also, we went to great lengths to avoid adding an additional block in as many cases as possible, by excluding blocks ending in zero or a value > 8. So, PPP values are optimal and cannot be changed. I will make the change in my IPSec drafts. Thanks. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Tue Jun 3 08:00:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA16108 for ipsec-outgoing; Tue, 3 Jun 1997 07:59:59 -0400 (EDT) Date: Tue, 3 Jun 97 11:12:12 GMT From: "William Allen Simpson" Message-ID: <5993.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: eliminate AH -- unanimous Sender: owner-ipsec@ex.tis.com Precedence: bulk Ahh, and it's messages like these that remind me what a true joy it has been to discuss things with the cryptologic community. If you bring two of them together, you get 4 opinions; 3 of them yield 9, etc. In this case, we cannot even get a consistent conclusion from the same person in different weeks.... > From: Steven Bellovin > Ever since Bill posted his straw poll, I've been bothered by an > intuitive feeling that AH and encryptionless ESP were not equivalent. Reminding you that the straw poll was posted in response to your message: Date: Wed, 21 May 1997 11:51:34 -0400 From: Steven Bellovin ... *) I don't like meaningless cryptography. Almost two years ago, I posted a field-by-field analysis. I showed that the IP header fields are either irrelevant for security purposes, changed en route (and hence not protectable), or are or should be bound to the security association, and hence need not be authenticated on a per-packet basis. ... The only reason we're discussing this again is because we realized that encryption almost always requires authentication. This may not be sufficient reason to reopen the question, especially given the immediately preceeding point. But yes, in an ideal world I'd opt for a clean AH, aka encryptionless ESP. > This afternoon, I finally realized the crucial difference: AH can be > deleted or ignored in a context-independent way. > ... This can't be done with ESP > without knowledge of the security association. > > Now -- whether or not we want to enable any of these abilities is a > separate issue. But the distinction does exist. > I conclude that the analysts have a wonderful time enumerating all the possibilities, but are unable to make any final recommendations as to the engineering choices we need to make. I personally will have a very difficult time supporting any such future recommendation, knowing that 9 days later the same analyst will come back and undermine his own position. So much for a consensus building exercise ... what a waste of time, in this group. Keep AH, and impose an outright ban on encryptionless ESP. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Tue Jun 3 10:41:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA17544 for ipsec-outgoing; Tue, 3 Jun 1997 10:36:53 -0400 (EDT) Message-ID: <01BC6FF1.8A81DFE0@TASTID1> From: Rob Adams To: "ipsec@tis.com" Subject: RE: eliminate AH -- unanimous Date: Tue, 3 Jun 1997 07:40:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk One could also make the argument that we keep bringing back issues that we've discussed over and over like eliminating AH. This isn't the first time this has come up. We still have it, now all of a sudden, it is unanimous to get rid of it.. What?! I think we're past the point where anyone really cares if you have a conforming implementation anymore. If you don't like AH, don't negotiate it. As for a lot of us though, I think you'll see AH being negotiated by many implementations, regardless of the outcome of this discussion. Why not a straw poll on how many people think it is too late to be making significant changes like this? I once flamed Dan McDonald for complaining about nit picking (I apologize Dan, you didn't deserve that).. Now, I understand his frustration. -Rob -----Original Message----- From: William Allen Simpson [SMTP:wsimpson@greendragon.com] Sent: Tuesday, June 03, 1997 4:12 AM To: ipsec@tis.com Subject: Re: eliminate AH -- unanimous Ahh, and it's messages like these that remind me what a true joy it has been to discuss things with the cryptologic community. If you bring two of them together, you get 4 opinions; 3 of them yield 9, etc. In this case, we cannot even get a consistent conclusion from the same person in different weeks.... > From: Steven Bellovin > Ever since Bill posted his straw poll, I've been bothered by an > intuitive feeling that AH and encryptionless ESP were not equivalent. Reminding you that the straw poll was posted in response to your message: Date: Wed, 21 May 1997 11:51:34 -0400 From: Steven Bellovin ... *) I don't like meaningless cryptography. Almost two years ago, I posted a field-by-field analysis. I showed that the IP header fields are either irrelevant for security purposes, changed en route (and hence not protectable), or are or should be bound to the security association, and hence need not be authenticated on a per-packet basis. ... The only reason we're discussing this again is because we realized that encryption almost always requires authentication. This may not be sufficient reason to reopen the question, especially given the immediately preceeding point. But yes, in an ideal world I'd opt for a clean AH, aka encryptionless ESP. > This afternoon, I finally realized the crucial difference: AH can be > deleted or ignored in a context-independent way. > ... This can't be done with ESP > without knowledge of the security association. > > Now -- whether or not we want to enable any of these abilities is a > separate issue. But the distinction does exist. > I conclude that the analysts have a wonderful time enumerating all the possibilities, but are unable to make any final recommendations as to the engineering choices we need to make. I personally will have a very difficult time supporting any such future recommendation, knowing that 9 days later the same analyst will come back and undermine his own position. So much for a consensus building exercise ... what a waste of time, in this group. Keep AH, and impose an outright ban on encryptionless ESP. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Tue Jun 3 10:41:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA17591 for ipsec-outgoing; Tue, 3 Jun 1997 10:41:37 -0400 (EDT) Message-Id: <199706031446.KAA27292@raptor.research.att.com> To: "William Allen Simpson" cc: ipsec@tis.com Subject: Re: eliminate AH -- unanimous Date: Tue, 03 Jun 1997 10:46:17 -0400 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm going to break some of my rules here. Ahh, and it's messages like these that remind me what a true joy it has been to discuss things with the cryptologic community. If you bring two of them together, you get 4 opinions; 3 of them yield 9, etc. In this case, we cannot even get a consistent conclusion from the same person in different weeks.... Bill, if you know any way to produce instant solutions to problems, I'd love to know it. I can't do that. What I can do is to continue to work on the problem. In this case, as you noted, I said in so many words that it took me a while to come up with it: > From: Steven Bellovin > Ever since Bill posted his straw poll, I've been bothered by an > intuitive feeling that AH and encryptionless ESP were not equivalent . So -- what shall we do? Shall we defer any solution until everyone agrees to do no more thinking about the problem? Perhaps only researchers who agree to take such an oath are allowed to work on it? I, at least, will admit my own mistakes when I recognize them. Two or three years ago, it was decided that we should have both AH and ESP. In the aftermath of my recent notes, several people have pointed out to me that my latest posting, showing a difference between AH and null ESP, was in fact old news -- it was the original rationale. Great -- that means that the correct analysis was done, and that I had forgotten it, and that others had either forgotten it or simply declined to post. (Why anyone would be shy about posting to this list is beyond me...) It's a sure sign that the working group has gone on too long when we no longer remember why we did certain things. Two years ago, I (among others) objected to the design of AH, for good and sufficient reason. Mind you, I wasn't objecting to the concept back then, but rather, to the details of the MAC computation. Now, Kent has proposed an ESP variant that satisfies those objections of mine, but doesn't preserve the context-free discard ability. (I should note that several people have also pointed out that the current AH spec protects the IPSO information. My religion dictates that security labels are bound to the SPI -- see Pirke Machshavim Tovim 0x1234:2^56 for the detailed exposition of this by Rebbitzen DES -- so I don't care about that property.) We have the following choices: a) Keep AH the way it's been; permit encryptionless ESP. b) Keep AH the way it's been; ban encryptionless ESP. c) Discard AH; use encryptionless ESP only. d) Redefine AH so that it has the semantics of encryptionless ESP. Use either a flag bit in the header or a separate protocol number to distinguish this case, to preserve the context- free knowledge that no encryption has been used. As best I can tell, export controls are a red herring here, btw. So -- in an ideal world, I'd pick (d), as indeed I did two years ago. But that choice was rejected by the group, and I'm content with that decision. There is no new data, and I see no reason to reopen the question -- that I "lost" is manifestly insufficient. You now suggest (c). We lose certain abilities, and in particular we lose the same abilities that caused (d) to be rejected two years ago. The choice between (a) and (b) is, for the most part, whether or not we include explicit language on the subject in the ESP draft; as has been noted, it's easy to write a separate encryptionless shim document. I have a modest preference for the separate document approach, since otherwise an implementor has to choose between null ESP and AH for cleartext connections, without architectural guidance. That is, if we're going to provide two different -- but not equivalent -- ways to do the same thing, we need to specify when each should be used. But if people feel otherwise, I'm not going to waste the electrons (or whatever remaining life my wrist tendons have) disagreeing. *I'm perfectly content with any of these choices. I don't give a rat's ass which is picked; all of them are (to my knowledge) secure, and since I'm not implementing anything these days the ugliness of some of the choices is purely esthetic. They'll all work. I want this spec finished, and the group disbanded.* From owner-ipsec Tue Jun 3 13:27:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA18799 for ipsec-outgoing; Tue, 3 Jun 1997 13:25:22 -0400 (EDT) Message-Id: <199706031752.NAA04904@relay.rv.tis.com> Date: Tue, 3 Jun 1997 13:28:54 -0400 From: gary flynn To: ipsec@tis.com Subject: IPSEC and Network Analysis Cc: gary@habanero.jmu.edu Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, I'm eagerly awaiting IPSEC functionality for its security advantages but I'm a little anxious about what it will mean in troubleshooting. The industry continues to distribute more and more layers of protocols, APIs, middleware, etc. Even with all the logging and trace files available, I still locate the source of a lot of problems by capturing and analyzing packets. How easy will it be to turn the encryption off when necessary for troubleshooting? Will IPSEC render all the management and monitoring tools like RMON probes useless? I'd guess that this is highly implementation specific but was curious if anyone has thought about this. Gary Flynn Network Analyst James Madison University From owner-ipsec Tue Jun 3 14:14:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA19138 for ipsec-outgoing; Tue, 3 Jun 1997 14:14:28 -0400 (EDT) From: Dan.McDonald@Eng.Sun.COM (Dan McDonald) Message-Id: <199706031821.LAA14044@kebe.eng.sun.com> Subject: Re: IPSEC and Network Analysis To: gary@habanero.jmu.edu (gary flynn) Date: Tue, 3 Jun 1997 11:21:34 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <199706031752.NAA04904@relay.rv.tis.com> from "gary flynn" at Jun 3, 97 01:28:54 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 > The industry continues to distribute more and more layers of protocols, > APIs, middleware, etc. Even with all the logging and trace files available, > I still locate the source of a lot of problems by capturing and analyzing > packets. Lots of us are in this boat, Gary. My advisor once said, "There's no such thing as too many traces." > How easy will it be to turn the encryption off when necessary for > troubleshooting? Will IPSEC render all the management and monitoring tools > like RMON probes useless? The idea behind IPsec is to make monitoring hard. In our minds, people who monitor are adversaries of some kind. In your mind, monitoring is for troubleshooting. Both mindsets are legitimate. > I'd guess that this is highly implementation specific but was curious if > anyone has thought about this. I suspect we all have to some small degree. An implementation {SHOULD,MUST} be able to turn off IPsec. If your network problem is local, then unplugging your router and turning off IPsec would probably work and allow you to troubleshoot without the kiddies coming in to bug you. Another possibility is to be able to feed real IP security associations into a monitoring tool, so that monitoring tool can decrypt/authenticate packets that it reads as easily as the destination would. The flip side to this coin is that an adversary (if he/she has access to the security associations) can use such a tool to his/her benefit. BTW, the only time you have to worry about this is with ESP. AH is just another header, and can _easily_ be parsed around. I can't remember if the NRL IPv6/IPsec distribution ships with its modified tcpdump, but when I was at NRL we'd modified tcpdump to parse around AH and still see all of the relevant TCP/UDP/etc. headers. It was nice to have. Hope this helps, Dan From owner-ipsec Tue Jun 3 14:15:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA19151 for ipsec-outgoing; Tue, 3 Jun 1997 14:15:28 -0400 (EDT) Message-Id: <199706031821.AA078352107@relay.hp.com> To: gary flynn Cc: ipsec@tis.com Subject: Re: IPSEC and Network Analysis In-Reply-To: gary's message of Tue, 03 Jun 1997 13:28:54 -0400. <199706031752.NAA04904@relay.rv.tis.com> Date: Tue, 03 Jun 1997 14:21:46 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > How easy will it be to turn the encryption off when > necessary for troubleshooting? Hopefully, very difficult, since the encryption is presumably in use for a reason; turning it off would presumably open up security vulnerabilities for whatever applications are in use.. > Will IPSEC render all > the management and monitoring tools like RMON probes > useless? Not completely; RMON probes will still be useful for traffic analysis.. :-) > I'd guess that this is highly implementation specific but > was curious if anyone has thought about this. Probably the right way to approach this from a security perspective will be to build RMON-like functionality into end systems.. when a party authorized by the end system's administrator requests it, send a copy of decrypted traffic to the monitoring station -- hopefully via some sort of encrypted channel to the monitoring station so that the traffic is never sent on the wire in the clear.. - Bill From owner-ipsec Tue Jun 3 17:25:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA20545 for ipsec-outgoing; Tue, 3 Jun 1997 17:23:59 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <9706022139.AA02322@mentat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 3 Jun 1997 17:16:13 -0400 To: Marc Hasson From: Stephen Kent Subject: Re: New draft -- IPSEC AH Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Marc, Thanks for all of your detailed comments: - The backwards compatibility comment refers to the fact that previous drafts (and the RFC) calls for a "minus 2" length adjustment and we didn't want to change that unnecessarily. However, with the permission of the implementors, I'd be happy to make this a "minus 3" adjustment and eliminate the parenthetical comment. -We'll revise the text to say that a null authentication algorithm would have a length field of "1" (not "0") due to the addition of sequence number as a mandatory field. - We'll change the initial value for the sequence number counter to be "0" instead of "1" so that the first transmitted packet will contain the value "1". - We'll change the max counter value to 2^32 (from 2^32-1) to reflect the previous change. Steve From owner-ipsec Tue Jun 3 17:26:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA20572 for ipsec-outgoing; Tue, 3 Jun 1997 17:25:58 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.32.19970602231250.00b27100@earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 3 Jun 1997 17:24:00 -0400 To: Bob Monsour From: Stephen Kent Subject: Re: New draft -- IPSEC ESP Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bob, Sorry about the AH references in the ESP document! As you can see, we tried to avoid needless differences between the two, but I guess we went too far sometimes! As for the location of the IV, yes, I envisioned that it be at the beginning of the payload section. A previous internal draft said just that, but chastened by Bill's remarks about padding being an algorithm-specific feature, I made the ESP spec ambiguous and shifted the burden to the algorithm application documents. I'm happy to move it back, since all of my experience suggests having an explicit IV up front, but the intent was to defer to the algorithm documents to permit the greatest possible flexibility. Steve From owner-ipsec Tue Jun 3 23:36:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA22373 for ipsec-outgoing; Tue, 3 Jun 1997 23:32:38 -0400 (EDT) Message-Id: <3.0.1.32.19970603233836.0074f9e0@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Tue, 03 Jun 1997 23:38:36 -0400 To: gary flynn From: Rodney Thayer Subject: Re: IPSEC and Network Analysis Cc: ipsec@tis.com In-Reply-To: <199706031752.NAA04904@relay.rv.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk The conventional dogma among the IPsec community is that this is a bad idea. However, there ARE people who feel that issues of maintainability and protocol certification merit some capability to do this. The IPsec MIB has the potential to support this, although that's not necessary. I like to remind people that the dirty truth is, the way people are building this stuff is that they disengage the crypto one way or another to debug, and debugging for interoperability is very close to ongoing maintenance situations. Another point is, these crypto people are smart, so they should be able to come up with a safe way to do this. After all, we're not asking for a big switch on the side of the box labelled "DISENGAGE CRYPTO SILENTLY". At 01:28 PM 6/3/97 -0400, you wrote: > >How easy will it be to turn the encryption off when >necessary for troubleshooting? Will IPSEC render all >the management and monitoring tools like RMON probes >useless? ---- ---- Rodney Thayer rodney@sabletech.com Sable Technology Corporation +1 617 332 7292 246 Walnut Street +1 617 332 7970 (Fax) Newton, MA 02160 From owner-ipsec Tue Jun 3 23:56:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA22468 for ipsec-outgoing; Tue, 3 Jun 1997 23:56:07 -0400 (EDT) Message-ID: <01BC707A.9E1EF040@col-as10s06.erols.com> From: Brian Rexroad To: "'Stephen Kent'" Cc: "'ipsec@tis.com'" , "'Bellovin, Steve'" Subject: RE: ESP revisions straw poll Date: Wed, 4 Jun 1997 00:01:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id XAA22465 Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen, It took awhile for me to remember the history of this. Having worked on an earlier protocol that may have influenced some of this work, there may be some motivation to keep the IV in a separate exchange. In our case, it was necessary to keep the IV in a separate exchange for reasons other than cryptographic algorithm or mode. We elected to send the IV in a separate exchange to accommodate encryption of applications which are more time sensitive than dependent on reliable transport -- real-time interactive stuff. In any case, it is desirable to ensure the IV is transferred without errors, but it is often tolerable to have bit errors in the traffic (voice and video services for example). Therefore, it was desirable to use a difference service for transmission of the IV in comparison to the traffic. This information may have little bearing on this work, but it was certainly relevant in our implementation. Brian Rexroad AT&T Information Security Center brexroad@att.com -----Original Message----- From: Stephen Kent [SMTP:kent@bbn.com] Sent: Tuesday, May 13, 1997 9:06 PM To: ipsec@tis.com Subject: ESP revisions straw poll Folks, In an effort to reach closure on the suggested changes to the latest ESP spec, I suggest the following revision, in addition to my earlier message about authenticationless ESP: - The optional IV field will be removed; if an encryption algorithm requires an IV, it will be transmitted as the initial portion of the ciphertext payload. The definition of the encryption algorithm as provided for use with ESP, will specify the presence (or absence) or an IV, and describe its length. the recent I-Ds on RC5 and CAST adopt this approach to algorithm definition. From owner-ipsec Wed Jun 4 09:33:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA25848 for ipsec-outgoing; Wed, 4 Jun 1997 09:31:09 -0400 (EDT) Date: Wed, 4 Jun 1997 09:34:48 -0400 From: Norman Shulman X-Sender: norm@rafael.tornd.securecomputing.com To: Stephen Kent cc: Marc Hasson , ipsec@tis.com Subject: Re: New draft -- IPSEC AH In-Reply-To: Message-Id: <97Jun4.092953edt.11652@janus.tor.securecomputing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Tue, 3 Jun 1997, Stephen Kent wrote: > - We'll change the max counter value to 2^32 (from 2^32-1) to > reflect the previous change. Note that 2^32 is the upper bound on the number of packets transmitted on an SA; the max counter value is still 2^32-1. Norm Norman Shulman Secure Computing Canada Systems Developer Tel 1 416 813 2075 norm@tor.securecomputing.com Fax 1 416 813 2001 From owner-ipsec Wed Jun 4 09:54:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA26007 for ipsec-outgoing; Wed, 4 Jun 1997 09:53:16 -0400 (EDT) Message-ID: From: Roy Pereira To: "'William Allen Simpson'" , "'Steven Bellovin'" Cc: "'ipsec@tis.com'" Subject: RE: eliminate AH -- unanimous Date: Wed, 4 Jun 1997 09:48:03 -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 Steve, >*I'm perfectly content with any of these choices. I don't give a rat's >ass which is picked; all of them are (to my knowledge) secure, and >since I'm not implementing anything these days the ugliness of some of >the choices is purely esthetic. They'll all work. I want this spec >finished, and the group disbanded.* I couldn't agree more ! As can be seen by the latest rounds of ANX testing that is going on right now, all of these specification changes and ambiguity is causing major delays in interoperability. Lets release version 1.0 since we know it works. Let's perhaps improve it and add bells and whistles in version 1.1 ! From owner-ipsec Wed Jun 4 11:11:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA26546 for ipsec-outgoing; Wed, 4 Jun 1997 11:07:48 -0400 (EDT) Message-Id: <3.0.1.32.19970604111336.00722ab8@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Wed, 04 Jun 1997 11:13:36 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: padding questions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk In the new new new ESP draft (draft-ietf-ipsec-esp-04) in section 2.4 it talks about padding. For an encryption scheme such as DES you need padding, so the (DES) document for ESP would have to talk about it's padding requirements. There are also requirements from the hardware community about what the padding values are (for DES/3DES chips.) So I guess the DES document will have to be updated. However, the document also suggests padding could be used to assist in hiding the true payload length, or for boundry conditions. For example I could take a 9 byte payload, add 5 bytes of pad (9 payload + 5 pad + 1 pad-length + 1 next-payload = 16 which is divisible by 8) But could I send the same packet padded with 21 bytes, i.e. throw in two more pad 'blocks' for obscurity? What if I use a non-block oriented encryption scheme such as ARCFOUR? It seems to me that to a civil implementation might want to pad to 8-byte boundries for politeness (and IPv6, etc.) Does this mean ALL encryption algorithm documents that accompany this MUST describe padding? Otherwise where do you document how to set the pad bytes (random/0-origin/1-origin/constant) From owner-ipsec Wed Jun 4 11:31:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA26746 for ipsec-outgoing; Wed, 4 Jun 1997 11:30:23 -0400 (EDT) Date: Wed, 4 Jun 97 08:32:41 PDT From: marc@mentat.com (Marc Hasson) Message-Id: <9706041532.AA13857@mentat.com> To: norm@tor.securecomputing.com Subject: Re: New draft -- IPSEC AH Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk > > - We'll change the max counter value to 2^32 (from 2^32-1) to > > reflect the previous change. > > Note that 2^32 is the upper bound on the number of packets transmitted on an > SA; the max counter value is still 2^32-1. Correct. 2^32 fits in with the current text that uses the word "prior", so it will now implicitly specify that 2^32-1 is the highest value to appear within the sequence # on the wire. Before, the largest value sent was 2^32-2. -- Marc -- From owner-ipsec Wed Jun 4 12:53:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA27436 for ipsec-outgoing; Wed, 4 Jun 1997 12:52:17 -0400 (EDT) Message-Id: <199706041659.AA275103543@relay.hp.com> To: Rodney Thayer Cc: ipsec@tis.com Subject: Re: padding questions In-Reply-To: rodney's message of Wed, 04 Jun 1997 11:13:36 -0400. <3.0.1.32.19970604111336.00722ab8@pop3.pn.com> Date: Wed, 04 Jun 1997 12:58:47 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > However, the document also suggests padding could be used to assist in > hiding the true payload length, or for boundry conditions. For example I > could take a 9 byte payload, add 5 bytes of pad (9 payload + 5 pad + 1 > pad-length + 1 next-payload = 16 which is divisible by 8) But could I send > the same packet padded with 21 bytes, i.e. throw in two more pad 'blocks' > for obscurity? I've seen this mentioned as a possibility in presentations about ESP for a number of years.. - Bill From owner-ipsec Wed Jun 4 20:38:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA00391 for ipsec-outgoing; Wed, 4 Jun 1997 20:35:36 -0400 (EDT) Date: Wed, 4 Jun 97 23:12:38 GMT From: "William Allen Simpson" Message-ID: <5996.wsimpson@greendragon.com> To: ipsec@tis.com Subject: finishing the work Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve Bellovin wrote: > >*I'm perfectly content with any of these choices. I don't give a rat's > >ass which is picked; all of them are (to my knowledge) secure, and > >since I'm not implementing anything these days the ugliness of some of > >the choices is purely esthetic. They'll all work. I want this spec > >finished, and the group disbanded.* > Roy Pereira responds: > I couldn't agree more ! As can be seen by the latest rounds of ANX > testing that is going on right now, all of these specification changes > and ambiguity is causing major delays in interoperability. Lets release > version 1.0 since we know it works. Let's perhaps improve it and add > bells and whistles in version 1.1 ! > Count me in agreement, too, with a caveat: We already shipped version 1.0 in August of 1995. We are arguing about version 1.1, and it has suffered from the addition of too many bells and whistles. Take them out, and leave them for version 2.0. For 1.1, let us be as compatible with 1.0 as possible. That will alleviate the interoperability problems. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Wed Jun 4 20:38:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA00392 for ipsec-outgoing; Wed, 4 Jun 1997 20:35:36 -0400 (EDT) Date: Wed, 4 Jun 97 23:25:38 GMT From: "William Allen Simpson" Message-ID: <5997.wsimpson@greendragon.com> To: ipsec@tis.com Cc: Steven Bellovin Subject: AH versus ESP -- no longer unanimous Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Steven Bellovin > > Ever since Bill posted his straw poll, I've been bothered by an > > intuitive feeling that AH and encryptionless ESP were not equivalent > > So -- what shall we do? Shall we defer any solution until everyone agrees > to do no more thinking about the problem? Perhaps only researchers who > agree to take such an oath are allowed to work on it? I, at least, will > admit my own mistakes when I recognize them. > It did not appear to me to be worded as the admission of a mistake. It appeared to be waffling, after a claim that the topic had been completely considered over a period of 2 years. Apology accepted. > We have the following choices: > > a) Keep AH the way it's been; permit encryptionless ESP. > > b) Keep AH the way it's been; ban encryptionless ESP. > > c) Discard AH; use encryptionless ESP only. > > d) Redefine AH so that it has the semantics of encryptionless > ESP. Use either a flag bit in the header or a separate protocol > number to distinguish this case, to preserve the context- > free knowledge that no encryption has been used. > > So -- in an ideal world, I'd pick (d), as indeed I did two years ago. > But that choice was rejected by the group, and I'm content with that > decision. There is no new data, and I see no reason to reopen the > question -- that I "lost" is manifestly insufficient. > Agreed. Also, as you may remember, I have previously noted that it is impossible to prevent (a), even by a mandate, as a "null" encryption transform could be publically or privately implemented. > You now suggest (c). We lose certain abilities, and in particular we > lose the same abilities that caused (d) to be rejected two years ago. > Actually, the poll was because (b) was rejected by the document editor, despite the group decision in its favor at Memphis, and you posted a long note that appeared to ask for (c). The list posters unanimously chose (c), until the obvious result was announced, and then another set of postings repudiated it. In short, there is a fundamental disagreement between the implementors and the researchers on this list preventing this group as a whole from making final choices -- of virtually anything. > The choice between (a) and (b) is, for the most part, whether or not > we include explicit language on the subject in the ESP draft; as has > been noted, it's easy to write a separate encryptionless shim document. I think that any explicit language added (that would be the architecture document covering AH and ESP, not the ESP document itself) would probably extend the already long period of contention. We have been arguing for over 2 months. > I have a modest preference for the separate document approach, since > otherwise an implementor has to choose between null ESP and AH for > cleartext connections, without architectural guidance. That is, if > we're going to provide two different -- but not equivalent -- ways to > do the same thing, we need to specify when each should be used. But > if people feel otherwise, I'm not going to waste the electrons (or > whatever remaining life my wrist tendons have) disagreeing. > Please write the "null" encryption transform draft, including thorough guidance on when to use it. Maybe a concrete specification will end the arguing, and you can convince someone to implement it. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Wed Jun 4 22:48:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA01173 for ipsec-outgoing; Wed, 4 Jun 1997 22:46:20 -0400 (EDT) Message-Id: <3.0.32.19970604195113.00b11b50@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 04 Jun 1997 19:51:22 -0700 To: "William Allen Simpson" From: Bob Monsour Subject: Your DES/3DES drafts Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, Can you explain the wording in the Security Considerations section of your drafts: (at the end of the second paragraph) > ered cryptographically strong. In this situation, user or connection > oriented integrity checking is needed [RFC-1826]. Why "connection oriented"? I didn't see anything in RFC 1826 about connection oriented integrity. In an IP environment, I would expect to see (strong) "connectionless integrity". Especially since the previous sentence mentioned ICMP and UDP, which are not connection oriented protocols. -Bob From owner-ipsec Thu Jun 5 10:29:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA05518 for ipsec-outgoing; Thu, 5 Jun 1997 10:24:32 -0400 (EDT) Date: Thu, 5 Jun 97 13:49:58 GMT From: "William Allen Simpson" Message-ID: <6004.wsimpson@greendragon.com> To: ipsec@tis.com Subject: users and connections Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Bob Monsour > Can you explain the wording in the Security Considerations section of your > drafts: > I'll do my best, albeit Perry wrote most of the Security Considerations, but it seems reasonably clear to me. > > ered cryptographically strong. In this situation, user or connection > > oriented integrity checking is needed [RFC-1826]. > > Why "connection oriented"? I didn't see anything in RFC 1826 about > connection oriented integrity. RFC-1826 provides integrity: The Authentication Header is a mechanism for providing strong integrity and authentication for IP datagrams. ... Perhaps you could become more familiar with the Bellovin paper? The attack described involves mutually suspicious users. To prevent the attack, the SPI keying should be on a per user (or for proxying firewalls, per connection) basis. Otherwise, the attacking user has access to the SPI, and can trivially decode the traffic. > In an IP environment, I would expect > to see (strong) "connectionless integrity". Especially since the > previous sentence mentioned ICMP and UDP, which are not connection > oriented protocols. > You must be coming from an ISO-speak environment. IP has the concept of "datagram", not "connectionless"; connections are the next level up. Usually, when we talk about "connection", we mean a set of datagrams with the same IP Source and Destination, and the same port numbers at the transport layer. A proxying firewall uses the connection to setup and distinguish a Security Association. Also, the Sequence Number field orders datagrams. That forms a connection over all the datagrams for the SA, by any definition. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Thu Jun 5 12:26:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA06249 for ipsec-outgoing; Thu, 5 Jun 1997 12:24:43 -0400 (EDT) From: Dan.McDonald@Eng.Sun.COM (Dan McDonald) Message-Id: <199706051631.JAA09493@kebe.eng.sun.com> Subject: Re: users and connections To: wsimpson@greendragon.com (William Allen Simpson) Date: Thu, 5 Jun 1997 09:31:30 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <6004.wsimpson@greendragon.com> from "William Allen Simpson" at Jun 5, 97 01:49:58 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 > > Why "connection oriented"? I didn't see anything in RFC 1826 about > > connection oriented integrity. > > RFC-1826 provides integrity: > > The Authentication Header is a mechanism for providing strong > integrity and authentication for IP datagrams. ... > > Perhaps you could become more familiar with the Bellovin paper? > > The attack described involves mutually suspicious users. To prevent the > attack, the SPI keying should be on a per user (or for proxying > firewalls, per connection) basis. Otherwise, the attacking user has > access to the SPI, and can trivially decode the traffic. Bill raises a fine point that, in particular, host vendors should take to heart. It is not only possible to implement, but REQUIRED that unique-per-endpoint SA assignment be allowed to happen. (Small hair to split: A single socket can be in use by two users, so per-user might be harder than per-endpoint, but like I said, it's a small hair to split, since most endpoints are unique-per-user anyway.) There is freely available source out there (NRL for one, and perhaps more...) that implements per-socket IPsec keying. Anyone requiring hints on implementing it should check it out. I suspect we have enough people who've figured it out on their own, though. And yes, it's in my future implementation plans as well. Just wanted to chime in along with Bill. Dan From owner-ipsec Fri Jun 6 01:14:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA10534 for ipsec-outgoing; Fri, 6 Jun 1997 01:10:22 -0400 (EDT) Message-Id: <199706060513.BAA03463@relay.hq.tis.com> Date: Fri, 6 Jun 97 1:08:41 EDT From: Karen Seo To: ipsec@tis.com cc: kseo@bbn.com Subject: AH/ESP edits Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, Thank you for the help and careful review. Based on the feedback so far, we've made the following changes to the AH and ESP documents. Our apologies for any comments we missed (or misunderstood). Please let us know your opinions about the pending items below by Friday the 13th (6/13/97). Thanks again, Karen Pending items ------------- 1. ESP: location of the IV in the payload section -- Should the IV be specified as always at the beginning, default at the beginning of the payload field with the option of algorithm-specific locations or always algorithm-specific? (see email from Steve Kent on 6/3/97) 2. AH: Payload length -- Should this be AH header minus 2 32-bit words or minus 3 words? In recent drafts, this field has been specified as the AH header minus the fixed portion (This was 2 32-bit words and is now 3 words). (see email from Steve Kent on 6/3/97). ESP --- 1. In section 3.1, "ESP Header Location", IPv6 tunnel-mode diagram, replaced "AH" with "ESP" in the note under the diagram. 2. In section 3.2.5, "Fragmentation", replaced "AH" with "ESP". 3. In section 2.2 "Sequence Number"... Corrected/clarified the text on initialization to say, "The sender's counter and the receiver's counter are initialized to 0 when an SA is established. The sequence number, the sender's counter, and the receiver's counter must never be allowed to cycle. Thus, they MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA. 4. In section 3.3.4, "Integrity Check Value Verification", DISCUSSION... Changed the wording from "Now perform the ICV computation and compare the result with the received value." to "Now perform the ICV computation and compare the result with the saved value." 5. In section 2.4, "Padding (for Encryption)... Changed to specify a default for the padding value (random data) with the algorithm documents allowed to override this and specify a different padding value if so desired. "As a default, the Padding bytes SHOULD be initialized with random data and they are transmitted. The transmitter can add 0-255 bytes of padding. Any encryption algorithm used with ESP that requires a padding value other than the default value MUST define its padding requirements in an RFC specifying how the algorithm is used with ESP. The content of the Padding field will thus be determined by the encryption algorithm and mode selected and defined in the corresponding algorithm RFC." 6. In section 3.3.3, "Sequence Number Verification", 3rd paragraph... Changed the wording from "The default window size is 32 ... A larger window size MAY be established during SA negotation. If a larger window size is negotiated it MUST be a multiple of 32. " to "The default window size is 32 ... A larger window size MAY be chosen by the receiver (and reported to the transmitter) during SA negotiation. If a larger windowsize is chosen it MUST be a multiple of 32. " 7. In section 3.2.3.1, paragraph 1, line 6: "the the" --> "the". 8. In section 3.3.2, paragraph 1, line 5: deleted "Sequence Number and"; changed "fields" to "field". 9. In section 3.3.3, DISCUSSION, line 3: "packet" --> "the packet". AH -- 1. In section 2.2, "Payload Length"... In the sentences, "A "null" authentication algorithm may be used only for debugging purposes. Its use would result in a "1" value for this field, as there would be no corresponding Authentication Data field.", the value will be adjusted to "0" or "1" depending on the decision on whether to subtract 2 or 3 words from the AH header. 2. In section 2.2, "Payload Length"... We've added the text, "In the "standard" case of a 96-bit authentication value plus the 3 32-bit word fixed portion, this length field will be "tbd". (tbd depends on the decision on whether to subtract 2 or 3 words from the AH header.) 3. In section 2.5, "Sequence Number"... Corrected/clarified the text on initialization to say, "The sender's counter and the receiver's counter are initialized to 0 when an SA is established. The sequence number, the sender's counter, and the receiver's counter must never be allowed to cycle. Thus, they MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA. 4. In section 3.2.3.2.1, "Authentication Data Padding"... Changed the wording from "the IP protocol context (v4 or v6)" to "the IP protocol version (v4 or v6)". 5. In section 3.2.3.2.1, "Authentication Data Padding"... Changed the wording from "These bytes are included in the Authentication Data calculation,..." to " These padding bytes are included in the Authentication Data calculation,..." 6. In section 3.3.1, "Reassembly"... Changed the wording from "If a packet offered to AH for processing appears to be an IP fragment, e.g., the OFFSET field is non-zero..." to "If a packet offered to AH for processing appears to be an IP fragment, i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set... 7. In section 3.3.3, "Sequence Number Verification", 3rd paragraph... Changed the wording from "The default window size is 32 ... A larger window size MAY be established during SA negotation." to "The default window size is 32 ... A larger window size MAY be chosen by the receiver (and reported to the transmitter) during SA negotiation." 8. In section 3.3.4, "Integrity Check Value Verification", DISCUSSION... Changed the wording from "Now perform the ICV computation and compare the result with the received value." to "Now perform the ICV computation and compare the result with the saved value. 9. In section 3.2.3.1.2, "ICV Computation for IPv6", ... Added "Priority" and "Flow Label" to the list of fields zero'd prior to performing ICV calculation. "Version" was left covered. "IPv4 Offset" was left uncovered. From owner-ipsec Fri Jun 6 04:21:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA11483 for ipsec-outgoing; Fri, 6 Jun 1997 04:17:54 -0400 (EDT) Message-Id: <3.0.32.19970606012244.00919610@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 06 Jun 1997 01:22:47 -0700 To: Karen Seo From: Bob Monsour Subject: Re: AH/ESP edits Cc: ipsec@tis.com, kseo@bbn.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 01:08 AM 6/6/97 EDT, Karen Seo wrote: >Pending items >------------- >1. ESP: location of the IV in the payload section -- Should the IV be > specified as always at the beginning, default at the beginning of the > payload field with the option of algorithm-specific locations or > always algorithm-specific? (see email from Steve Kent on 6/3/97) I had raised the issue primarily because the DES and 3DES drafts that had recently been submitted did not specify the location of the IV (I had presumed that it was a the start of the payload, but it was not clear that it had to be). The RC5 and CAST drafts explicitly call for it to be located at the start of the payload. My suggestion for the ESP draft is to specify it as algorithm-specific (we've just got to make sure it's done as part of reviewing the transforms). -Bob From owner-ipsec Fri Jun 6 11:27:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA13973 for ipsec-outgoing; Fri, 6 Jun 1997 11:16:50 -0400 (EDT) Date: Fri, 6 Jun 1997 11:16:50 -0400 From: Norman Shulman X-Sender: norm@rafael.tornd.securecomputing.com To: Karen Seo cc: ipsec@tis.com, kseo@bbn.com Subject: Re: AH/ESP edits In-Reply-To: <199706060513.BAA03463@relay.hq.tis.com> Message-Id: <97Jun6.111151edt.11655@janus.tor.securecomputing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Fri, 6 Jun 1997, Karen Seo wrote: > Thank you for the help and careful review. Based on the feedback so > far, we've made the following changes to the AH and ESP documents. Our > apologies for any comments we missed (or misunderstood). Please let us > know your opinions about the pending items below by Friday the 13th > (6/13/97). > > Pending items > ------------- > 1. ESP: location of the IV in the payload section -- Should the IV be > specified as always at the beginning, default at the beginning of the > payload field with the option of algorithm-specific locations or > always algorithm-specific? (see email from Steve Kent on 6/3/97) Always algorithm-specific. Norm Norman Shulman Secure Computing Canada Systems Developer Tel 1 416 813 2075 norm@tor.securecomputing.com Fax 1 416 813 2001 From owner-ipsec Fri Jun 6 14:00:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA15157 for ipsec-outgoing; Fri, 6 Jun 1997 13:58:24 -0400 (EDT) Message-Id: <2.2.32.19970606181338.014d5578@mailserv-H.ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 06 Jun 1997 14:13:38 -0400 To: Karen Seo From: Naganand Doraswamy Subject: Re: AH/ESP edits Cc: ipsec@tis.com, kseo@bbn.com Sender: owner-ipsec@ex.tis.com Precedence: bulk >Pending items >------------- >1. ESP: location of the IV in the payload section -- Should the IV be > specified as always at the beginning, default at the beginning of the > payload field with the option of algorithm-specific locations or > always algorithm-specific? (see email from Steve Kent on 6/3/97) > This should be algorithm specific >2. AH: Payload length -- Should this be AH header minus 2 32-bit words > or minus 3 words? In recent drafts, this field has been specified as > the AH header minus the fixed portion (This was 2 32-bit words and is > now 3 words). (see email from Steve Kent on 6/3/97). > I dont have a very opinion on this but I am inclined to say 3 32 bit words. I am currently interpreting payload lenght as hash length. --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) From owner-ipsec Fri Jun 6 16:05:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA15912 for ipsec-outgoing; Fri, 6 Jun 1997 16:02:51 -0400 (EDT) Message-ID: From: Roy Pereira To: "'ipsec@tis.com'" , "'Karen Seo'" Subject: RE: AH/ESP edits Date: Fri, 6 Jun 1997 16:06:39 -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 >Pending items >------------- >1. ESP: location of the IV in the payload section -- Should the IV be > specified as always at the beginning, default at the beginning of the > payload field with the option of algorithm-specific locations or > always algorithm-specific? (see email from Steve Kent on 6/3/97) I'm not sure that a section concerning IVs needs to be in the main ESP document since IVs are only used for a particular type of cipher algorithm (CBC) and not all of them. I would leave this entirely up to the algorithm-specific document. >2. AH: Payload length -- Should this be AH header minus 2 32-bit words > or minus 3 words? In recent drafts, this field has been specified as > the AH header minus the fixed portion (This was 2 32-bit words and is > now 3 words). (see email from Steve Kent on 6/3/97). Keep it the same as previous documents. > From owner-ipsec Fri Jun 6 17:23:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA16366 for ipsec-outgoing; Fri, 6 Jun 1997 17:21:02 -0400 (EDT) Message-ID: From: Roy Pereira To: "'ANX Security Mailing List'" , "'IPSEC Mailing List'" Subject: ANX bakeoff ISAKMP issues Date: Fri, 6 Jun 1997 13:01:52 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk The following ISAKMP issues were encountered at the recent ANX IPSec Interoperability tests in Detroit. No 'HMAC Algorithm' attribute should to be sent when negotiating AH. This is redundent, since the same information is presented in the transform ID. Should the Protocol and Port from the IPSEC-DOI ID Payload be included in the hashes? There needs to be a clarification of the "Protocol" that is used to derive the KEYMAT. KEYMAT = prf(SKEYID_D, [ g(qm)^xy ] | PROTOCOL | SPI | Ni | Nr ) Should be it IP_PROTO_ESP or ISAKMP_PROTO_ESP ? If I initiate a MainMode, but then the peer initiates QuickMode, what is the initiator cookie for QuickMode? His or mine? MainMode's initiator or QuickMode's initiator? Keep AH, allow encryption-less ESP, but it should be documented in a separate ESP null-cipher draft that uses the same formating as all the rest of the ESP cipher (DES, 3DES, RC5, CAST)` drafts. In RSA_SIG mode, should we send a CertReq payload when you want the peer to send their Certificate. (HDR, SA, CERTREQ) This might be required since the CERT payload is optional and the peer does know whether you want their certificate or not. Should we place wording in the draft that CertReq payloads must be supported and may be in the first MainMode RSA_SIG exchange. Should the CA_DISTGUISHED_NAME attribute be defined in IPSEC-DOI when it is also being used in MainMode for Certificate Requests? Padding of individual ISAKMP payloads causes problems for payloads like Certificate Payloads. BCERT could not properly parse certificate blobs with padding added on the end. Let's get rid of individual ISAKMP payload padding or add another field to the certificate payload to state the real length of the certificate. Preferably th first option. The KEY_LENGTH attribute is needed in MainMode negotiations for variable key length cipher algorithms like CAST128 and RC5. Roy Pereira TimeStep Corporation http://www.timestep.com (613) 599-3610 x4808 From owner-ipsec Fri Jun 6 17:45:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA16508 for ipsec-outgoing; Fri, 6 Jun 1997 17:44:06 -0400 (EDT) Message-ID: From: Roy Pereira To: "'IPSEC Mailing List'" , "'ANX Security Mailing List'" Subject: ANX bakeoff ISAKMP issues Date: Fri, 6 Jun 1997 17:37:40 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk >The following ISAKMP issues were encountered at the recent ANX IPSec >Interoperability tests in Detroit. > > >No 'HMAC Algorithm' attribute should to be sent when negotiating AH. This is >redundent, since the same information is presented in the transform ID. > >Should the Protocol and Port from the IPSEC-DOI ID Payload be included in the >hashes? > >There needs to be a clarification of the "Protocol" that is used to derive >the KEYMAT. >KEYMAT = prf(SKEYID_D, [ g(qm)^xy ] | PROTOCOL | SPI | Ni | Nr ) >Should be it IP_PROTO_ESP or ISAKMP_PROTO_ESP ? > >If I initiate a MainMode, but then the peer initiates QuickMode, what is the >initiator cookie for QuickMode? His or mine? MainMode's initiator or >QuickMode's initiator? > >Keep AH, allow encryption-less ESP, but it should be documented in a separate >ESP null-cipher draft that uses the same formating as all the rest of the ESP >cipher (DES, 3DES, RC5, CAST)` drafts. > >In RSA_SIG mode, should we send a CertReq payload when you want the peer to >send their Certificate. (HDR, SA, CERTREQ) This might be required since the >CERT payload is optional and the peer does know whether you want their >certificate or not. Should we place wording in the draft that CertReq >payloads must be supported and may be in the first MainMode RSA_SIG exchange. > >Should the CA_DISTGUISHED_NAME attribute be defined in IPSEC-DOI when it is >also being used in MainMode for Certificate Requests? > >Padding of individual ISAKMP payloads causes problems for payloads like >Certificate Payloads. BCERT could not properly parse certificate blobs with >padding added on the end. Let's get rid of individual ISAKMP payload padding >or add another field to the certificate payload to state the real length of >the certificate. Preferably th first option. > >The KEY_LENGTH attribute is needed in MainMode negotiations for variable key >length cipher algorithms like CAST128 and RC5. > >Roy Pereira >TimeStep Corporation http://www.timestep.com >(613) 599-3610 x4808 > From owner-ipsec Fri Jun 6 18:38:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA16731 for ipsec-outgoing; Fri, 6 Jun 1997 18:36:16 -0400 (EDT) Message-Id: <199706062243.PAA17308@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: anx-sec@dot.netrex.net Cc: "'IPSEC Mailing List'" Subject: Re: ANX bakeoff ISAKMP issues In-Reply-To: Your message of "Fri, 06 Jun 1997 13:01:52 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 06 Jun 1997 15:43:28 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk > The following ISAKMP issues were encountered at the recent ANX IPSec > Interoperability tests in Detroit. > > No 'HMAC Algorithm' attribute should to be sent when negotiating AH. > This is redundent, since the same information is presented in the > transform ID. Agreed. The DOI talks about this attribute in conjunction with ESP but I guess it should be more explicit. > Should the Protocol and Port from the IPSEC-DOI ID Payload be included > in the hashes? Absolutely! They're part of the ID. > There needs to be a clarification of the "Protocol" that is used to > derive the KEYMAT. > KEYMAT = prf(SKEYID_D, [ g(qm)^xy ] | PROTOCOL | SPI | Ni | Nr ) > Should be it IP_PROTO_ESP or ISAKMP_PROTO_ESP ? It's the protocol and SPI from the proposal as defined in the base ISAKMP draft figure 6. > If I initiate a MainMode, but then the peer initiates QuickMode, what is > the initiator cookie for QuickMode? His or mine? MainMode's initiator > or QuickMode's initiator? "mine"-- MainMode's initiator. The cookies together identify the ISAKMP SA, if you flip them they'll identify something else-- or nothing. There has been demonstrated interoperability doing this already so I figured it was clear. I can add some explicit verbage to the resolution doc on this. > Keep AH, allow encryption-less ESP, but it should be documented in a > separate ESP null-cipher draft that uses the same formating as all the > rest of the ESP cipher (DES, 3DES, RC5, CAST)` drafts. This isn't really an ISAKMP issue. > In RSA_SIG mode, should we send a CertReq payload when you want the peer > to send their Certificate. (HDR, SA, CERTREQ) This might be required > since the CERT payload is optional and the peer does know whether you > want their certificate or not. Should we place wording in the draft > that CertReq payloads must be supported and may be in the first MainMode > RSA_SIG exchange. If you need a cert then ask for one, but I don't think any ancillary payloads (like the CERTREQ) should be required. Also, for MainMode I don't think it should be HDR, SA, CERTREQ since the SA might also include a pre-shared key protection suite that might end up being selected. The CERTREQ should go in the 2nd round trip-- i.e. HDR, KE, Ni/r, CERTREQ. For AggressiveMode, yea, it should go in the 1st message. > Should the CA_DISTGUISHED_NAME attribute be defined in IPSEC-DOI when it > is also being used in MainMode for Certificate Requests? As opposed to being in the resolution doc? Hmmm, I dunno. > Padding of individual ISAKMP payloads causes problems for payloads like > Certificate Payloads. BCERT could not properly parse certificate blobs > with padding added on the end. Let's get rid of individual ISAKMP > payload padding or add another field to the certificate payload to state > the real length of the certificate. Preferably th first option. Yea, I never understood that requirement. Let's just do away with it. > The KEY_LENGTH attribute is needed in MainMode negotiations for variable > key length cipher algorithms like CAST128 and RC5. It's already there: Attribute #14 (in Appendix A). But the *real* reason it was added was not CAST128 or RC5, it was Blowfish (insert emoticon here). Also, I'd like to add that the base ISAKMP draft should clear up the SPI size confusion. Section 2.4 says that all SPIs must be 8 octets but the proposal payload includes a SPI length field to say how long the SPI is and notes that the SPI field itself is variable. For IPSec the SPI is 4 octets so just pass 4 and say so. I think the 2.4 verbage is a leftover and would like to see it stricken. Dan. From owner-ipsec Mon Jun 9 07:47:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA01840 for ipsec-outgoing; Mon, 9 Jun 1997 07:39:26 -0400 (EDT) Date: Fri, 6 Jun 1997 15:05:43 -0700 From: bishop@cs.ucdavis.edu (Matt Bishop) Message-Id: <199706062205.PAA09043@nob> To: ipsec@ans.net Subject: CFP: 1998 Symposium on Network and Distributed System Security Sender: owner-ipsec@ex.tis.com Precedence: bulk CALL FOR PAPERS The Internet Society Symposium on Network and Distributed System Security Where: San Diego, California When: March 1998 GOAL: The symposium will foster information exchange between hardware and software developers of network and distributed system security services. The intended audience is those who are interested in the practical aspects of network and distributed system security, focusing on actual system design and implementation, rather than theory. Encouraging and enabling the Internet community to apply, deploy, and advance the state of available security technology is the major focus of symposium. Symposium proceedings will be published by the Internet Society. Topics for the symposium include, but are not limited to, the following: * Architectures for large-scale, heterogeneous distributed systems * Security in malleable systems: mobile code, mobile agents, dynamic policy updates, etc. * Special problems: e.g. interplay between security goals and other goals -- efficiency, 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 like the Internet, high-speed systems like the gigabit testbeds, wireless systems, and personal communication 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; endorsement, licensing, bonding, and other forms of assurance; intellectual property protections GENERAL CHAIR: David Balenson, Trusted Information Systems PROGRAM CHAIRS: Matt Bishop, University of California at Davis Steve Kent, BBN PROGRAM COMMITTEE: Steve Bellovin, AT&T Labs -- Research Doug Engert, Argonne National Laboratories Warwick Ford, VeriSign Li Gong, JavaSoft Rich Graveman, Bellcore Ari Juels, RSA Laboratories Tom Longstaff, CERT/CC Doug Maughan, National Security Agency Dan Nessett, 3Com Corporation Rich Parker, NATO Michael Roe, Cambridge University Rob Rosenthal, DARPA Wolfgang Schneider, GMD Darmstadt Christoph Schuba, Purdue University Win Treese, Open Market, Inc. Jonathan Trostle, Novell Gene Tsudik, USC/Information Sciences Institute Steve Welke, Institute for Defense Analyses LOCAL ARRANGEMENTS CHAIR: Thomas Hutton, San Diego Supercomputer Center PUBLICATIONS CHAIR: Steve Welke, Institute for Defense Analyses LOGISTICS CHAIR: Torryn Brazell, 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 1 August 1997, and should 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 should arrive well before 1 August. If electronic submission is difficult, submissions should be sent via postal mail. All submissions and program related correspondence (only) should be directed to the program chair: Matt Bishop, Department of Computer Science, University of California at Davis, Davis CA 95616-8562, Email: sndss98-submissions@cs.ucdavis.edu. Phone: +1 (916) 752-8060, FAX: +1 (916) 752-4767, Dates, final call for papers, advance program, and registration information will be available at the URL: http://www.isoc.org/conferences/ndss98. Each submission will be acknowledged by e-mail. If acknowledgment is not received within seven days, please contact the program chair as in- dicated above. Authors and panelists will be notified of acceptance by 1 October 1997. Instructions for preparing camera-ready copy for the proceedings will be sent at that time. The camera-ready copy must be received by 1 November 1997. From owner-ipsec Mon Jun 9 12:52:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA04361 for ipsec-outgoing; Mon, 9 Jun 1997 12:51:00 -0400 (EDT) Message-Id: <199706091658.JAA00608@fluffy.cisco.com> To: Daniel Harkins cc: anx-sec@dot.netrex.net, "'IPSEC Mailing List'" Subject: Re: ANX bakeoff ISAKMP issues In-reply-to: Your message of "Fri, 06 Jun 1997 15:43:28 PDT." <199706062243.PAA17308@dharkins-ss20> Date: Mon, 09 Jun 1997 09:58:12 -0700 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk >> No 'HMAC Algorithm' attribute should to be sent when negotiating AH. >> This is redundent, since the same information is presented in the >> transform ID. > >Agreed. The DOI talks about this attribute in conjunction with ESP but >I guess it should be more explicit. I'll argue that it's not redundant because the base AH transform ID is simply AH_MD5 or AH_SHA. If we make this change, we'd have to define new transform ID's if we ever decide to use something other than HMAC. There's also something to be said for keeping the AH and ESP definitions symmetric. Nonetheless, if there's a concensus that this is overly complicated, I'll remove the mandatory AH attribute statement in the next version of the DOI. Derrell From owner-ipsec Tue Jun 10 15:05:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13189 for ipsec-outgoing; Tue, 10 Jun 1997 15:00:24 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <6004.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 10 Jun 1997 14:44:22 -0400 To: William Allen Simpson From: Stephen Kent Subject: Re: users and connections Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, The term "connection-oriented integrity" is not really appropriate in the IPSEC environment, even when the anti-replay option is enabled. The fact that we may provide keying at a per-connection or per-user granularity does not, in itself, represent connection-oriented integrity. What we provide is data origin authentication and connectionless integrity, and anti-replay provides what might be termed "partial" sequence integrity. However, we don't treat out of order arrival to be an error, unless it represents a (real or potential) replay, so what we provide in IPSEC is not connection-oriented integrity (as per ISO 7498-2). However, if we have TCP operating above IPSEC, and we are employing integrity (with or without anti-replay) then we are supporting connection-oriented integrity provided by TCP, even though IPSEC is not providing this service per se. Steve From owner-ipsec Tue Jun 10 15:05:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13195 for ipsec-outgoing; Tue, 10 Jun 1997 15:00:29 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.1.32.19970604111336.00722ab8@pop3.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 10 Jun 1997 14:29:33 -0400 To: Rodney Thayer From: Stephen Kent Subject: Re: padding questions Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Rodney, The revised text in ESP will include a default padding description (as in the previous ESP I-D) and that can be used for traffic flow confidentiality padding even when the algorithm does not impose a padding requirement. We'll clarify the wording to make sure this is clear. Steve From owner-ipsec Tue Jun 10 15:05:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13194 for ipsec-outgoing; Tue, 10 Jun 1997 15:00:26 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199706051631.JAA09493@kebe.eng.sun.com> References: <6004.wsimpson@greendragon.com> from "William Allen Simpson" at Jun 5, 97 01:49:58 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 10 Jun 1997 14:51:58 -0400 To: Dan McDonald From: Stephen Kent Subject: Re: users and connections Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk The Security Architecture document (if we ever manage to get it out) pecifically requires that per-user SAs be supported when IPSEC is implemented within a system at a point where individual user identities are available. This excludes the requirement to provide this fine granularity keying in gateways or firewalls, in BITW devices, and leaves BITS in a gray area. Steve From owner-ipsec Tue Jun 10 18:05:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA14434 for ipsec-outgoing; Tue, 10 Jun 1997 18:03:59 -0400 (EDT) Date: Tue, 10 Jun 97 21:35:52 GMT From: "William Allen Simpson" Message-ID: <6018.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: users and connections Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, I cannot find a copy of ISO 7498-2 anywhere in the RFCs. Therefore, I don't have any idea what you are talking about. ISO 7498-2 is meaningless in the Internet context, and is not cited by our RFC. The term "connection" in the Internet has long (more than a decade, maybe even 2 decades) refered to a pair of ports, usually TCP ports. The term "connection" is the same used in Bellovin's paper that is cited. The text in RFC-1829 is about the need for integrity when combined with some other service. In that much we agree. Indeed, TCP is explicitly mentioned. It has been privately suggested that to avoid confusion, the word "session" could be substituted for "connection". Has some obscure ISO document mandated "session" for some other purpose as well? > From: Stephen Kent > The term "connection-oriented integrity" is not really appropriate > in the IPSEC environment, even when the anti-replay option is enabled. The > fact that we may provide keying at a per-connection or per-user granularity > does not, in itself, represent connection-oriented integrity. What we > provide is data origin authentication and connectionless integrity, and > anti-replay provides what might be termed "partial" sequence integrity. > However, we don't treat out of order arrival to be an error, unless it > represents a (real or potential) replay, so what we provide in IPSEC is not > connection-oriented integrity (as per ISO 7498-2). However, if we have TCP > operating above IPSEC, and we are employing integrity (with or without > anti-replay) then we are supporting connection-oriented integrity provided > by TCP, even though IPSEC is not providing this service per se. > WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Tue Jun 10 18:21:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA14534 for ipsec-outgoing; Tue, 10 Jun 1997 18:20:57 -0400 (EDT) Message-Id: <199706102228.AA147951692@relay.hp.com> To: Stephen Kent Cc: William Allen Simpson , ipsec@tis.com Subject: Re: users and connections In-Reply-To: kent's message of Tue, 10 Jun 1997 14:44:22 -0400. Date: Tue, 10 Jun 1997 18:28:09 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > However, if we have TCP operating above IPSEC, and we are employing > integrity (with or without anti-replay) then we are supporting > connection-oriented integrity provided by TCP, even though IPSEC is > not providing this service per se. This is true *if* the TCP connections are (somehow or other) "bound" to the IPSEC SA's (or, more correctly, since SA's may expire in the middle of a connection, the principals which "own" the SA's). - Bill From owner-ipsec Tue Jun 10 18:23:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA14582 for ipsec-outgoing; Tue, 10 Jun 1997 18:22:58 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <6018.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 10 Jun 1997 18:28:33 -0400 To: William Allen Simpson From: Stephen Kent Subject: Re: users and connections Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Gee, Bill, are you saying that if a concept isn't recorded in an RFC then you are ignorant of it? I thought you were a more broadly educated person that that ;-) Next you'll be suggesting that if one can't find a publication via a Yahoo or Alta Vista search, then the publication doesn't exist! ISO 7498-2 is a standard that, among other things, defines terminology for security services. A few years back the PSRG produced an I-D that reproduced much of that terminology and set it in the TCP/IP context, but the I-D never generated much interest and thus was not pursued to RFC status. Still, the terminology is often used in technical literature in the network security field and is thoroughly applicable in the TCP/IP environment. And yes, Bill, "session" is also a term that has other meanings in both the ISO and TCP/IP worlds, e.g., a "telnet session" or a "session layer protocol." I don't see a need to invent new terminology here; I think one can express what you are trying to say in a fashion consistent with the existing terminology. It will just take more than a terse phrase to do so. Steve From owner-ipsec Tue Jun 10 18:31:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA14634 for ipsec-outgoing; Tue, 10 Jun 1997 18:31:03 -0400 (EDT) Message-Id: <199706102238.AA160902282@relay.hp.com> To: "William Allen Simpson" Cc: ipsec@tis.com Subject: Re: users and connections In-Reply-To: wsimpson's message of Tue, 10 Jun 1997 21:35:52 +0000. <6018.wsimpson@greendragon.com> Date: Tue, 10 Jun 1997 18:38:01 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, I think the concept you're trying to find a name for might best be described as "per-connection keying" or "per-connection SA's" - Bill From owner-ipsec Tue Jun 10 22:16:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA15887 for ipsec-outgoing; Tue, 10 Jun 1997 22:15:30 -0400 (EDT) Date: Wed, 11 Jun 97 01:35:29 GMT From: "William Allen Simpson" Message-ID: <6019.wsimpson@greendragon.com> To: ipsec@tis.com Subject: users and connections a futile waste of time Sender: owner-ipsec@ex.tis.com Precedence: bulk While taking a nice lovely long walk with the ex, prior to visiting my parents for my 40th tomorrow, I had a twinge of memory. I came home to check the Bellovin paper "Problem Areas for the IP Security Protocols", and sure enough, there it was.... Bellovin states that the primary defense is "per-connection or per-user keying". He relies on "the authentication transforms [to] protect the integrity of the message". Now, Kent states: > The term "connection-oriented integrity" is not really appropriate > in the IPSEC environment, even when the anti-replay option is enabled. The > fact that we may provide keying at a per-connection or per-user granularity > does not, in itself, represent connection-oriented integrity. OK, assuming that both Bellovin and Kent are using the same terminology, this says that we really cannot use IP Security in the attack scenarios outlined by Bellovin. And sure enough, Bellovin, in his final paper, opines: "These attacks and recommendations ... leave us feeling very nervous about network layer encryption. ... We suggest that its use be restricted to the following situations: "1. Router-to-router encryption to provide virtual private networks, in conjunction with a firewall.... "2. [A] tunnel from a mobile machine to its firewall.... "3. Possibly between two single user hosts.... "For more general use, we recommend moving towards [sic] the cryptographic processing towards the transport layer." I remember old messages from Karn and JI recommending the same thing nearly 5 years ago. IP Security was never intended to be used for communications between machines with "mutually suspicious" users. Now, somebody explain why we wasted 4 years trying to shoe-horn in user and connection oriented integrity? And please explain why we wasted the past 2 years arguing about integrity and ESP transforms, when it is unneeded for the above 3 scenarios? AH would serve just as well.... WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Tue Jun 10 23:25:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA16204 for ipsec-outgoing; Tue, 10 Jun 1997 23:24:38 -0400 (EDT) Message-Id: <199706110331.XAA14833@codex.cis.upenn.edu> To: "William Allen Simpson" cc: ipsec@tis.com Subject: Re: users and connections a futile waste of time In-reply-to: Your message of "Wed, 11 Jun 1997 01:35:29 GMT." <6019.wsimpson@greendragon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29289.865999577.1@dsl.cis.upenn.edu> Date: Tue, 10 Jun 1997 23:26:17 +0100 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <6019.wsimpson@greendragon.com>, "William Allen Simpson" writes: > >OK, assuming that both Bellovin and Kent are using the same terminology, >this says that we really cannot use IP Security in the attack scenarios >outlined by Bellovin. What IPsec provides is packet-flow integrity. Given a TCP endpoint pair (address1, port1, address2, port2), it is possible to map a packet flow to a tcp connection and vice versa (meaning that only packets of that connection will use the negotiated SAs, and that if both peers do that, all packets using that SA will belong to this TCP connection only). What this leaves us with is attacks before or after the endpoints are established or teared down respectively. Before: process binds to port, asks for an SA; before SA is established, process is killed and another process binds to the same port. Given a badly designed system, the second process could end up using the first one's SA. This can be avoided by the operating system "locking" ports for which a negotiation is taking place, destroying the resulting SA, then unlocking the port (by lock i mean make it unavailable for binding to). A second attack is possible as a race condition if a process can ask for an SA for a port that it has not bound to yet; this would be both a strange way of doing things and extremely bad practice on the application programmer's side. After: process exits; another process binds to same port, then replays traffic or otherwise uses existing SA. Obviously, this can be avoided if the operating system destroys the SA as soon as the socket is closed (or shutdown). The same holds for UDP. The model breaks somewhat for ICMP, but why someone would want to send confidential information using ICMP *and* worry about hostile users reading them is beyond me. Given these rather modest expectations from an operating system, i don't see how even hostile users with no unusual priviledges (such as being able to read the kernel memory) can read each other's traffic or do other attacks. Or am i missing something here ? Cheers, -Angelos From owner-ipsec Wed Jun 11 16:55:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA22408 for ipsec-outgoing; Wed, 11 Jun 1997 16:42:22 -0400 (EDT) Message-Id: <3.0.1.32.19970611164817.007796b4@ranier.altavista-software.com> X-Sender: altapop@ranier.altavista-software.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 11 Jun 1997 16:48:17 -0400 To: ipsec@tis.com From: Matt Thomas Subject: draft-simpson-esp-des3-x-01.txt In-Reply-To: <5941.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk In section 1.3, Initialization Vector. The IV is defined for SAs with negotiated keys as based on the SPI and replay counter: When dynamically configured via a key management protocol, the 64-bit IV is generated from the 32-bit SPI field followed by (concatenated with) the 32-bit Sequence Number field. The bit-wise complement of the 32-bit Sequence Number value is XOR'd with the first 32-bits (SPI). My question is why? I read the security notes but I still can't figure out the above is specified. Both the RC5 and CAST ESP drafts use a pseudo-random IV which is discarded. That's makes much more sense to me. By defining the 3DES IV as above, doesn't this give an attacker a really good source of plaintext to try to crack the keys? Am I missing something fundamental here? -- Matt Thomas Internet: matt.thomas@altavista-software.com Internet Locksmith WWW URL: AltaVista Internet Software Disclaimer: This message reflects my own Littleton, MA warped views, etc. From owner-ipsec Thu Jun 12 12:52:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA29210 for ipsec-outgoing; Thu, 12 Jun 1997 12:51:06 -0400 (EDT) Date: Thu, 12 Jun 97 16:02:20 GMT From: "William Allen Simpson" Message-ID: <6023.wsimpson@greendragon.com> To: ipsec@tis.com Subject: users and connections definitions Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Stephen Kent > Gee, Bill, are you saying that if a concept isn't recorded in an > RFC then you are ignorant of it? I thought you were a more broadly > educated person that that ;-) Next you'll be suggesting that if one can't > find a publication via a Yahoo or Alta Vista search, then the publication > doesn't exist! > Yep! I firmly believe that all IETF material should be on-line, or at least accessible at the local university library. I even went out and got a copy of the ancient Voydock-Kent '83.... Cannot do that with an ISO document. If we didn't reference an ISO document in the RFC, then we didn't expect anyone to read it to understand the work. > ISO 7498-2 is a standard that, among other things, defines > terminology for security services. A few years back the PSRG produced an > I-D that reproduced much of that terminology and set it in the TCP/IP > context, but the I-D never generated much interest and thus was not pursued > to RFC status. ISO 7498-2 is probably a piece of the usual ISO inaccessible ponderous verbiage, written largely to generate revenue. Publication does not a "standard" make. If PSRG produced an I-D, and it didn't get much interest, then there was a problem with the writing. Produce a readable document, and reference it in all the IPSec documents. In fact, I'd make that your highest priority! WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Thu Jun 12 12:52:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA29209 for ipsec-outgoing; Thu, 12 Jun 1997 12:51:05 -0400 (EDT) Date: Thu, 12 Jun 97 16:24:26 GMT From: "William Allen Simpson" Message-ID: <6024.wsimpson@greendragon.com> To: ipsec@tis.com Subject: calculating IVs Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Matt Thomas > The IV is defined for SAs with negotiated keys as based on the > SPI and replay counter: > > When dynamically configured via a key management protocol, the 64-bit > IV is generated from the 32-bit SPI field followed by (concatenated > with) the 32-bit Sequence Number field. The bit-wise complement of > the 32-bit Sequence Number value is XOR'd with the first 32-bits > (SPI). > > My question is why? I read the security notes but I still can't figure > out the above is specified. A really thorough explanation takes several pages. I'm working on a "white paper" to collect the previous discussion. Suffice it to say, that was the _compromise_ reached over a year ago. It was the second compromise method. It is a little stronger than the first compromise reached over 2 years ago, described in RFC-1829 and RFC-1851. One of the problems with this group is no decision stands for more than a year. And everything has to be explained all over again to each new person, such as yourself. The "best" method would be to key DES-OFB over SPI+Sequence and use that for the IV. Easy in software, but the hardware manufacturers griped that would cause 2 chip invocations, and slow down their implementations. However, since then it has appeared that the "best" method can be done with 1 invocation in CBC mode, and then replace the generated ciphertext in the packet with the original SPI+Sequence. Simple. Elegant. I would be willing to change. Ask the vendors that implemented RFC-1851 if they would be willing to change.... > Both the RC5 and CAST ESP drafts use a > pseudo-random IV which is discarded. That's makes much more sense to me. Bad choice. Go read "Abusing IVs" in "Problem Areas for the IP Security Protocols" [Bellovin95, 96]. Or the referenced Voydock-Kent83. > By defining the 3DES IV as above, doesn't this give an attacker a really > good source of plaintext to try to crack the keys? > > Am I missing something fundamental here? Yes. Both methods provide exactly the same amount (64-bits) of known text. The IV is XOR'd with the first plaintext block before encrypting. Therefore, the IV isn't really plaintext on its own, as any good encryption algorithm will sufficiently obscure the result. A separate IV allows potential for changing bits in the first block. Particularly bad for UDP without checksums. Using the SPI and/or Sequence causes the packet to be misdirected or discarded if the SPI or Sequence are changed. Much better protection. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Thu Jun 12 18:47:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA01259 for ipsec-outgoing; Thu, 12 Jun 1997 18:44:14 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <6023.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Jun 1997 18:50:13 -0400 To: William Allen Simpson From: Stephen Kent Subject: Re: users and connections definitions Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, >Yep! I firmly believe that all IETF material should be on-line, or at >least accessible at the local university library. > >I even went out and got a copy of the ancient Voydock-Kent '83.... > >Cannot do that with an ISO document. If we didn't reference an ISO >document in the RFC, then we didn't expect anyone to read it to >understand the work. We all assume various levels of background info in our writing, and not all of it is on-line. I'm flattered that you went to the trouble to locate one of my older publications, but if you had looked at more recent ones, you would have found the definitions in question. For example, in "The Internet System Handbook," edited by Dan Lynch and Marshall Rose (1993), I wrote a chapter entitled "Architectural Security" which captures these definitions and extends them to include some refinements that we developed during the PSRG work. Most of this is reproduced, in more concise form, in "Network and Internetwork Security," by William Stallings (1995). >> ISO 7498-2 is a standard that, among other things, defines >> terminology for security services. A few years back the PSRG produced an >> I-D that reproduced much of that terminology and set it in the TCP/IP >> context, but the I-D never generated much interest and thus was not pursued >> to RFC status. > >ISO 7498-2 is probably a piece of the usual ISO inaccessible ponderous >verbiage, written largely to generate revenue. Publication does not a >"standard" make. Well, I won't defend the quality of any organization's standards documents in general, including those of the IETF, but the relevent parts of 7498-2 are not badly written. And, in the case of ISO, publication does, technically, make it a standard (though it does not ensure adoption and deployment)! >If PSRG produced an I-D, and it didn't get much interest, then there was >a problem with the writing. Produce a readable document, and reference >it in all the IPSec documents. Actually, I think the PSRG I-D was well written, but did not advance because other matters were a higher priority. But, feel free to judge for you self. I'm sending an MS Word file that reproduces the essence of this work, in a newly edited form, that Rob Shirey developed for puiblication last year, via a separate message to you. >In fact, I'd make that your highest priority! Bill, when you get to set my priorities, it's time to find a new job! Steve From owner-ipsec Thu Jun 12 20:26:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA01744 for ipsec-outgoing; Thu, 12 Jun 1997 20:25:46 -0400 (EDT) Date: Thu, 12 Jun 97 23:42:09 GMT From: "William Allen Simpson" Message-ID: <6031.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: users and connections definitions Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Stephen Kent > >Cannot do that with an ISO document. If we didn't reference an ISO > >document in the RFC, then we didn't expect anyone to read it to > >understand the work. > > We all assume various levels of background info in our writing, and > not all of it is on-line. Maybe you do, but don't include me. I like well-defined RFCs. > Actually, I think the PSRG I-D was well written, but did not advance > because other matters were a higher priority. But, feel free to judge for > you self. I'm sending an MS Word file that reproduces the essence of this > work, in a newly edited form, that Rob Shirey developed for puiblication > last year, via a separate message to you. > I wondered what that 356 KB message was. Since I don't own MS Word, it's worse than useless, and I can safely toss it. Thanks, anyway, and let us know when the I-D comes out.... > Bill, when you get to set my priorities, it's time to find a new job! > Actually, it's about time. We need someone willing to revise the drafts to meet our implementors' consensus, with a turnaround time of something less than 2 months.... WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Fri Jun 13 07:47:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA05250 for ipsec-outgoing; Fri, 13 Jun 1997 07:41:49 -0400 (EDT) Message-ID: <01BC7754.9A699460@baiju.jf.intel.com> From: Baiju Patel To: "'ipsec@tis.com'" Subject: ISAKMP Oakley resolution and ipsec doi document questions Date: Thu, 12 Jun 1997 17:18:09 -0700 Sender: owner-ipsec@ex.tis.com Precedence: bulk 1. The ISAKMP/OAKLEY document specifies Quick Mode is defined as follows: Initiator Responder ----------- ----------- HDR*, HASH(1), SA, Ni [, KE ] [, IDui, IDur ] --> <-- HDR*, HASH(2), SA, Nr [, KE ] [, IDui, IDur ] HDR*, HASH(3) --> Does this mean that either both IDui and IDur must be specified or none. Or was it authors intention to specify Initiator Responder ----------- ----------- HDR*, HASH(1), SA, Ni [, KE ] [, IDui][,IDur ] --> <-- HDR*, HASH(2), SA, Nr [, KE ] [, IDui][, IDur ] HDR*, HASH(3) --> So that one or both IDui and IDur can be specified. Basically, I am curious on how will the initiator know the identity IDur if receiver is a proxy. 2. in the doi document, who's port number is specified in the identification payload? (initiator or reviver?) The protocol ID and port are also in the field marked reserved in the ISAKMP document. Is this intentional? In my view, this should be consistent. 3. draft-ietf-ipsec-isakmp-oakley-03.txt: The introduction states: This draft combines ISAKMP and Oakley. The purpose is to negotiate, and provide authenticated keying material for, security associations in a protected manner. Since this document is only applicable (to best of my understanding) to peer to peer communication (and not multicast), it may be a good idea to specify that clearly. ------------------------------------------- Baiju V. Patel, 503 264 2422 Internet Security Architect Intel Architecture Labs JF3-206 2111 N.E. 25th Avenue Hillsboro, OR 97124 From owner-ipsec Fri Jun 13 09:21:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA06046 for ipsec-outgoing; Fri, 13 Jun 1997 09:19:01 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <6031.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 Jun 1997 09:22:17 -0400 To: William Allen Simpson From: Stephen Kent Subject: Re: users and connections definitions Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, >> We all assume various levels of background info in our writing, and >> not all of it is on-line. > >Maybe you do, but don't include me. I like well-defined RFCs. For someone who purports to like well-defined (and presumably well-written) RFCs, the long series of Photuris I-Ds hardly serve as examplars. >> Actually, I think the PSRG I-D was well written, but did not advance >> because other matters were a higher priority. But, feel free to judge for >> you self. I'm sending an MS Word file that reproduces the essence of this >> work, in a newly edited form, that Rob Shirey developed for puiblication >> last year, via a separate message to you. >> >I wondered what that 356 KB message was. Since I don't own MS Word, >it's worse than useless, and I can safely toss it. Thanks, anyway, and >let us know when the I-D comes out.... I'll check with my co-author and see if he'd like to submit the document as an informational RFC, although the re-formatting effort argues against that. In your case I'd suggest holding your breath. Steve From owner-ipsec Fri Jun 13 21:00:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA09635 for ipsec-outgoing; Fri, 13 Jun 1997 20:56:33 -0400 (EDT) Message-Id: <199706132012.QAA03014@relay.rv.tis.com> Date: Fri, 13 Jun 97 15:43:26 EDT From: Karen Seo To: ipsec@tis.com cc: kseo@bbn.com Subject: AH/ESP loose ends Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, Here are some additional issues/edits based on feedback from the community since our June 6 email on "AH/ESP edits". Please let us know your opinions on the open issues below by Friday the 20th (6/20/97). Thank you, Karen OPEN ISSUES ----------- 1. In a private message, someone raised the concern that some routers may move and/or insert IP options, e.g., for 4-byte alignment. If so, this would conflict with the use of AH. Can anyone confirm or deny this rumor? 2. Re: defining how to handle mutable/immutable IPv4 and IPv6 fields for the purpose of AH ICV calculation... We received feedback requesting clarification on how to handle IPv4 options that aren't explicitly listed in the text. We were thinking of including the table below (along with similar information for IPv6 options and extension headers) in an Appendix to the AH document. We view creating a separate document as the cleanest approach, as it best accommodates the creating of new options/extension headers, but realize that it might further delay the process and so we offer the appendix solution as a compromise. In any case we believe that an explicit listing of options (and extensions for IPv6) is needed to avoid confusion. We've included below the rewritten section 3.2.3, "Integrity Check Value Calculation", which explicitly categorizes the IP base header fields into immutable, mutable but predictable, and mutable. We have then included the Appendix proposed above under "Open Issues" that lists the IPv4 Options and IPv6 Options and Extension Headers. ESP --- 1. In section 2.4, "Padding (for Encryption)" -- some concerns were expressed about whether this section clearly describes how to determine the padding values (a default that can be overridden by the algorithm in its RFC) and that this field can be used for traffic flow confidentiality padding even when the algorithm does not impose a padding requirement. This section now reads: 2.4 Padding (for Encryption) If an encryption algorithm is employed that requires the plaintext to be a multiple of some number of bytes, e.g., the block size of a block cipher, the Padding field is used to fill the plaintext (consisting of the Payload Data, Pad Length and Next Header fields, as well as the Padding) to the size required by the algorithm. As a default, the Padding bytes SHOULD be initialized with random data and they are transmitted. The transmitter can add 0-255 bytes of padding. Any encryption algorithm used with ESP that requires a padding value other than the default value MUST define its padding requirements in an RFC specifying how the algorithm is used with ESP. The content of the Padding field will thus be determined by the encryption algorithm and mode selected and defined in the corresponding algorithm RFC. Padding also may be required, irrespective of algorithm requirements, to ensure that the resulting ciphertext terminates on a 4-byte boundary, i.e., the Pad Length and Next Header fields must be right aligned within a 4-byte word, as illustrated in the ESP packet format figure. Finally, padding beyond that required for the algorithm or alignment reasons cited above, may be used to conceal the actual length of the payload, in support of (partial) traffic flow confidentiality. However, inclusion of such additional padding has adverse bandwidth implications and thus its use should be undertaken with care. The Padding field is optional, but all implementations MUST support generation and consumption of padding. 2. In section 2.3, "Payload Data", changed the sentence "If the algorithm used to encrypt the payload requires cryptographic synchronization data, e.g., an IV..." to "If the algorithm used to encrypt the payload requires cryptographic synchronization data, e.g., an Initialization Vector (IV)..." 3. In section 2, "Encapsulating Security Payload Packet Format", added a footnote to the diagram that says, "If included in the Payload field, cryptographic synchronization data, e.g., an IV, usually is not encrypted per se, although it often is referred to as being part of the ciphertext." AH -- 1. In section 3.2.3, "Integrity Check Value Calculation", clarified that for Loose and Strict Source Routing (IPv4 and IPv6), the destination address is mutable but predictable. 2. Re: router alert option -- It should be noted that if this option is used, the option is immutable, but it means that each router will "process" the packet, i.e., might change the packet. This would happen on a hop by hop basis as the packet goes from router to router. But in order to reach the higher layer that's doing the processing, e.g., RSVP/IGMP, the packet has to go through IPSEC processing first. But the routers along the way won't have an SA with an SPI for this packet (just the endpoint of the SA will have this information). So IPSEC might not be appropriate for users of this option. We propose to call the option immutable, insert a note to the reader warning about this problem. 3. In section 3.2.3, Integrity Check Value Calculation, we've rewritten this text to explicitly categorize the IP header fields into immutable, mutable but predictable, and mutable (see below). We have then included the Appendix proposed above under "Open Issues". 4. In section 3.2.3.1, we've clarified that "...the zero-fill approach ensures that the length of the fields that are so handled cannot be changed during transit, even though their contents are not explicitly covered by the ICV." ---------------------------------------------------------------------------- As mentioned under "Open Issues" above, we've appended below the rewritten section 3.2.3, "Integrity Check Value Calculation", which explicitly categorizes the IP base header fields into immutable, mutable but predictable, and mutable. We have then included the Appendix proposed above under "Open Issues" that lists the IPv4 Options and IPv6 Options and Extension Headers. 3.2.3 Integrity Check Value Calculation 3.2.3.1 Handling Mutable Fields The AH ICV is computed over IP header fields that are either immutable in transit or that are predictable in value upon arrival at the endpoint for the AH SA. The ICV also encompasses the upper level protocol data, which is assumed to be immutable in transit. If a field is modified during transit, the value of the field is set to zero for purposes of the ICV computation. If a field is mutable, but its value at the (IPsec) receiver is predictable, then that value is inserted into the field for purposes of the ICV calculation. The Authentication Data field also is set to zero in preparation for this computation. Note that by replacing each field's value with zero, rather than omitting the field, alignment is preserved for the ICV calculation. Also, the zero-fill approach ensures that the length of the fields that are so handled cannot be changed during transit, even though their contents are not explicitly covered by the ICV. 3.2.3.1.1 ICV Computation for IPv4 3.2.3.1.1.1 Base Header Fields The IPv4 base header fields are classified as follows: Immutable Version Internet Header Length Total Length Identification Protocol Source Address Destination Address (without loose or strict source routing) Mutable but predictable Destination Address (with loose or strict source routing) Mutable (zeroed prior to ICV calculation) Type of Service (TOS) Flags Fragment Offset Time to Live (TTL) Header Checksum TOS -- This field is excluded because some routers are known to change the value of this field, even though the IP specification does not consider TOS to be a mutable header field. Flags -- This field is excluded since an intermediate router might set the DF bit, even if the source did not select it. Fragment Offset -- Since AH is applied only to non-fragmented IP packets, the Offset Field must always be zero, and thus it is excluded (even though it is predictable). TTL -- This is changed en-route as a normal course of processing by routers, and thus its value at the receiver is not predictable by the sender. Header Checksum -- This will change if any of these other fields changes, and thus its value upon reception cannot be predicted by the sender. 3.2.3.1.1.2 Options For IPv4 (unlike IPv6), there is no mechanism for tagging options as mutable in transit. Hence the IPv4 options are explicitly listed in Appendix A and classified as immutable, mutable but predictable, or mutable. For IPv4, the entire option is viewed as a unit; so even though the type and length fields within most options are immutable in transit, if an option is classified as mutable, the entire option is zeroed for ICV computation purposes. 3.2.3.1.2 ICV Computation for IPv6 3.2.3.1.2.1 Base Header Fields The IPv6 base header fields are classified as follows: Immutable Version Payload Length Next Header Source Address Destination Address (without Routing Extension Header) Mutable but predictable Destination Address (with Routing Extension Header) Mutable (zeroed prior to ICV calculation) Priority Flow Label Hop Limit 3.2.3.1.2.2 Extension Headers -- Options The IPv6 extension headers (that are options) are explicitly listed in Appendix A and classified as immutable, mutable but predictable, or mutable. IPv6 options in the Hop-by-Hop and Destination Extension Headers contain a bit that indicates whether the option might change (unpredictably) during transit. For any option for which contents may change en-route, the entire "Option Data" field must be treated as zero-valued octets when computing or verifying the ICV. The Option Type and Opt Data Len are included in the ICV calculation. All options for which the bit indicates immutability are included in the ICV calculation. See the IPv6 specification [DH95] for more information. 3.2.3.1.2.3 Extension Headers -- non-Options The IPv6 extension headers (that are not options) are explicitly listed in Appendix A and classified as immutable, mutable but predictable, or mutable. ---------------------------------------------------------------------------- Appendix A 1. IPv4 Options This table shows how the IPv4 options are classified with regard to "mutability". Where two references are provided, the second one supercedes the first. This table is based in part on information provided in RFC1700, "ASSIGNED NUMBERS", (October 1994). Option Copy Class Number Name Reference ---- ----- ------ ---------------------- --------- IMMUTABLE -- included in ICV calculation 0 0 0 End of Options List [RFC791] 0 0 1 No Operation [RFC791] 1 0 2 Security [RFC1108(historic but in use)] 1 0 5 Extended Security [RFC1108(historic but in use)] 1 0 6 Commercial Security [expired I-D, now US MIL STD] 1 0 20 Router Alert [RFC2113] 1 0 21 Sender Directed Multi- [RFC1770] Destination Delivery MUTABLE -- zeroed 1 0 3 Loose Source Route [RFC791] 0 2 4 Time Stamp [RFC791] 0 0 7 Record Route [RFC791] 1 0 9 Strict Source Route [RFC791] 0 2 18 Traceroute [RFC1393] EXPERIMENTAL, SUPERCEDED -- zeroed 1 0 8 Stream ID [RFC791, RFC1122 (Host Req)] 0 0 11 MTU Probe [RFC1063, RFC1191 (PMTU)] 0 0 12 MTU Reply [RFC1063, RFC1191 (PMTU)] 1 0 17 Extended Internet Protocol [RFC1385, RFC1883 (IPv6)] 0 0 10 Experimental Measurement [ZSu] 1 2 13 Experimental Flow Control [Finn] 1 0 14 Experimental Access Control [Estrin] 0 0 15 ??? [VerSteeg] 1 0 16 IMI Traffic Descriptor [Lee] 1 0 19 Address Extension [Ullmann IPv7] 2. IPv6 Extension Headers Option/Extension Name Reference --------------------- --------- MUTABLE BUT PREDICTABLE Routing (Type 0) [RFC1883] BIT INDICATING IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING TRANSIT) Hop by Hop options [RFC1883] Destination options [RFC1883] NOT APPLICABLE Fragmentation [RFC1883] Options -- IPv6 options in the Hop-by-Hop and Destination Extension Headers contain a bit that indicates whether the option might change (unpredictably) during transit. For any option for which contents may change en-route, the entire "Option Data" field must be treated as zero-valued octets when computing or verifying the ICV. The Option Type and Opt Data Len are included in the ICV calculation. All options for which the bit indicates immutability are included in the ICV calculation. See the IPv6 specification [DH95] for more information. Routing (Type 0) -- The IPv6 Routing Header "Type 0" will rearrange the address fields within the packet during transit from source to destination. However, the contents of the packet as it will appear at the receiver are known to the sender and to all intermediate hops. Hence, the IPv6 Routing Header "Type 0" is included in the Authentication Data calculation as mutable but predictable. The transmitter must order the field so that it appears as it will at the receiver, prior to performing the ICV computation. Fragmentation -- Fragmentation occurs after outbound IPSEC processing (section 3.2.4) and reassembly occurs before inbound IPSEC processing (section 3.3.1). So the Fragmentation Extension Header, if it exists, is not seen by IPSEC. From owner-ipsec Fri Jun 13 21:00:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA09657 for ipsec-outgoing; Fri, 13 Jun 1997 20:57:35 -0400 (EDT) Message-Id: <199706131912.PAA07029@codex.cis.upenn.edu> To: Stephen Kent cc: William Allen Simpson , ipsec@tis.com Subject: Re: users and connections definitions In-reply-to: Your message of "Fri, 13 Jun 1997 09:22:17 EDT." Date: Fri, 13 Jun 1997 15:10:01 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In message , Stephen Kent writes: >>Maybe you do, but don't include me. I like well-defined RFCs. > >For someone who purports to like well-defined (and presumably well-written) >RFCs, the long series of Photuris I-Ds hardly serve as examplars. As one of the Photuris implementors, i have to say that: a) writing a draft for a key management protocol is not as easy as you might think b) Bill has always been responsive to all comment i (and others) made on the draft(s) - the changes take place in less than a week, sometimes one or two days. That's better than i can say for others. c) at this point, the Photuris drafts are much more readable than the ISAKMP/Oakley ones d) the Photuris and the ISAKMP drafts are both a lot of pages. Yet, compared to the rest of the IPsec drafts, they seem to be progressing really well - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBM6GbCL0pBjh2h1kFAQGSkQP/YPFIh1YWP2OtnGspTj5Ti/iuSkLIvXod E6YG31rMr0QJxv75E0S7h+dy0fpQHJCRSjAO4jeiwZz0pN+a7pcOekWo2Cz7/wg+ FeEGkvVg6cNoPfiXjDVlxIPIT2n1cORrAcR+fHBNUoKeTlIcpgElaqrhDlDBbv9s gkFgTEZMh64= =/NZH -----END PGP SIGNATURE----- From owner-ipsec Fri Jun 13 21:00:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA09656 for ipsec-outgoing; Fri, 13 Jun 1997 20:57:35 -0400 (EDT) Message-Id: <01BC780F.30DF14A0@erussell-1.ftp.com> From: "Edward A. Russell" To: "'baiju@ideal.jf.intel.com'" , "'ipsec@tis.com'" Subject: RE: ISAKMP Oakley resolution and ipsec doi document questions Date: Fri, 13 Jun 1997 15:33:48 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Baiju Patel (baiju@ideal.jf.intel.com) said on 6/13/97 at 8:11 AM > >1. The ISAKMP/OAKLEY document specifies > > Quick Mode is defined as follows: > > Initiator Responder > ----------- ----------- > HDR*, HASH(1), SA, Ni > [, KE ] [, IDui, IDur ] --> > <-- HDR*, HASH(2), SA, Nr > [, KE ] [, IDui, IDur ] > HDR*, HASH(3) --> > >Does this mean that either both IDui and IDur must be specified >or none. Or was it authors intention to specify > > > Initiator Responder > ----------- ----------- > HDR*, HASH(1), SA, Ni > [, KE ] [, IDui][,IDur ] --> > <-- HDR*, HASH(2), SA, Nr > [, KE ] [, IDui][, IDur ] > HDR*, HASH(3) --> >So that one or both IDui and IDur can be specified. >Basically, I am curious on how will the initiator know >the identity IDur if receiver is a proxy. I belieive the assumption is you must specify both or neither. The initiator should know the IDur identity even if the receiver (isakmp peer) is a proxy because the initiator presumbably knows who he want to ultimately connect to. It is up to the initiator to tell the responder who the ultimate destination (IDur) is going to be and therefor who this SA is going to be used for. > >2. in the doi document, who's port number is specified in >the identification payload? (initiator or reviver?) >The protocol ID and port are also in the field marked >reserved in the ISAKMP document. Is this intentional? >In my view, this should be consistent. The port is 500 for sending The port is 500 for receiving The port is 500 ONLY. I believe this came out of Memphis. > >3. draft-ietf-ipsec-isakmp-oakley-03.txt: > The introduction states: >This draft combines ISAKMP and Oakley. The purpose is to negotiate, > and provide authenticated keying material for, security associations > in a protected manner. > >Since this document is only applicable (to best of my understanding) >to peer to peer communication (and not multicast), it may be a good idea to > specify that clearly. Edward Russell erussell@ftp.com From owner-ipsec Fri Jun 13 21:37:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA09913 for ipsec-outgoing; Fri, 13 Jun 1997 21:37:05 -0400 (EDT) Date: Sat, 14 Jun 97 01:34:28 GMT From: "William Allen Simpson" Message-ID: <6039.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: users and connections definitions Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Stephen Kent > For someone who purports to like well-defined (and presumably well-written) > RFCs, the long series of Photuris I-Ds hardly serve as examplars. > Although this comment is insufficiently specific to make any sort of rebuttal, I will agree that once Photuris was gone from the WG, and we could safely remove all the cryptologic rationale (demanded by the "serious" but non-implementing "analysts") into a separate draft, it is a _lot_ more readable for real implementors. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Sat Jun 14 01:05:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA10849 for ipsec-outgoing; Sat, 14 Jun 1997 01:04:08 -0400 (EDT) Date: Fri, 13 Jun 1997 22:11:19 -0700 Message-Id: <199706140511.WAA13916@gump.eng.ascend.com> From: Karl Fox To: Karen Seo Cc: ipsec@tis.com Subject: AH/ESP loose ends In-Reply-To: <199706132012.QAA03014@relay.rv.tis.com> References: <199706132012.QAA03014@relay.rv.tis.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ipsec@ex.tis.com Precedence: bulk Karen Seo writes: > 1. In a private message, someone raised the concern that some routers > may move and/or insert IP options, e.g., for 4-byte alignment. If > so, this would conflict with the use of AH. Can anyone confirm or > deny this rumor? This was discussed extensively two years ago and nobody could come up with a supporting example, so the argument was discarded. In nearly two years of fielding and testing IPSEC-speaking products, I've never seen any such problem. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 From owner-ipsec Sat Jun 14 02:01:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA11075 for ipsec-outgoing; Sat, 14 Jun 1997 02:01:10 -0400 (EDT) Date: Sat, 14 Jun 1997 02:17:48 +0200 (DFT) From: Niels Provos To: ipsec@tis.com, photuris@starfury.services.soscorp.com Subject: [Announce] Photuris Implementation MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk An implementation of the Photuris keymanagement protocol according to the drafts: draft-simpson-photuris-12.txt draft-simpson-photuris-schemes-01.txt is available running on AIX, Solaris, Linux and OpenBSD. You can find the sources and the necessary libraries (gmp-2.0.2 and libdes-4.01) at http://www.physnet.uni-hamburg.de/provos/photuris/ At the moment only the PF_ENCAP kernel interface as found in John Ioannidis' and Angelos D. Keromytis' IPSec which is used in the OpenBSD kernel is supported. This software was written in Germany and thus USA export restrictions don't apply. Send any questions to provos@physnet.uni-hamburg.de Greetings Niels Provos - PHYSnet Rechnerverbund PGP V2.6 Public key via finger or key server Niels Provos Universitaet Hamburg WWW: http://www.physnet.uni-hamburg.de/provos/ Jungiusstrasse 9 E-Mail: provos@wserver.physnet.uni-hamburg.de Germany 20355 Hamburg Tel.: +49 40 4123-2404 Fax: -6571 From owner-ipsec Mon Jun 16 10:29:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA25520 for ipsec-outgoing; Mon, 16 Jun 1997 10:17:06 -0400 (EDT) Message-ID: From: Roy Pereira To: "'baiju@ideal.jf.intel.com'" , "'ipsec@tis.com'" , "'Edward A. Russell'" Subject: RE: ISAKMP Oakley resolution and ipsec doi document questions Date: Mon, 16 Jun 1997 10:26:19 -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 >> >>2. in the doi document, who's port number is specified in >>the identification payload? (initiator or reviver?) >>The protocol ID and port are also in the field marked >>reserved in the ISAKMP document. Is this intentional? >>In my view, this should be consistent. > >The port is 500 for sending >The port is 500 for receiving >The port is 500 ONLY. >I believe this came out of Memphis. This change was due to some implementations only accepting ISAKMP exchanges if both the source and destination ports were 500. > From owner-ipsec Mon Jun 16 17:34:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA28169 for ipsec-outgoing; Mon, 16 Jun 1997 17:31:51 -0400 (EDT) Message-Id: <199706161756.KAA25201@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: "Edward A. Russell" Cc: "'baiju@ideal.jf.intel.com'" , "'ipsec@tis.com'" Subject: Re: ISAKMP Oakley resolution and ipsec doi document questions In-Reply-To: Your message of "Fri, 13 Jun 1997 15:33:48 EDT." <01BC780F.30DF14A0@erussell-1.ftp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 16 Jun 1997 10:56:27 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Edward A. Russell wrote: > Baiju Patel (baiju@ideal.jf.intel.com) said on 6/13/97 at 8:11 AM > >2. in the doi document, who's port number is specified in > >the identification payload? (initiator or reviver?) > >The protocol ID and port are also in the field marked > >reserved in the ISAKMP document. Is this intentional? > >In my view, this should be consistent. > > The port is 500 for sending > The port is 500 for receiving > The port is 500 ONLY. > I believe this came out of Memphis. I think he was asking about the protocol and port fields in the ID payload (right Baiju?). I think those fields are really only of interest in phase II when used as proxy id's. In that case the ID would be the protocol and port of the intended service. Example, if I'm telnetting to ideal.jf.intel.com the ID type of IDur would be ID_FQDN, the protocol would be TCP, the port would be 23, and the identification data would be ideal.jf.intel.com. And you're right. The documents should be consistent. Next rev they will be. Dan. From owner-ipsec Mon Jun 16 18:22:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA28383 for ipsec-outgoing; Mon, 16 Jun 1997 18:20:27 -0400 (EDT) Message-ID: From: Roy Pereira To: Roy Pereira , "'ipsec@tis.com'" , "'Edward A. Russell'" , "'Baiju Patel'" Subject: RE: ISAKMP Oakley resolution and ipsec doi document questions Date: Mon, 16 Jun 1997 14:38:47 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > >I am confused. If port is 500 only, why are >we specifying it at all. It looks like this port >has nothing to do with identification. > >Let me try to understand. If I implement ISAKMP >and not want to use port 500, but say use port >2000, could I use the port field to indicate to the >receiver that the reply must be sent to port 2000 >(I do not think this is the case, because the first >message of main mode exchange does not include >ID at all). > The port in the ID payload is only used for identification and not for the ISAKMP protocol. ISAKMP always uses port 500. The port field in the ID payload identifies the application (or protocol) that is requesting the SA. The port and protocol fields are relative to the user information in the ID payload's data. So it is used to refine the identity. From owner-ipsec Tue Jun 17 07:32:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA03078 for ipsec-outgoing; Tue, 17 Jun 1997 07:29:18 -0400 (EDT) Message-ID: <01BC7A3C.60B607E0@baiju.jf.intel.com> From: Baiju Patel To: "'Roy Pereira'" , "'ipsec@tis.com'" , "'Edward A. Russell'" Subject: RE: ISAKMP Oakley resolution and ipsec doi document questions Date: Mon, 16 Jun 1997 10:02:18 -0700 Sender: owner-ipsec@ex.tis.com Precedence: bulk I am confused. If port is 500 only, why are we specifying it at all. It looks like this port has nothing to do with identification. Let me try to understand. If I implement ISAKMP and not want to use port 500, but say use port 2000, could I use the port field to indicate to the receiver that the reply must be sent to port 2000 (I do not think this is the case, because the first message of main mode exchange does not include ID at all). Baiju -----Original Message----- From: Roy Pereira [SMTP:rpereira@TimeStep.com] Sent: Monday, June 16, 1997 7:26 AM To: 'baiju@ideal.jf.intel.com'; 'ipsec@tis.com'; 'Edward A. Russell' Subject: RE: ISAKMP Oakley resolution and ipsec doi document questions >> >>2. in the doi document, who's port number is specified in >>the identification payload? (initiator or reviver?) >>The protocol ID and port are also in the field marked >>reserved in the ISAKMP document. Is this intentional? >>In my view, this should be consistent. > >The port is 500 for sending >The port is 500 for receiving >The port is 500 ONLY. >I believe this came out of Memphis. This change was due to some implementations only accepting ISAKMP exchanges if both the source and destination ports were 500. From owner-ipsec Tue Jun 17 07:32:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA03086 for ipsec-outgoing; Tue, 17 Jun 1997 07:30:18 -0400 (EDT) Message-ID: <01BC7A3B.E8662A40@baiju.jf.intel.com> From: Baiju Patel To: "'Edward A. Russell'" , "'ipsec@tis.com'" Subject: RE: ISAKMP Oakley resolution and ipsec doi document questions Date: Mon, 16 Jun 1997 09:58:56 -0700 Sender: owner-ipsec@ex.tis.com Precedence: bulk Edward, There are two specific scenarios using proxies for IPSEC. 1. A host wants to initiate a connection to another host, and a proxy host in the middle handles IPSEC for it This is the case addressed in your response. Typically, (but not necessarily), this would be for accessing intranet over a firewall by an host on the internet. 2. A host (daemon) wants to accept connections from other hosts and there is a proxy which needs to establish an authenticated IPSEC connection to the host before it allows traffic to/from it. Here is an example. I have a web server www on the intranet. For many pragmatic reasons, I do not want to put this web server in the DMZ. This web server wants to request the firewall that it be allowed to communicate with any external host. The way firewall can ensure this (and stop other intranet hosts from using IP address of www to send unauthorized traffic out), is to establish IPSEC AH or ESP SA between www and firewall and use it. The firewall will varify that all the packets leaving the site are from www and no one else. Similarly, all the packets entering the Intranet to www are (for example encrypted) so that know one can spoof them. (In some ways, this type of fuctionality is supported by socks). In this example, host www will establish an IPSEC AH or ESP SA. However, the firewall will not know the identity IDur until some external host attempts to connect to www. Therefore, I would suggest that we do not mandate that IDui and IDur must be specified at the same time. One alternative is to use 0.0.0.0 as ID when you do not know the ID (since it provides such a limited value why bother sending it). Therefore, it is my openion that IDur and IDii should not be tied together (which leads to a question on how to differentiate between the two!). Baiju -----Original Message----- From: Edward A. Russell [SMTP:erussell@ftp.com] Sent: Friday, June 13, 1997 12:34 PM To: 'baiju@ideal.jf.intel.com'; 'ipsec@tis.com' Subject: RE: ISAKMP Oakley resolution and IPSEC DOI document questions Baiju Patel (baiju@ideal.jf.intel.com) said on 6/13/97 at 8:11 AM > >1. The ISAKMP/OAKLEY document specifies > > Quick Mode is defined as follows: > > Initiator Responder > ----------- ----------- > HDR*, HASH(1), SA, Ni > [, KE ] [, IDui, IDur ] --> > <-- HDR*, HASH(2), SA, Nr > [, KE ] [, IDui, IDur ] > HDR*, HASH(3) --> > >Does this mean that either both IDui and IDur must be specified >or none. Or was it authors intention to specify > > > Initiator Responder > ----------- ----------- > HDR*, HASH(1), SA, Ni > [, KE ] [, IDui][,IDur ] --> > <-- HDR*, HASH(2), SA, Nr > [, KE ] [, IDui][, IDur ] > HDR*, HASH(3) --> >So that one or both IDui and IDur can be specified. >Basically, I am curious on how will the initiator know >the identity IDur if receiver is a proxy. I belieive the assumption is you must specify both or neither. The initiator should know the IDur identity even if the receiver (isakmp peer) is a proxy because the initiator presumbably knows who he want to ultimately connect to. It is up to the initiator to tell the responder who the ultimate destination (IDur) is going to be and therefor who this SA is going to be used for. > >2. in the doi document, who's port number is specified in >the identification payload? (initiator or reviver?) >The protocol ID and port are also in the field marked >reserved in the ISAKMP document. Is this intentional? >In my view, this should be consistent. The port is 500 for sending The port is 500 for receiving The port is 500 ONLY. I believe this came out of Memphis. > >3. draft-ietf-ipsec-isakmp-oakley-03.txt: > The introduction states: >This draft combines ISAKMP and Oakley. The purpose is to negotiate, > and provide authenticated keying material for, security associations > in a protected manner. > >Since this document is only applicable (to best of my understanding) >to peer to peer communication (and not multicast), it may be a good idea to > specify that clearly. Edward Russell erussell@ftp.com From owner-ipsec Tue Jun 17 07:40:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA03265 for ipsec-outgoing; Tue, 17 Jun 1997 07:40:21 -0400 (EDT) Message-ID: <01BC7A76.7DBE89E0@baiju.jf.intel.com> From: Baiju Patel To: "'Chris Boscolo'" Cc: "'ipsec'" Subject: RE: Security considerations for L2TP (one last try)! Date: Mon, 16 Jun 1997 16:58:16 -0700 Sender: owner-ipsec@ex.tis.com Precedence: bulk MIC is a solution that Pat and I had talked about long time back. Also, I had summarized in an earlier mail. I am not against it. However, I do believe that it is a limited solution (e.g., what happens if someone proves MD5 is broken?). Organizations have security policies and security solutions must be flexible so that these policies (and objectives there of) are realizable. IPSEC is a framework under which you can have flexible security solutions that can meet different security requirements. Thus, it allows you to provide value add and a product differentiate. Therefore, it is a desired security protocol (both from business and technical point of view). Therefore, we are recommending IPSEC as the means of meeting L2TP's security requirements when used over IP. I am not against implementing other mechanisms for L2TP over non-IP protocols (so, now there are two!). Baiju Baiju -----Original Message----- From: Chris Boscolo [SMTP:chris.boscolo@sealabs.com] Sent: Tuesday, June 10, 1997 2:03 PM To: l2tp@zendo.com Subject: Security considerations for L2TP (one last try)! Baiju, and PatC, I almost agreed with you until I had a night to think about it. (This feels like a steep uphill battle but I will persist one last time none the less.) [Baiju Patel wrote] > Chris, let me try to explain why IPSEC may not be as bad an > idea. ... First, don't get me wrong, it is not that I don't like IPSEC, it's that I beleive there should be L2TP (with reasonable security) without requiring anything else. (In this case IPSEC) I will pull another "assumtion" I found in an ealier L2TP draft: "End System transparency: Neither the remote end system nor his home site hosts should require any special software to use this service in a secure manner." Image an ISP (in LAC mode) providing L2TP services that doesn't use IPSEC. I am a PPP client connect to the ISP. Also, I am using an older version of PPP which does not support any CCP encryption. Wouldn't this mean that my tunnel is unenecrypted? Lets take this a step further. Lets say thet I try to find L2TP client software, (since I don't trust my ISP to do the encryption for me) Then, in order to have a secure tunnel my client will also have to use IPSEC. I do agree with your previous point about a security soluttion looking like IPSEC, but I bring the point up again, l2TP does not require IP. If we keep making assumtions that it is based on IP we may as well stick with PPTP since it is an IP only solution. What would be nice is if L2TP offerd used an optioanl MIC for control messages, and an optional MIC and ecryption for data. It seems like the extra (128) bytes per control message would not be a huge price to pay for. Since it is optional, if you were using IPSEC then you could elect not to use the built into L2TP. Here is how it could be added? The option could be (in/ex)cluded vi the K bit, since the Key is being removed. Also, the key field could be replaced by MIC len (2bytes) & 2 bytes PAD for the control messages. And by a MIC len 2 Bytes, encryption data len (2bytes) for data packets. The actual data would follow the MIC, and auth stuff. The MIC, and encryption used could be negotiated. The actual size of the use of the space for the MIC, and encryption data would depend on the type negotiated. The encryption data could be things like an IV. (PatC, I wasn't sure how your MIC work fit in?) So, I have said my piece. If I am the only one that feels this way, I will say no more about it... Thanks, Chrisb -- Chris Boscolo chris.boscolo@WatchGuard.com Seattle Software Labs (206) 521-8348 From owner-ipsec Tue Jun 17 09:05:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA04360 for ipsec-outgoing; Tue, 17 Jun 1997 09:04:47 -0400 (EDT) Date: Tue, 17 Jun 1997 09:03:09 -0400 From: "Waterhouse, Richard" Subject: RE: ISAKMP Oakley resolution and ipsec doi document questions To: "'ipsec@tis.com'" , "'Edward A. Russell'" , "'Baiju Patel'" , "'Roy Pereira'" Message-id: MIME-version: 1.0 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk >> >>Let me try to understand. If I implement ISAKMP >>and not want to use port 500, but say use port >>2000, could I use the port field to indicate to the >>receiver that the reply must be sent to port 2000 >>(I do not think this is the case, because the first >>message of main mode exchange does not include >>ID at all). >> > >The port in the ID payload is only used for identification and not for >the ISAKMP protocol. ISAKMP always uses port 500. > I'm not sure I understand how the following statement in the ISAKMP Standard implies that "ISAKMP always USES port 500". > Implementations MUST include support for ISAKMP using the User Datagram Protocol (UDP) on port 500. UDP Port 500 has been assigned to ISAKMP by the Internet Assigned Numbered Authority (IANA). Implementations MAY addi- tionally support ISAKMP over other transport protocols or over IP itself. > From owner-ipsec Thu Jun 19 11:57:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA21872 for ipsec-outgoing; Thu, 19 Jun 1997 11:48:51 -0400 (EDT) Message-Id: <199706191554.LAA20807@relay.hq.tis.com> Comments: Authenticated sender is From: "Peter Trei" Organization: Process Software To: ipsec@tis.com Date: Thu, 19 Jun 1997 11:57:31 -6 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: DES-CBC brute forced. Reply-to: trei@process.com CC: trei@process.com X-mailer: Pegasus Mail for Win32 (v2.42) Sender: owner-ipsec@ex.tis.com Precedence: bulk This is relevant to the issue of selecting bulk encryption algorithms for ESP. [Note: I have a personal interest here - I proposed the DES key search to RSA back in October, and it grew out of that suggestion. I also invented some of the techniques used.] - Peter Trei trei@process.com --------------------------------------------- Forwarded message: >From owner-deschall-announce@gatekeeper.megasoft.com Wed Jun 18 13:43:46 1997 Date: Wed, 18 Jun 1997 14:09:11 -0600 From: Rocke Verser Message-Id: <199706182009.OAA06697@dopey.verser.frii.com> To: deschall@gatekeeper.megasoft.com Subject: DESCHALL Press Release Sender: owner-deschall@gatekeeper.megasoft.com Precedence: bulk INTERNET-LINKED COMPUTERS CHALLENGE DATA ENCRYPTION STANDARD LOVELAND, COLORADO (June 18, 1997). Tens of thousands of computers, all across the U.S. and Canada, linked together via the Internet in an unprecedented cooperative supercomputing effort to decrypt a message encoded with the government-endorsed Data Encryption Standard (DES). Responding to a challenge, including a prize of $10,000, offered by RSA Data Security, Inc, the DESCHALL effort successfully decoded RSADSI's secret message. According to Rocke Verser, a contract programmer and consultant who developed the specialized software in his spare time, "Tens of thousands of computers worked cooperatively on the challenge in what is believed to be one of the largest supercomputing efforts ever undertaken outside of government." Using a technique called "brute-force", computers participating in the challenge simply began trying every possible decryption key. There are over 72 quadrillion keys (72,057,594,037,927,936). At the time the winning key was reported to RSADSI, the DESCHALL effort had searched almost 25% of the total. At its peak over the recent weekend, the DESCHALL effort was testing 7 billion keys per second. Verser considers this project to be remarkable in two ways: One. This is the first time anyone has publicly shown that they can read a message encrypted with DES. And this was done with "spare" CPU time, mostly from ordinary PCs, by thousands of users who have never even met each other. U.S. government and industry will have to take a hard look at their cryptographic policies. "DES can no longer be considered secure against a determined adversary", Verser said. Two. This project demonstrates the kind of supercomputing power that can be harnessed on the Internet using nothing but "spare" CPU time. "Imagine what might be possible using millions of computers connected to the Internet!" Aside from cryptography and other obvious mathematical uses, supercomputers are used in many fields of science. "Perhaps a cure for cancer is lurking on the Internet?", said Verser, "Or perhaps the Internet will become Everyman's supercomputer." Under current U.S. government export regulations, and underscoring a problem faced by the U.S. software industry, the program that searched the keys could not be exported, except to Canada. A competitive effort, based in Sweden, sprang up well after the DESCHALL effort began. Able to "market" their keysearch software around the world, the Swedish effort caught up quickly, and had searched nearly 10 quadrillion keys by the end of the contest. ------------------------------------ Verser agrees with the sentiment voiced in RSADSI's secret message: "Strong cryptography makes the world a safer place." Use of strong cryptography, both domestically and internationally, is essential in today's electronic world. "But not at the expense of a citizen's right to privacy." Verser adds, "Recent proposals for 'key-recovery' and for criminalization of the use of cryptography have no place in a free society." Information about the DESCHALL effort is available from the official DESCHALL Web site at: MEDIA CONTACTS: Matt Curtin, (908) 431-5300 x 295, ALTERNATE: Rocke Verser, (970) 663-5629, ALTERNATE: Justin Dolske, (614) 459-5194, - 30 - From owner-ipsec Thu Jun 19 12:24:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA22157 for ipsec-outgoing; Thu, 19 Jun 1997 12:22:40 -0400 (EDT) From: Uri Blumenthal Message-Id: <9706191629.AA25553@hawpub.watson.ibm.com> Subject: Re: DES-CBC brute forced. To: trei@process.com Date: Thu, 19 Jun 1997 12:29:08 -0400 (EDT) Cc: ipsec@tis.com In-Reply-To: <199706191554.LAA20807@relay.hq.tis.com> from "Peter Trei" at Jun 19, 97 11:57:31 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Peter Trei says: > This is relevant to the issue of selecting > bulk encryption algorithms for ESP. > undertaken outside of government." > ................... > Using a technique called "brute-force", computers participating in > the challenge simply began trying every possible decryption key... > There are over 72 quadrillion keys (72,057,594,037,927,936). At the > time the winning key was reported to RSADSI, the DESCHALL effort had > searched almost 25% of the total. At its peak over the recent > weekend, the DESCHALL effort was testing 7 billion keys per second. > .....One. This is the first time anyone has publicly shown that they > can read a message encrypted with DES.................... What to do depends on how close to DEs you want to stay. There is DES/SK (in which I have personal interest, as this mod was designed by me and Steve Bellovin) - it will deny brute force and make diff/lin attacks more difficult (but not impossible). There's 3DES for those who don't want to change a single bit of DES spec (which may or may not be wise, considering the price paid)... -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Thu Jun 19 12:33:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA22218 for ipsec-outgoing; Thu, 19 Jun 1997 12:31:46 -0400 (EDT) Message-Id: <3.0.1.32.19970619123242.00d949f4@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Thu, 19 Jun 1997 12:32:42 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: test Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk From owner-ipsec Thu Jun 19 15:48:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA23431 for ipsec-outgoing; Thu, 19 Jun 1997 15:43:59 -0400 (EDT) Message-Id: <199706191950.PAA09886@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: uri@watson.ibm.com cc: trei@process.com, ipsec@tis.com Subject: What price security? In-reply-to: Your message of "Thu, 19 Jun 1997 12:29:08 EDT." <9706191629.AA25553@hawpub.watson.ibm.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Thu, 19 Jun 1997 15:50:42 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Uri Blumenthal writes: > What to do depends on how close to DEs you want to stay. There > is DES/SK (in which I have personal interest, as this mod was > designed by me and Steve Bellovin) - it will deny brute force > and make diff/lin attacks more difficult (but not impossible). > There's 3DES for those who don't want to change a single bit > of DES spec (which may or may not be wise, considering the > price paid)... I used to think that 3DES and other algorithms like it were "too expensive". Extensive day to day use of SSH taught me otherwise. I 3DES encrypt ALL my network traffic these days -- backups, remote logins, the works -- and I never notice the speed loss. Actually working with implementations often teaches one things one wouldn't have suspected from a theoretical viewpoint. My guess is that 3DES is only too expensive if you are trying to push a lot of data through an old embedded microprocessor based system where you just don't have the juice to do the work. On anything remotely modern, or anything where you aren't pumping lots of data (and hypothetical SNMP enabled lightbulbs aren't going to be pushing lots of data), you will not notice the overhead. Perry From owner-ipsec Thu Jun 19 16:26:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA23642 for ipsec-outgoing; Thu, 19 Jun 1997 16:23:51 -0400 (EDT) From: Uri Blumenthal Message-Id: <9706192030.AA23327@hawpub.watson.ibm.com> Subject: Re: What price security? To: perry@piermont.com Date: Thu, 19 Jun 1997 16:30:12 -0400 (EDT) Cc: ipsec@tis.com In-Reply-To: <199706191950.PAA09886@jekyll.piermont.com> from "Perry E. Metzger" at Jun 19, 97 03:50:42 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Perry E. Metzger says: > I used to think that 3DES and other algorithms like it were "too > expensive". > Extensive day to day use of SSH taught me otherwise. I 3DES encrypt > ALL my network traffic these days -- backups, remote logins, the works > -- and I never notice the speed loss. Depends on what you're doing, of course. Five years ago I used 3DES for telnet, and - surprise - never noticed the speed loss. Now try real-time video-conferencing and tell me if you notice any performance degradation. > Actually working with implementations often teaches one things one > wouldn't have suspected from a theoretical viewpoint. My guess is that > 3DES is only too expensive if you are trying to push a lot of data > through an old embedded microprocessor based system where you just > don't have the juice to do the work. I think your guess is only partially correct. It depends mostly on how much data you're pushing through. > On anything remotely modern, or > anything where you aren't pumping lots of data (and hypothetical SNMP > enabled lightbulbs aren't going to be pushing lots of data), you will > not notice the overhead. No, SNMP shouldn't move lots of data (unless the design is screwed up :-). But today there are other protocols that do load the network (:-). To summarize: there are applications today, where 3DES delays things visibly, and from cryptography point of view there is no need to pay that price. On the other hand, plenty of applications today can live with 3DES on today's or yesterday's hardware... -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Thu Jun 19 18:46:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA24374 for ipsec-outgoing; Thu, 19 Jun 1997 18:43:52 -0400 (EDT) Message-Id: <199706192251.SAA11541@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: uri@watson.ibm.com cc: ipsec@tis.com Subject: Re: What price security? In-reply-to: Your message of "Thu, 19 Jun 1997 16:30:12 EDT." <9706192030.AA23327@hawpub.watson.ibm.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Thu, 19 Jun 1997 18:51:45 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Uri Blumenthal writes: > Depends on what you're doing, of course. Five years ago I used 3DES > for telnet, and - surprise - never noticed the speed loss. Now try > real-time video-conferencing and tell me if you notice any > performance degradation. I have, actually. Surprisingly, you can get away with it a lot of the time today -- and doubtless all of the time Real Soon Now. Remember, 3DES implementations can churn out far higher than ethernet bandwidth data rates on modern processors. In a year or two this will be even less of an issue. If Phil Karn is reading, he might be able to speak a bit to the sorts of data rates he gets with his tuned 3DES code on 200Mhz+ Pentium IIs. > > On anything remotely modern, or > > anything where you aren't pumping lots of data (and hypothetical SNMP > > enabled lightbulbs aren't going to be pushing lots of data), you will > > not notice the overhead. > > No, SNMP shouldn't move lots of data (unless the design is screwed up :-). > But today there are other protocols that do load the network (:-). > > To summarize: there are applications today, where 3DES delays things > visibly, and from cryptography point of view there is no need to pay > that price. Even the dinkiest things can do pretty high speed with RC4, of course... Perry PS I think we mostly agree here, btw. From owner-ipsec Thu Jun 19 19:06:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA24478 for ipsec-outgoing; Thu, 19 Jun 1997 19:03:30 -0400 (EDT) Message-Id: <199706192310.AA015331828@relay.hp.com> To: ipsec@tis.com Subject: isakmp/doi questions: fine-grained keying.. Date: Thu, 19 Jun 1997 19:10:27 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm trying to figure out how to implement fine-grained per-transport-connection SA's with isakmp. section 4.6.2 includes space for a port number, and says: The Identification Payload is used to identify the initiator of the Security Association. The identity of the initiator SHOULD be used by the responder to determine the correct host system security policy requirement for the association. For example, a host might choose to require data origin authentication without confidentiality (AH) from a certain set of IP addresses and full authentication with confidentiality (Hughes) from another range of IP addresses. The Identification Payload provides information that can be used by the responder to make this decision. it also specifies: o Protocol ID (1 octet) - Value specifying an associated IP protocol ID (e.g. UDP/TCP). A value of zero means that the Protocol ID field should be ignored. o Port (2 octets) - Value specifying an associated port. A value of zero means that the Port field should be ignored. It does not specify whether the port number is the port on the initiator's host or the responder's host; this could be specified more clearly. In the event that the responding host supports multiple certifiable identities, an important part of responder security policy is knowing which identity to attach to the responder's end of the SA. As it stands, the protocol does not provide the responder with enough information to know which identity/certificate should be used to authenticate the responder's half of the exchange. This is especially relevant when encryption will be used by the underlying SA... you don't want to send something encrypted unless you know who's going to be able to decrypt it. I think you need to include both source and destination ports *somewhere* in the protocol, but I'm not entirely sure this works best in the phase I exchange, either. I'll see if I can come up with a more concrete alternative proposal in the next few days. - Bill From owner-ipsec Thu Jun 19 19:43:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA24771 for ipsec-outgoing; Thu, 19 Jun 1997 19:41:29 -0400 (EDT) Date: Thu, 19 Jun 1997 16:49:10 -0700 (PDT) Message-Id: <199706192349.QAA06201@servo.qualcomm.com> From: Phil Karn To: perry@piermont.com CC: uri@watson.ibm.com, trei@process.com, ipsec@tis.com In-reply-to: <199706191950.PAA09886@jekyll.piermont.com> (perry@piermont.com) Subject: Re: What price security? Sender: owner-ipsec@ex.tis.com Precedence: bulk >Extensive day to day use of SSH taught me otherwise. I 3DES encrypt >ALL my network traffic these days -- backups, remote logins, the works >-- and I never notice the speed loss. I do the same, and I agree. The only time I even notice the encryption load enough to be tempted to turn it off is when I'm shipping a very large amount of data (like an entire filesystem) between two machines on my private home Ethernet where I'm fairly confident there are no eavesdroppers. By the way, the DES implementation in the freeware version of SSH could be improved. There's a fairly obvious optimization that could be had in the 3DES encrypt/decrypt functions, namely eliminating the final permutations of encryptions 1&2 and eliminating the initial permutations of encryptions 2&3 as these pairs of permutations cancel. Also, I have a DES and 3DES in hand-optimized assembler for the Intel x86 CPUs that I'm thinking of dropping into SSH as a patch kit. My code does 3DES at 6.22 megabits/sec on a 133MHz Pentium. That's over twice the speed of the 3DES C code in SSH, which I measure at about 2.6 megabits/sec on the P133. Phil From owner-ipsec Thu Jun 19 19:59:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA24851 for ipsec-outgoing; Thu, 19 Jun 1997 19:56:32 -0400 (EDT) Message-Id: <199706200000.UAA00200@coredump.cis.upenn.edu> To: Bill Sommerfeld cc: ipsec@tis.com Subject: Re: isakmp/doi questions: fine-grained keying.. In-reply-to: Your message of "Thu, 19 Jun 1997 19:10:27 EDT." <199706192310.AA015331828@relay.hp.com> Date: Thu, 19 Jun 1997 20:00:00 +0100 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In message <199706192310.AA015331828@relay.hp.com>, Bill Sommerfeld writes: >It does not specify whether the port number is the port on the >initiator's host or the responder's host; this could be specified more >clearly. If you check Quick Mode, you'll see that there are two IDs sent, IDii and IDir; these are (presumably) the identities of the user-initiator and the user-responder, as known by the Initiator. I would expect the Responder to verify those, then reverse the order and send them back to the Initiator in the next message (i don't have the draft around tho, so take this last with a grain of salt). >I think you need to include both source and destination ports >*somewhere* in the protocol, but I'm not entirely sure this works best >in the phase I exchange, either. I'll see if I can come up with a >more concrete alternative proposal in the next few days. > I don't think you need to do this in the Phase I exchange; i would expect that the IDs exchanged there are just IPv4 addresses, no ports. Remember, Phase I identifies just the ISAKMP daemons, no users. However, your question raises an interesting problem: what if i want to encrypt the traffic of a particular TCP session but want to use my certificate as user foo; as it stands right now, the protocol allows for either but not both. I suspect that the way to authenticate TCP sessions (but not all traffic from user A@host1 to user B@host2) involves using secrets that depend on the IP address included in the ID, i.e. no finer grain auth. is possible. - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBM6nIAL0pBjh2h1kFAQEwnQP5Aauzksq6Swvcl+YLzbDDWar8mSAjQus0 7j66oef2UQIpFMQ0fgDj1qyfRoKl7OcIil33/NVcV9oC/4lL5Vg9diGqdNyYGb+d UXyf/KiZBWVfV+DtcjA8LUg5pfcphk2RAs4Huf5GmVBYUPSfnejuITIwoGvTjjEw TbDDBIDyyxQ= =Wfg2 -----END PGP SIGNATURE----- From owner-ipsec Thu Jun 19 20:19:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA24988 for ipsec-outgoing; Thu, 19 Jun 1997 20:17:36 -0400 (EDT) To: perry@piermont.com cc: uri@watson.ibm.com, ipsec@tis.com Subject: Re: What price security? In-reply-to: Your message of "Thu, 19 Jun 1997 18:51:45 -0400." <199706192251.SAA11541@jekyll.piermont.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Jun 1997 10:23:50 +1000 Message-ID: <5655.866766230@connect.com.au> From: George Michaelson Sender: owner-ipsec@ex.tis.com Precedence: bulk > Uri Blumenthal writes: > > Depends on what you're doing, of course. Five years ago I used 3DES > > for telnet, and - surprise - never noticed the speed loss. Now try > > real-time video-conferencing and tell me if you notice any > > performance degradation. > >Perry Metzger writes: > Remember, 3DES implementations can churn out far higher than ethernet > bandwidth data rates on modern processors. In a year or two this will > be even less of an issue. These comments don't mesh for me. you can't both be right. If the RT conferencing is being done on the internet-at large, then end-to-end delay and congestion is going to make it be WELL under an ethernet in speed and quality. If Perrys comments about 3DES being able to flood and ethernet is true, then then even for real-time conferencing, 3DES added delay will be lost in noise for a number of people eg trans-continental or >15 hop separated parties. I think the answer is that 3DES can sustain datarate for applications up to ethernet speed, but delay effects *may* be visible for parties whose normal end-end delay is under some value which is a crossoverpoint: if the normal network loading encompasses that delay with sufficient variance, then you won't notice the difference much, apart from issues relating to loss recovery for a streaming cipher. Is that it? -George -- George Michaelson | connect.com.au pty/ltd Email: ggm@connect.com.au | c/o AAPT, Phone: +61 7 3834 9976 | level 8, the Riverside Centre, Fax: +61 7 3834 9908 | 123 Eagle St, Brisbane QLD 4000 From owner-ipsec Thu Jun 19 21:31:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA25289 for ipsec-outgoing; Thu, 19 Jun 1997 21:29:25 -0400 (EDT) Message-Id: <199706200137.VAA11890@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: George Michaelson cc: ipsec@tis.com Subject: Re: What price security? In-reply-to: Your message of "Fri, 20 Jun 1997 10:23:50 +1000." <5655.866766230@connect.com.au> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Thu, 19 Jun 1997 21:37:00 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk George Michaelson writes: > If the RT conferencing is being done on the internet-at large, then > end-to-end delay and congestion is going to make it be WELL under an ethernet > in speed and quality. Yup. > If Perrys comments about 3DES being able to flood and ethernet is > true, then then even for real-time conferencing, 3DES added delay > will be lost in noise for a number of people eg trans-continental or > >15 hop separated parties. I believe that, too. Phil has noted that even on a comparitively old processor, his tuned 3DES implementation gets 2/3rds of an ethernet. My more modern machines using his code easily saturate ethernet. As I've said, my experience at this point is that I rarely if ever notice the cost of encryption day to day, and I use it all the time -- even on my home ethernet. And if its a small issue now, imagine what it will be like in two years, when Intel 300Mhz Pentium II machines are low to medium end home machines? Perry From owner-ipsec Thu Jun 19 21:42:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA25347 for ipsec-outgoing; Thu, 19 Jun 1997 21:41:26 -0400 (EDT) To: perry@piermont.com cc: ipsec@tis.com Subject: Re: What price security? In-reply-to: Your message of "Thu, 19 Jun 1997 21:37:00 -0400." <199706200137.VAA11890@jekyll.piermont.com> Date: Fri, 20 Jun 1997 11:48:40 +1000 Message-ID: <6951.866771320@connect.com.au> From: George Michaelson Sender: owner-ipsec@ex.tis.com Precedence: bulk As I've said, my experience at this point is that I rarely if ever notice the cost of encryption day to day, and I use it all the time -- even on my home ethernet. Like you, I have suspicions that I could drink less coffee if it was simpler to turn it off per-app, and request just that when D/L big .tar.gz from the wub. I guess systems management cudgels are designed to make this 'un-feature' knob er, hard on the knuckles, and thus less likely to be tweeked. And if its a small issue now, imagine what it will be like in two years, when Intel 300Mhz Pentium II machines are low to medium end home machines? Modulo the issue of VR/MM exceeding current constraints of 128x128 boxlets of action. If we have real VHS quality material flying around, things might still be requiring a bit more bandwidth than we use now. However, It seems to me that this comes down to the bandwidth-delay product and as long as ipsec notes the effect of algorithms on end-to-end and per-link costs in that sense, upper-layer architects can take that into account. So does IPSEC alone impose enough added delay in the path to make bigwin and other long-delay options important for preservation of service level? Does it have impact on packetloss backoff and recovery strategies? Certainly at the application level it would, there was a small amount of discussion about this on one of the MBONE related lists, considering how application level streaming media could use stream ciphers with lossy protocols. the recovery issues seem to me to be messy in space and time, but block ciphers would seem to carry much more overhead. Is this a no-win situation that just has to be borne? cheers -George -- George Michaelson | connect.com.au pty/ltd Email: ggm@connect.com.au | c/o AAPT, Phone: +61 7 3834 9976 | level 8, the Riverside Centre, Fax: +61 7 3834 9908 | 123 Eagle St, Brisbane QLD 4000 From owner-ipsec Thu Jun 19 22:14:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA25508 for ipsec-outgoing; Thu, 19 Jun 1997 22:12:58 -0400 (EDT) Message-Id: <199706200227.TAA10200@mailsun2.us.oracle.com> Date: 19 Jun 97 19:19:53 -0700 From: "PALAMBER.US.ORACLE.COM" To: ipsec@tis.com Subject: Chairman of IPSec Resigns Cc: PALAMBER@us.oracle.com, rgm3@chrysler.com, jis@MIT.EDU, tytso@MIT.EDU MIME-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.0.2.1.40) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Sender: owner-ipsec@ex.tis.com Precedence: bulk I would like to notify all members of the IP Security working group that I am handing over the chair position to Bob Moskowitz and Ted Ts'o. It has been a challenge and a pleasure working with everyone. The group will benefit from this change as we move to building real IPSec implementations. Regards, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 633-2963 Redwood Shores, CA 94065 E-Mail: palamber@us.oracle.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-ipsec Fri Jun 20 05:18:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA27695 for ipsec-outgoing; Fri, 20 Jun 1997 05:16:03 -0400 (EDT) Organization: ESAT, K.U.Leuven, Belgium Date: Fri, 20 Jun 1997 11:20:21 +0200 (METDST) From: Bart Preneel To: Phil Karn cc: perry@piermont.com, uri@watson.ibm.com, trei@process.com, ipsec@tis.com Subject: Re: What price security? In-Reply-To: <199706192349.QAA06201@servo.qualcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Thu, 19 Jun 1997, Phil Karn wrote: > >Extensive day to day use of SSH taught me otherwise. I 3DES encrypt > >ALL my network traffic these days -- backups, remote logins, the works > >-- and I never notice the speed loss. > > I do the same, and I agree. The only time I even notice the encryption > load enough to be tempted to turn it off is when I'm shipping a very > large amount of data (like an entire filesystem) between two machines > on my private home Ethernet where I'm fairly confident there are no > eavesdroppers. > > By the way, the DES implementation in the freeware version of SSH > could be improved. There's a fairly obvious optimization that could > be had in the 3DES encrypt/decrypt functions, namely eliminating the > final permutations of encryptions 1&2 and eliminating the initial > permutations of encryptions 2&3 as these pairs of permutations cancel. > > Also, I have a DES and 3DES in hand-optimized assembler for the Intel > x86 CPUs that I'm thinking of dropping into SSH as a patch kit. My > code does 3DES at 6.22 megabits/sec on a 133MHz Pentium. That's over > twice the speed of the 3DES C code in SSH, which I measure at about > 2.6 megabits/sec on the P133. > > Phil > FYI: The 3DES code of my colleague Antoon Bosselaers runs at 9.2 Mbit/s on a 133MHz Pentium. Not available for free though ;-) Bart Preneel ------------------------------------------------------------------------------- Katholieke Universiteit Leuven tel. +32 16 32 11 48 Dept. Electrical Engineering-ESAT / COSIC fax. +32 16 32 19 86 K. Mercierlaan 94, B-3001 Heverlee, BELGIUM bart.preneel@esat.kuleuven.ac.be http://www.esat.kuleuven.ac.be/~preneel ------------------------------------------------------------------------------- From owner-ipsec Fri Jun 20 09:25:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA29294 for ipsec-outgoing; Fri, 20 Jun 1997 09:22:18 -0400 (EDT) Date: Fri, 20 Jun 1997 09:28:26 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199706201328.JAA17227@argon.ncsc.mil> To: ipsec@tis.com Subject: Re: What price security? X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: "Perry E. Metzger" > > I used to think that 3DES and other algorithms like it were "too > expensive". > > Extensive day to day use of SSH taught me otherwise. I 3DES encrypt > ALL my network traffic these days -- backups, remote logins, the works > -- and I never notice the speed loss. Nonetheless, there are applications (such as gigabit routers) where the processor-to-bandwidth ratio is smaller than pentium-over-modem. Hopefully everyone with an interest in strong efficient encryption will contribute their favorite algorithm to the AES (DES replacement) selection process when the call goes out, and contribute to the analysis of the submitted algorithms. From owner-ipsec Fri Jun 20 09:42:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA29428 for ipsec-outgoing; Fri, 20 Jun 1997 09:40:56 -0400 (EDT) From: andrade@netcom.com (Andrade Software Andrade Networking) Message-Id: <199706201348.GAA25680@netcom13.netcom.com> Subject: Re: What price security? To: karn@Qualcomm.com (Phil Karn) Date: Fri, 20 Jun 1997 06:48:20 -0700 (PDT) Cc: perry@piermont.com, uri@watson.ibm.com, trei@process.com, ipsec@tis.com In-Reply-To: <199706192349.QAA06201@servo.qualcomm.com> from "Phil Karn" at Jun 19, 97 04:49:10 pm Sender: owner-ipsec@ex.tis.com Precedence: bulk Andrade Software & Networking Andrad@Netcom.Com X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 544 Phil, I liked your new code. The encryption/decryption speed on a Pentium Pro was about 2-3 times faster than the old D3DES. I was getting around 5 to 7 uS per 100 bytes v.s about 15 uS per 100 bytes. Unfortunately the key setup is more expensive, about 200 uS v.s. 80 uS. For lots of short messages which require different keys it is slower than D3DES. For long messages or many messages with the same key it is faster. - Alex -- Alex Alten P.O. Box 11406 Pleasanton, CA 94588 USA Andrade@Netcom.Com (510) 417-0159 Fax/Voice From owner-ipsec Fri Jun 20 10:19:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA29710 for ipsec-outgoing; Fri, 20 Jun 1997 10:17:38 -0400 (EDT) Message-Id: <3.0.1.32.19970620102256.009bee1c@ranier.altavista-software.com> X-Sender: altapop@ranier.altavista-software.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 20 Jun 1997 10:22:56 -0400 To: ipsec@tis.com From: Matt Thomas Subject: isakmp-07: what is ADDRESS-NOTIFICATION used for? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk In section 3.14.1 notify message types, the value 26 is assigned to address-notification. No where that I can find in the isakmp-07 draft is that defined or referenced. Anyone know what it is for? Thanks, -- Matt Thomas Internet: matt.thomas@altavista-software.com Internet Locksmith WWW URL: AltaVista Internet Software Disclaimer: This message reflects my own Littleton, MA warped views, etc. From owner-ipsec Fri Jun 20 10:27:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA29795 for ipsec-outgoing; Fri, 20 Jun 1997 10:25:19 -0400 (EDT) Message-Id: <3.0.1.32.19970620102726.007450dc@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Fri, 20 Jun 1997 10:27:26 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: ESP encryption algorithms -- the next generation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hopefully people will discuss what encryption algorithms they wish to deploy in a multi-vendor interoperably environment. At a minimum it seems technically sound to do something more than just DES. It will be interesting to see what becomes common in the future. >Date: Fri, 20 Jun 1997 09:28:26 -0400 >From: dpkemp@missi.ncsc.mil (David P. Kemp) >To: ipsec@tis.com >Subject: Re: What price security? >X-Sun-Charset: US-ASCII >Sender: owner-ipsec@ex.tis.com > >> From: "Perry E. Metzger" >> >> I used to think that 3DES and other algorithms like it were "too >> expensive". >> >> Extensive day to day use of SSH taught me otherwise. I 3DES encrypt >> ALL my network traffic these days -- backups, remote logins, the works >> -- and I never notice the speed loss. > > >Nonetheless, there are applications (such as gigabit routers) where the >processor-to-bandwidth ratio is smaller than pentium-over-modem. > >Hopefully everyone with an interest in strong efficient encryption will >contribute their favorite algorithm to the AES (DES replacement) >selection process when the call goes out, and contribute to the >analysis of the submitted algorithms. > > From owner-ipsec Fri Jun 20 10:41:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA29901 for ipsec-outgoing; Fri, 20 Jun 1997 10:39:52 -0400 (EDT) Message-Id: <3.0.1.32.19970620103906.006980d8@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Fri, 20 Jun 1997 10:39:06 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: ISAKMP encryption choices? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I wonder if anyone is implementing the OTHER encryption algorithms specified in isakmp-oakley-03 for phase 1. It allows DES, IDEA, Blowfish, RC5, 3DES, and CAST. Is anyone doing anything other than DES? I was thinking of making sure the next implementation survey form allows this sort of thing to be specified. From owner-ipsec Fri Jun 20 11:42:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00344 for ipsec-outgoing; Fri, 20 Jun 1997 11:38:44 -0400 (EDT) Message-Id: <199706201545.LAA14643@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: dpkemp@missi.ncsc.mil (David P. Kemp) cc: ipsec@tis.com Subject: Re: What price security? In-reply-to: Your message of "Fri, 20 Jun 1997 09:28:26 EDT." <199706201328.JAA17227@argon.ncsc.mil> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 20 Jun 1997 11:45:43 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk David P. Kemp writes: > > From: "Perry E. Metzger" > > > > I used to think that 3DES and other algorithms like it were "too > > expensive". > > > > Extensive day to day use of SSH taught me otherwise. I 3DES encrypt > > ALL my network traffic these days -- backups, remote logins, the works > > -- and I never notice the speed loss. > > Nonetheless, there are applications (such as gigabit routers) where the > processor-to-bandwidth ratio is smaller than pentium-over-modem. No doubt. Of course, one of the advantages of the Internet architecture is that routers generally aren't communications endpoints (they are, but only for a tiny amount of management traffic) so they generally aren't going to be doing much encryption. It is only endpoint hosts with gigabit speed networks that need to worry, and those are (currently) rare, and probably by the time they are common processors will be substantially faster. For the edge case of Virtual Network equipment that has to go at high speeds, well, gigabit speed 3DES chips are available, and cheap compared to the rest of the router. Perry From owner-ipsec Fri Jun 20 11:43:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00353 for ipsec-outgoing; Fri, 20 Jun 1997 11:40:45 -0400 (EDT) Message-Id: <199706201548.LAA14652@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: andrade@netcom.com (Andrade Software Andrade Networking) cc: ipsec@tis.com Subject: Re: What price security? In-reply-to: Your message of "Fri, 20 Jun 1997 06:48:20 PDT." <199706201348.GAA25680@netcom13.netcom.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 20 Jun 1997 11:47:58 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Andrade Software Andrade Networking writes: > I liked your new code. The encryption/decryption speed on a Pentium Pro > was about 2-3 times faster than the old D3DES. I was getting around > 5 to 7 uS per 100 bytes v.s about 15 uS per 100 bytes. Unfortunately > the key setup is more expensive, about 200 uS v.s. 80 uS. For lots of > short messages which require different keys it is slower than D3DES. > For long messages or many messages with the same key it is faster. In general, though, this isn't a problem. In an application like IPSEC, where you have a finite number of keys being used to encrypt short packets, you just keep the pre-set up key blobs around for each key and only do the setup work once for each security association. Perry From owner-ipsec Fri Jun 20 12:07:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA00545 for ipsec-outgoing; Fri, 20 Jun 1997 12:01:32 -0400 (EDT) Message-Id: <199706201608.AA230252914@hpcsos.col.hp.com> To: Bart Preneel Cc: Phil Karn , perry@piermont.com, uri@watson.ibm.com, trei@process.com, ipsec@tis.com Subject: Re: What price security? In-Reply-To: Bart.Preneel's message of Fri, 20 Jun 1997 11:20:21 +0200. Date: Fri, 20 Jun 1997 12:08:31 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > FYI: > The 3DES code of my colleague Antoon Bosselaers runs > at 9.2 Mbit/s on a 133MHz Pentium. Bart, To make this more relevant to ipsec, how, umm, "agile" is this 3DES? I think there are three relevant measurements: - How much memory is required by the key schedules - How long does it take to set them up - How well does it perform on short blocks (64 bytes to ~4k bytes), if you have to change to a new key schedule after every block (assume you're rotating among 10 to 100 different keys). Clearly one can (and perhaps should) cache precomputed key schedules into your SA data structure(s), but whether to do it and how long to retain it is clearly a memory vs time engineering tradeoff.. - Bill From owner-ipsec Fri Jun 20 12:16:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA00625 for ipsec-outgoing; Fri, 20 Jun 1997 12:15:01 -0400 (EDT) Date: Fri, 20 Jun 1997 09:22:30 -0700 (PDT) Message-Id: <199706201622.JAA20497@servo.qualcomm.com> From: Phil Karn To: andrade@netcom.com CC: perry@piermont.com, uri@watson.ibm.com, trei@process.com, ipsec@tis.com In-reply-to: <199706201348.GAA25680@netcom13.netcom.com> (andrade@netcom.com) Subject: Re: What price security? Sender: owner-ipsec@ex.tis.com Precedence: bulk Alex, >5 to 7 uS per 100 bytes v.s about 15 uS per 100 bytes. Unfortunately >the key setup is more expensive, about 200 uS v.s. 80 uS. For lots of >short messages which require different keys it is slower than D3DES. The key setup in my code is slower because I never optimized the key scheduling code. I wasn't out to crack keys, and I figured that it was better anyway to handle the multiple key case by just creating each key schedule once and passing the appropriate one to the encrypt and decrypt routines. That's faster than continually calling even the fastest key scheduling function... Phil From owner-ipsec Fri Jun 20 12:17:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA00634 for ipsec-outgoing; Fri, 20 Jun 1997 12:16:03 -0400 (EDT) Date: Fri, 20 Jun 1997 09:23:51 -0700 (PDT) Message-Id: <199706201623.JAA20501@servo.qualcomm.com> From: Phil Karn To: dpkemp@missi.ncsc.mil CC: ipsec@tis.com In-reply-to: <199706201328.JAA17227@argon.ncsc.mil> (dpkemp@missi.ncsc.mil) Subject: Re: What price security? Sender: owner-ipsec@ex.tis.com Precedence: bulk >Nonetheless, there are applications (such as gigabit routers) where the >processor-to-bandwidth ratio is smaller than pentium-over-modem. Which, IMHO, is yet another compelling argument for doing encryption on an end-to-end basis whenever possible. Phil From owner-ipsec Fri Jun 20 12:23:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA00726 for ipsec-outgoing; Fri, 20 Jun 1997 12:21:37 -0400 (EDT) Message-Id: <3.0.1.32.19970620122744.00ac7e70@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 20 Jun 1997 12:27:44 -0400 To: Bart Preneel , Phil Karn From: Robert Moskowitz Subject: Re: What price security? Cc: perry@piermont.com, uri@watson.ibm.com, trei@process.com, ipsec@tis.com In-Reply-To: References: <199706192349.QAA06201@servo.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 11:20 AM 6/20/97 +0200, Bart Preneel wrote: > >FYI: >The 3DES code of my colleague Antoon Bosselaers runs >at 9.2 Mbit/s on a 133MHz Pentium. >Not available for free though ;-) > When you people quote these #s, is the CPU running at 100%? What could you get done if you had a CAD rendering app running that was taking 65% of that 1333MHz Pentium's power? the case study would be that math is on a server and the workstation uses NFS to access it over the Internet. We would want to secure this, of course. But once the data starts coming in the CAD program starts DOING real work with it.... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Fri Jun 20 12:32:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA00780 for ipsec-outgoing; Fri, 20 Jun 1997 12:29:38 -0400 (EDT) Message-Id: <3.0.1.32.19970620123622.009a3600@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 20 Jun 1997 12:36:22 -0400 To: ipsec@tis.com From: Robert Moskowitz Subject: A little social engineering In-Reply-To: References: <199706192349.QAA06201@servo.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk For the moment, my Chrysler and AIAG hats are off, but my first comment as the new co-chair. Our Default cypher in the docs is 56bit DES, and I am not inclined to change it. However, perhaps agreement can be reached on a Recommended cypher of greater strength. Now our official policy is we do not concern ourselves with any government policy like crypto export. But if DES is giving us problems, 3DES is even worst. I understand that Isreali companies have trouble exporting 3DES code, and no trouble exporting DES. So take a look at the various cyphers. Perhaps we do not have to wait for AES to come up with a recommendation. Now putting my AIAG hat back on, this is of interest to me... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Fri Jun 20 12:46:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA00923 for ipsec-outgoing; Fri, 20 Jun 1997 12:44:12 -0400 (EDT) Message-Id: <199706201651.MAA14892@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: rgm3@chrysler.com cc: trei@process.com, ipsec@tis.com Subject: Re: What price security? In-reply-to: Your message of "Fri, 20 Jun 1997 12:27:44 EDT." <3.0.1.32.19970620122744.00ac7e70@dilbert.is.chrysler.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 20 Jun 1997 12:51:04 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Robert Moskowitz writes: > When you people quote these #s, is the CPU running at 100%? Yup. > What could you get done if you had a CAD rendering app running that > was taking 65% of that 1333MHz Pentium's power? Hopefully it wouldn't be doing I/O at a full clip, but if it was, you obviously couldn't run both. You are accurately pointing out that in theory this stuff hurts performance. I agree with you about the theory 100% -- I used to believe the theory, just as I used to believe that Ethernet couldn't run at 100% of capacity because the queuing theory said so. However, practical experience shows that you CAN run Ethernet close to 100% and get work out of it. On the encryption stuff, my practical experience thus far is that somehow, it doesn't seem to make a difference. I haven't studied it enough to know why entirely, but my guess is that in practice when you are muching I/O at maximum rate you are I/O bound, not CPU bound, and thus you don't notice it on an ethernet -- when you are CPU bound, you tend not to be doing vast amounts of I/O. My guess is that you probably WOULD notice on fast ethernet. The point is, though, that things aren't nearly as bad as people thought, and that with CPUs getting faster the performance is only going to improve. Perry From owner-ipsec Fri Jun 20 12:55:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA00990 for ipsec-outgoing; Fri, 20 Jun 1997 12:52:42 -0400 (EDT) Message-Id: <3.0.1.32.19970620125741.00a37e20@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 20 Jun 1997 12:57:41 -0400 To: perry@piermont.com From: Robert Moskowitz Subject: Re: What price security? Cc: trei@process.com, ipsec@tis.com In-Reply-To: <199706201651.MAA14892@jekyll.piermont.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 12:51 PM 6/20/97 -0400, Perry E. Metzger wrote: > >The point is, though, that things aren't nearly as bad as people >thought, and that with CPUs getting faster the performance is only >going to improve. Unfortunately the CAD people have the same attitude. VR CAD design here we come! CAD is an example of an extremely CPU intensive program. It takes a lot of CPU to take a Bezie (ya I can't speel) equation and convert it to something the video card can deal with. Many other apps are not so CPU demanding. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Fri Jun 20 12:57:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA01017 for ipsec-outgoing; Fri, 20 Jun 1997 12:55:45 -0400 (EDT) Message-Id: <199706201724.NAA07190@relay.rv.tis.com> Comments: Authenticated sender is From: "Peter Trei" Organization: Process Software To: karn@Qualcomm.com, perry@piermont.com, uri@watson.ibm.com, trei@process.com, ipsec@tis.com, andrade@netcom.com Date: Fri, 20 Jun 1997 13:03:24 -6 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: What price security? Reply-to: trei@process.com X-mailer: Pegasus Mail for Win32 (v2.42) Sender: owner-ipsec@ex.tis.com Precedence: bulk Phil Karn writes: > Alex, > > >5 to 7 uS per 100 bytes v.s about 15 uS per 100 bytes. Unfortunately > >the key setup is more expensive, about 200 uS v.s. 80 uS. For lots of > >short messages which require different keys it is slower than D3DES. > > The key setup in my code is slower because I never optimized the key > scheduling code. I wasn't out to crack keys, and I figured that it was > better anyway to handle the multiple key case by just creating each > key schedule once and passing the appropriate one to the encrypt and > decrypt routines. That's faster than continually calling even the > fastest key scheduling function... > Phil This is one place where the work that went into the DES cracking effort can be applied. With a little one-time, startup work, you can generate key schedules much faster than Phil's code. If you study the way DES sets up key schedules, you'll find that each bit in the subkeys mirrors the setting of one bit in the original key. To generate key schedules quickly, at startup time I generated 56 key schedules using Phil's routine, each for a key with one bit set. To generate the key schedule for an arbitrary key, I had only to OR together the schedules corrosponding to set bits in the key. This is much faster than the canonical method. The breakeven point is somewhere around 60 keys - if your app will use >60 keys during it's run, you win with this method. You could lower the breakeven point by putting the 1-bit schedules into a header file, instead of calculating them at startup time. [This is NOT a criticism of Phil - he had no reason to optimize this part of the system.] Peter Trei trei@process.com From owner-ipsec Fri Jun 20 13:07:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA01101 for ipsec-outgoing; Fri, 20 Jun 1997 13:06:19 -0400 (EDT) From: Uri Blumenthal Message-Id: <9706201712.AA32771@hawpub.watson.ibm.com> Subject: Re: What price security? To: perry@piermont.com Date: Fri, 20 Jun 1997 13:12:36 -0400 (EDT) Cc: ipsec@tis.com In-Reply-To: <199706201651.MAA14892@jekyll.piermont.com> from "Perry E. Metzger" at Jun 20, 97 12:51:04 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Perry E. Metzger says: > > What could you get done if you had a CAD rendering app running that > > was taking 65% of that 1333MHz Pentium's power? > Hopefully it wouldn't be doing I/O at a full clip, but if it was, you > obviously couldn't run both. Which is precisely the point. In some cases you don't feel the delay at all, in others it may hurt you. > You are accurately pointing out that in > theory this stuff hurts performance. I don't think it's "just" the theory. If you don't run CAD and similar things, then for you it's 100% theory and you don't have to worry. If however you do run those ugly CPU-hungry apps - then for you it's 100% practice and you feel the hurt. > The point is, though, that things aren't nearly as bad as people > thought, and that with CPUs getting faster the performance is only > going to improve. The point is taken, but the problem is - as CPU and bandwidth get better, the work we make them do increases at the same (if not higher) ratio. So if you'll be solving today's problems on tomorrow's CPUs and networks - you're fine. But if you face tomorrow's problems on today's (and even tomorrow's) hardware - I'd drop that arrogant smile (:-). I'm sure CP/M would fly on today's Pentium. Win95 - doesn't. Do you see my drift? (:-) [Please don't tell me how fast Linux runs - I know. It's my main operating system :-] -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Fri Jun 20 13:20:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA01157 for ipsec-outgoing; Fri, 20 Jun 1997 13:18:54 -0400 (EDT) Message-Id: <199706201726.NAA15069@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: rgm3@chrysler.com cc: ipsec@tis.com Subject: Re: A little social engineering In-reply-to: Your message of "Fri, 20 Jun 1997 12:36:22 EDT." <3.0.1.32.19970620123622.009a3600@dilbert.is.chrysler.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 20 Jun 1997 13:26:27 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Robert Moskowitz writes: > Our Default cypher in the docs is 56bit DES, and I am not inclined to > change it. Nor am I... > However, perhaps agreement can be reached on a Recommended cypher of > greater strength. I'd say we should Recommend 3DES, though not require it, with a mind towards requiring it someday in the future. Perry From owner-ipsec Fri Jun 20 13:30:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA01227 for ipsec-outgoing; Fri, 20 Jun 1997 13:29:04 -0400 (EDT) Message-Id: <199706201736.NAA15099@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: uri@watson.ibm.com cc: ipsec@tis.com Subject: Re: What price security? In-reply-to: Your message of "Fri, 20 Jun 1997 13:12:36 EDT." <9706201712.AA32771@hawpub.watson.ibm.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 20 Jun 1997 13:36:22 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Uri Blumenthal writes: > > You are accurately pointing out that in theory this stuff hurts > > performance. > > I don't think it's "just" the theory. If you don't run CAD and similar > things, then for you it's 100% theory and you don't have to worry. If > however you do run those ugly CPU-hungry apps - then for you it's 100% > practice and you feel the hurt. I *do* run CPU hungry aps, Uri. What I'm encouraging people to do is to experiment and check if it actually turns out to be an issue for them before *assuming* it will be. It appears that for a wide variety of systems, the theoretical problem isn't showing up as a practical problem. Perry From owner-ipsec Fri Jun 20 13:34:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA01271 for ipsec-outgoing; Fri, 20 Jun 1997 13:33:34 -0400 (EDT) Message-Id: <199706201741.AA284298467@relay.hp.com> To: rgm3@chrysler.com Cc: perry@piermont.com, trei@process.com, ipsec@tis.com Subject: Re: What price security? In-Reply-To: rgm3's message of Fri, 20 Jun 1997 12:57:41 -0400. <3.0.1.32.19970620125741.00a37e20@dilbert.is.chrysler.com> Date: Fri, 20 Jun 1997 13:41:06 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > CAD is an example of an extremely CPU intensive program. It takes a lot of > CPU to take a Bezier equation and convert it to something the video > card can deal with. Well, there are clearly three options if you want to do CAD and IPSEC at the same time: a) back off to weaker/faster algorithms.. Maybe rc4/rc5 is "good enough" for your workload. b) add hardware assist for the crypto. c) add more cpu's or a faster cpu... replace the P133 running at 63% with a P200 working at ~40%.. d) put off with reduced frame rate for the VR when it's communicating.. My gut feel, as a software guy working for a hardware company, is that if (d) isn't good enough, (c) will be most cost-effective over time in end systems; (b) is only likely to be effective in security gateways, not end systems. [disclaimer: in case you hadn't noticed, I work for a hardware vendor who will be happy to sell you bigger/faster boxes :-) ] - Bill From owner-ipsec Fri Jun 20 13:54:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA01471 for ipsec-outgoing; Fri, 20 Jun 1997 13:52:13 -0400 (EDT) Date: Fri, 20 Jun 1997 13:57:20 -0400 From: Rich Graveman Message-Id: <199706201757.AA24146@shadow.secure.bellcore.com> To: perry@piermont.com Subject: Re: A little social engineering Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Perry, > I'd say we should Recommend 3DES, though not require it, with a mind > towards requiring it someday in the future. I agree with you that 3DES is attractive. For me the reasons are: 1. It can hardly be worse than DES, which has 20+ years of analysis. 2. It appears to get rid of the only serious DES shortcoming: key size. 3. It is unpatented and widely available in hardware and software. However, even having read the last two days' comments about performance, I think we should take time to consider DESX, which also appears to have the advantages above at single DES performance. Richard Graveman | V: +1 732 699 4611 | Bellcore 444 Hoes Lane, Rm. 1K-221 rfg@bellcore.com | F: +1 732 336 2828 | Piscataway, NJ 08854 USA From owner-ipsec Fri Jun 20 14:03:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA01533 for ipsec-outgoing; Fri, 20 Jun 1997 14:02:18 -0400 (EDT) Message-Id: <199706201806.OAA15254@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: Rich Graveman cc: ipsec@tis.com Subject: Re: A little social engineering In-reply-to: Your message of "Fri, 20 Jun 1997 13:57:20 EDT." <199706201757.AA24146@shadow.secure.bellcore.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 20 Jun 1997 14:06:52 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Rich Graveman writes: > However, even having read the last two days' comments about performance, > I think we should take time to consider DESX, which also appears to have > the advantages above at single DES performance. If I remember correctly DESX just "whitens" DES with a repeated XOR of each block against a static key value. My gut instinct is that I don't trust that much. I think of it as multiple encryption of DES and a repeated XOR pad, and certainly given that the repeated XOR pad alone is completely trivial to break, I'm not sure why I would trust the combination of DES with a trivial algorithm... Anyway, it doesn't give me comfort. Perry From owner-ipsec Fri Jun 20 14:08:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA01552 for ipsec-outgoing; Fri, 20 Jun 1997 14:07:18 -0400 (EDT) From: Dan.McDonald@eng.sun.com (Dan McDonald) Message-Id: <199706201814.LAA00285@kebe.eng.sun.com> Subject: Re: What price security? To: sommerfeld@apollo.hp.com (Bill Sommerfeld) Date: Fri, 20 Jun 1997 11:14:36 -0700 (PDT) Cc: rgm3@chrysler.com, perry@piermont.com, trei@process.com, ipsec@tis.com In-Reply-To: <199706201741.AA284298467@relay.hp.com> from "Bill Sommerfeld" at Jun 20, 97 01:41:06 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 > Well, there are clearly three options if you want to do CAD and IPSEC > at the same time: > My gut feel, as a software guy working for a hardware company, is that > if (d) isn't good enough, (c) will be most cost-effective over time in > end systems; (b) is only likely to be effective in security gateways, > not end systems. > [disclaimer: in case you hadn't noticed, I work for a hardware vendor > who will be happy to sell you bigger/faster boxes :-) ] As someone else who falls into that category, I agree totally! :) One other thing we implementors can do... and that's to make sure we tweak the living daylights out of any algorithms we have out there. And if there happens to be any of you out there with fast implementations, if you have reasonable redistribution policies, let us know fercryinoutloud. For example, Craig Metz told me that when he dropped in Phil Karn's x86-hand-tweaked DES, ESP performance jumped considerably on NRL code running on Intel boxen. My $0.02. Dan From owner-ipsec Fri Jun 20 14:21:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA01639 for ipsec-outgoing; Fri, 20 Jun 1997 14:20:21 -0400 (EDT) Message-Id: <199706201820.OAA01639@portal.ex.tis.com> From: Greg Carter To: "'ipsec@tis.com'" , "'Rodney Thayer'" Cc: "'Roy Pereira'" Subject: RE: ISAKMP encryption choices? Date: Fri, 20 Jun 1997 13:40:31 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk During the last bake-off there was interop between Entrust and TimeStep doing CAST-128 for ISAKMP/Oakley encryption with key lengths of 40 and 128 bits. I have been doing 3DES, but haven't done interop tests with anyone using it. ---- Greg Carter Entrust Technologies carterg@entrust.com >---------- >From: Rodney Thayer[SMTP:rodney@sabletech.com] >Sent: Friday, June 20, 1997 10:39 AM >To: ipsec@tis.com >Subject: ISAKMP encryption choices? > >I wonder if anyone is implementing the OTHER encryption algorithms >specified in isakmp-oakley-03 for phase 1. It allows DES, IDEA, Blowfish, >RC5, 3DES, and CAST. Is anyone doing anything other than DES? > >I was thinking of making sure the next implementation survey form allows >this sort of thing to be specified. > From owner-ipsec Fri Jun 20 14:26:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA01707 for ipsec-outgoing; Fri, 20 Jun 1997 14:25:24 -0400 (EDT) Message-Id: <3.0.1.32.19970620142556.00a6b820@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 20 Jun 1997 14:25:56 -0400 To: perry@piermont.com, dpkemp@missi.ncsc.mil (David P. Kemp) From: Robert Moskowitz Subject: Re: What price security? Cc: ipsec@tis.com In-Reply-To: <199706201545.LAA14643@jekyll.piermont.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 11:45 AM 6/20/97 -0400, Perry E. Metzger wrote: > >Of course, one of the advantages of the Internet architecture is that >routers generally aren't communications endpoints (they are, but only >for a tiny amount of management traffic) so they generally aren't >going to be doing much encryption. It is only endpoint hosts with >gigabit speed networks that need to worry, and those are (currently) >rare, and probably by the time they are common processors will be >substantially faster. For many the router is the gateway. Talk to Cisco and Ascend on that. And also look at Redcreek. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Fri Jun 20 14:29:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA01728 for ipsec-outgoing; Fri, 20 Jun 1997 14:27:55 -0400 (EDT) Message-Id: <199706201835.LAA03809@sirius.cs.pdx.edu> To: Rodney Thayer cc: ipsec@tis.com, tellner@cs.pdx.edu Subject: Re: ISAKMP encryption choices? In-reply-to: Your message of "Fri, 20 Jun 1997 10:39:06 EDT." <3.0.1.32.19970620103906.006980d8@pop3.pn.com> Date: Fri, 20 Jun 1997 11:35:20 -0700 From: "Todd D. Ellner" Sender: owner-ipsec@ex.tis.com Precedence: bulk Given the recent events in the Senate this entire discussion may soon become moot. The Kerrey/McCain bill (SB909) has REPLACED ProCODE as of last night. Mandated weak encryption, warrantless key recovery, only government approved algorithms, the whole nine yards. Saddest regards, Todd From owner-ipsec Fri Jun 20 14:29:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA01735 for ipsec-outgoing; Fri, 20 Jun 1997 14:28:26 -0400 (EDT) Message-Id: <3.0.1.32.19970620143023.00a97270@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 20 Jun 1997 14:30:23 -0400 To: Bill Sommerfeld From: Robert Moskowitz Subject: Re: What price security? Cc: perry@piermont.com, trei@process.com, ipsec@tis.com In-Reply-To: <199706201741.AA284298467@relay.hp.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 01:41 PM 6/20/97 -0400, Bill Sommerfeld wrote: > > b) add hardware assist for the crypto. > >(b) is only likely to be effective in security gateways, >not end systems. Also servers. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Fri Jun 20 14:39:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA01807 for ipsec-outgoing; Fri, 20 Jun 1997 14:38:02 -0400 (EDT) Date: Fri, 20 Jun 1997 14:44:28 -0400 From: Rich Graveman Message-Id: <199706201844.AA24728@shadow.secure.bellcore.com> To: perry@piermont.com Subject: Re: A little social engineering Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Perry Metzger responded to my post as follows: > Rich Graveman writes: > > However, even having read the last two days' comments about performance, > > I think we should take time to consider DESX, which also appears to have > > the advantages above at single DES performance. > > If I remember correctly DESX just "whitens" DES with a repeated XOR of > each block against a static key value. My gut instinct is that I don't > trust that much. I think of it as multiple encryption of DES and a > repeated XOR pad, and certainly given that the repeated XOR pad alone > is completely trivial to break, I'm not sure why I would trust the > combination of DES with a trivial algorithm... > > Anyway, it doesn't give me comfort. > > Perry You are correct about what DESX does, but crucially for its design it "whitens" the plaintext with one value and then the ciphertext with another. You are also correct in expressing a gut feeling that many may have shared until Joe Kilian and Phillip Rogaway published a paper at Crypto '96 giving a proof under reasonable assumptions that this design indeed is a sound way to extend the effective key length. Quoting from their abstract, p. 252 of the Proceedings, ... This construction was first suggested by Ron Rivest as a computationally cheap way to protect DES against exhaustive key-search attacks. This papaer proves, in a formal model, that the DESX construction is sound. They go on to estimate the effective key length at around 110 bits. Regards, Richard Graveman | V: +1 732 699 4611 | Bellcore 444 Hoes Lane, Rm. 1K-221 rfg@bellcore.com | F: +1 732 336 2828 | Piscataway, NJ 08854 USA From owner-ipsec Fri Jun 20 14:40:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA01818 for ipsec-outgoing; Fri, 20 Jun 1997 14:39:05 -0400 (EDT) Message-Id: <3.0.1.32.19970620143631.00a29c30@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 20 Jun 1997 14:36:31 -0400 To: Phil Karn , dpkemp@missi.ncsc.mil From: Robert Moskowitz Subject: Re: What price security? Cc: ipsec@tis.com In-Reply-To: <199706201623.JAA20501@servo.qualcomm.com> References: <199706201328.JAA17227@argon.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 09:23 AM 6/20/97 -0700, Phil Karn wrote: >>Nonetheless, there are applications (such as gigabit routers) where the >>processor-to-bandwidth ratio is smaller than pentium-over-modem. > >Which, IMHO, is yet another compelling argument for doing encryption >on an end-to-end basis whenever possible. And those servers better gear up for some hefty crypto work! Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Fri Jun 20 14:41:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA01819 for ipsec-outgoing; Fri, 20 Jun 1997 14:39:06 -0400 (EDT) Message-Id: <199706201846.OAA15454@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: rgm3@chrysler.com cc: ipsec@tis.com Subject: Re: What price security? In-reply-to: Your message of "Fri, 20 Jun 1997 14:25:56 EDT." <3.0.1.32.19970620142556.00a6b820@dilbert.is.chrysler.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 20 Jun 1997 14:46:23 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Robert Moskowitz writes: > At 11:45 AM 6/20/97 -0400, Perry E. Metzger wrote: > >Of course, one of the advantages of the Internet architecture is that > >routers generally aren't communications endpoints (they are, but only > >for a tiny amount of management traffic) so they generally aren't > >going to be doing much encryption. It is only endpoint hosts with > >gigabit speed networks that need to worry, and those are (currently) > >rare, and probably by the time they are common processors will be > >substantially faster. > > For many the router is the gateway. Talk to Cisco and Ascend on that. And > also look at Redcreek. I explicitly listed that case later in the same message when I spoke of VPN products. If your router is being used to provide VPN services, you very probably need hardware anyway. Perry From owner-ipsec Fri Jun 20 14:45:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA01889 for ipsec-outgoing; Fri, 20 Jun 1997 14:44:04 -0400 (EDT) Message-Id: <199706201851.OAA15498@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: "Todd D. Ellner" cc: Rodney Thayer , ipsec@tis.com Subject: Re: ISAKMP encryption choices? In-reply-to: Your message of "Fri, 20 Jun 1997 11:35:20 PDT." <199706201835.LAA03809@sirius.cs.pdx.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 20 Jun 1997 14:50:57 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk "Todd D. Ellner" writes: > Given the recent events in the Senate this entire discussion > may soon become moot. The Kerrey/McCain bill (SB909) has > REPLACED ProCODE as of last night. And it isn't going to pass -- not by a long shot. If it does, well, I suppose most of the rest of the world isn't going to care what we stupid Americans do. The IETF is an international organization. We don't build standards for the U.S. only. Perry From owner-ipsec Fri Jun 20 15:04:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA02027 for ipsec-outgoing; Fri, 20 Jun 1997 15:03:50 -0400 (EDT) Message-Id: <97Jun20.150632edt.11650@janus.tor.securecomputing.com> To: "Todd D. Ellner" cc: ipsec@tis.com Subject: Re: ISAKMP encryption choices? References: <199706201835.LAA03809@sirius.cs.pdx.edu> In-reply-to: tellner's message of "Fri, 20 Jun 1997 14:35:20 -0400". <199706201835.LAA03809@sirius.cs.pdx.edu> From: "C. Harald Koch" Date: Fri, 20 Jun 1997 15:10:57 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199706201835.LAA03809@sirius.cs.pdx.edu>, "Todd D. Ellner" writes: > Given the recent events in the Senate this entire discussion > may soon become moot. The Kerrey/McCain bill (SB909) has > REPLACED ProCODE as of last night. Mandated weak encryption, > warrantless key recovery, only government approved algorithms, > the whole nine yards. I don't know why we keep having to say this, but: SOME OF US ARE OUTSIDE THE USA. That means we can develop products (and standards!) with strong crypto, and without key recovery, despite the foolish decisions of your politicians. We have our own politicians to worry about, but that's a different story. -- Harald Koch, A Canadian in Canada... From owner-ipsec Fri Jun 20 15:04:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA02013 for ipsec-outgoing; Fri, 20 Jun 1997 15:03:16 -0400 (EDT) Date: Fri, 20 Jun 1997 12:10:53 -0700 (PDT) Message-Id: <199706201910.MAA21014@servo.qualcomm.com> From: Phil Karn To: rgm3@chrysler.com CC: Bart.Preneel@esat.kuleuven.ac.be, perry@piermont.com, uri@watson.ibm.com, trei@process.com, ipsec@tis.com In-reply-to: <3.0.1.32.19970620122744.00ac7e70@dilbert.is.chrysler.com> (message from Robert Moskowitz on Fri, 20 Jun 1997 12:27:44 -0400) Subject: Re: What price security? Sender: owner-ipsec@ex.tis.com Precedence: bulk >When you people quote these #s, is the CPU running at 100%? What could you Yup. I count the number of bits encrypted and divide by the "user" time as reported by the UNIX "time" command. >get done if you had a CAD rendering app running that was taking 65% of that >1333MHz Pentium's power? Then your encryption throughput would simply be 35% of what it could be if you could spend the whole CPU on it. But I think that would still be acceptably fast for most networks given a 1,333 MHz Pentium. :-) Phil From owner-ipsec Fri Jun 20 15:08:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA02063 for ipsec-outgoing; Fri, 20 Jun 1997 15:08:49 -0400 (EDT) Message-Id: <199706201916.MAA04726@sirius.cs.pdx.edu> To: "C. Harald Koch" cc: "Todd D. Ellner" , ipsec@tis.com, tellner@cs.pdx.edu Subject: Re: ISAKMP encryption choices? In-reply-to: Your message of "Fri, 20 Jun 1997 15:10:57 EDT." <97Jun20.150632edt.11650@janus.tor.securecomputing.com> Date: Fri, 20 Jun 1997 12:16:13 -0700 From: "Todd D. Ellner" Sender: owner-ipsec@ex.tis.com Precedence: bulk True, this is international, but since the US is a policy leader in a lot of areas it is everyone's concern. Given that there is a special US official whose only function is to travel the world convincing others to follow US policy and considering the general trend towards restrictions in, for instance, Germany, Russia, the UK (if DTI gets its way), France and others and the way in which the US tossed its weight around in the process leading up to the OECD policy statement it is something that the rest of the world will have to deal with one way or another. From owner-ipsec Fri Jun 20 15:39:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA02333 for ipsec-outgoing; Fri, 20 Jun 1997 15:38:58 -0400 (EDT) Message-ID: <01BC7D77.5DE37820@vpnet139.vpnet.com> From: Bill Hunt To: "'rgm3@chrysler.com'" , "ipsec@tis.com" Subject: RE: A little social engineering Date: Fri, 20 Jun 1997 12:42:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id PAA02330 Sender: owner-ipsec@ex.tis.com Precedence: bulk Ultimately, the strength of an encryption algorithm is proven by its longevity. Which was one of the strong reasons for choosing DES in the first place. 3DES seems like a reasonable stronger recommendation. >From a market perspective, the bulk of our customers prefer 3DES to other algorithms as well, so it certainly has the perception of strength. Regards, Bill --- Bill Hunt (bill@vpnet.com) Director, Software Engineering VPNet Technologies, Inc. -----Original Message----- From: Robert Moskowitz [SMTP:rgm3@chrysler.com] Sent: Friday, June 20, 1997 9:36 AM To: ipsec@tis.com Subject: A little social engineering For the moment, my Chrysler and AIAG hats are off, but my first comment as the new co-chair. Our Default cypher in the docs is 56bit DES, and I am not inclined to change it. However, perhaps agreement can be reached on a Recommended cypher of greater strength. Now our official policy is we do not concern ourselves with any government policy like crypto export. But if DES is giving us problems, 3DES is even worst. I understand that Isreali companies have trouble exporting 3DES code, and no trouble exporting DES. So take a look at the various cyphers. Perhaps we do not have to wait for AES to come up with a recommendation. Now putting my AIAG hat back on, this is of interest to me... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Fri Jun 20 16:02:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA02511 for ipsec-outgoing; Fri, 20 Jun 1997 16:01:07 -0400 (EDT) Message-Id: <199706202007.QAA22289@coredump.cis.upenn.edu> To: "Todd D. Ellner" cc: "C. Harald Koch" , ipsec@tis.com Subject: Re: ISAKMP encryption choices? In-reply-to: Your message of "Fri, 20 Jun 1997 12:16:13 PDT." <199706201916.MAA04726@sirius.cs.pdx.edu> Date: Fri, 20 Jun 1997 16:07:33 +0100 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In message <199706201916.MAA04726@sirius.cs.pdx.edu>, "Todd D. Ellner" writes: >True, this is international, but since the US is a policy leader in >a lot of areas it is everyone's concern. Given that there is a special >US official whose only function is to travel the world convincing >others to follow US policy and considering the general trend towards >restrictions in, for instance, Germany, Russia, the UK (if DTI gets >its way), France and others and the way in which the US tossed its >weight around in the process leading up to the OECD policy statement >it is something that the rest of the world will have to deal with one >way or another. However, in this particular case at least (ISAKMP), there is at least one international implementation available. Check ftp://ftp.funet.fi/pub/unix/security/net/ip/pluto-6.alpha.tar.gz As the name implies, it's still an alpha release. It is usable to some degree (if you're willing to write a few more lines of code, and use the SWAN ipsec-0.5, found in the same directory). Supposedly, someone else will now continue development outside the US now that i'm back in Philadelphia. - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBM6rjBL0pBjh2h1kFAQH2kgP+IJ22tOprj8haNsVJtcZAo24sVCKqBXfU F02Zn8nuQLzfzLw2E4aKd2QBS+aqH4OYkBPGoR9S2awcWuSGPSI8m9kptDEpzX0v jP/fCUR4Dovybu8a9aCi9a464xIzcdvFBZnD4jfunce7VyV8QNtV1uDJ6dY/+Sl6 1kV8sNQNjzg= =9HPG -----END PGP SIGNATURE----- From owner-ipsec Fri Jun 20 16:03:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA02539 for ipsec-outgoing; Fri, 20 Jun 1997 16:03:07 -0400 (EDT) Date: Fri, 20 Jun 1997 16:10:25 -0400 Message-Id: <9706202010.AA26219@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: IETF Munich scheduling Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- For your information, we have been assigned one session at the Munich IETF meeting, at the following time: Wednesday, August 13 at 1930-2200 (opposite dhc, iab, mboned) - Ted -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.2, an Emacs/PGP interface iQCVAwUBM6rjlUQVcM1Ga0KJAQFRGgP9GcklWwQx5d+JCFBV1k7OT/ctwuv/8ceJ lrK8UDuT56WX3UkCrIgpH3IOJtMPfeDErCHFqUEFyXfeCwOLi2w9CVA7ImV037jA P6sNBewiSmgaWz6eAcVy6efASG59aSHS2HUjHSODQuc+CYhtgmBd+n3Qgb/dWRJ+ l0fAfN7ByE8= =uZnk -----END PGP SIGNATURE----- From owner-ipsec Fri Jun 20 16:07:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA02576 for ipsec-outgoing; Fri, 20 Jun 1997 16:07:10 -0400 (EDT) Date: Fri, 20 Jun 1997 14:28:16 -0400 X-From: "Theodore Y. Ts'o" , Robert Moskowitz Message-Id: <9706201828.AA25929@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: Announcement from the new IPsec chairs Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk As the new IPSEC chairs, we'd like to thank the previous chairs for all of their work. We also wish to thank all of the many document authors for their dilligence. We have one goal: this work group will move to inactive status by the end of the year, as all current work gets through last call on to the standards track. In fact it would suit us just fine if we do not need to request a slot for DC. We are contacting all of the ID authors to review their document status. We have a process already in place to get consistancy into the transforms as was started back oh so many sessions ago (Montreal was it?). We are already well along the way on this; in fact we expect to have IDs for wg review in early July. This will allow for one iteration of the wg with republishing before the July 30th ID cutoff date. NOTE: WE ARE NOT CHANGING ANY BITS ON THE WIRE. We are addressing the document readability issues that have cropped up during the interoperability workshops that have been run by the AIAG (auto industry action group). We are also working at bringing up a web site for the workgroup. The purpose of this site will be: Interoperability results Implementation experiences and document clarifications White papers on IPsec technolgy People will be encouraged to write up their interpretations of such things as in line IVs and publish them on this site. These positions get losted in the organic discussions on the list. Desired later enhancements in IPsec Other things as requested by the wg. If we work together we all win. Robert Moskowitz Theodore Ts'o Chrysler Corporation MIT (810) 758-8212 (617) 253-8091 From owner-ipsec Fri Jun 20 16:21:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA02675 for ipsec-outgoing; Fri, 20 Jun 1997 16:21:17 -0400 (EDT) Message-ID: From: Roy Pereira To: "'ipsec@tis.com'" , "'Rodney Thayer'" Subject: RE: ISAKMP encryption choices? Date: Fri, 20 Jun 1997 16:30:05 -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 We have implemented DES, 3DES, RC5, CAST-128, IDEA, and BlowFish (i.e. all of them) in both ESP and ISAKMP. Unforetunately, we have been able only to test interoperability for DES and CAST-128. >---------- >From: Rodney Thayer[SMTP:rodney@sabletech.com] >Sent: Friday, June 20, 1997 10:39 AM >To: ipsec@tis.com >Subject: ISAKMP encryption choices? > >I wonder if anyone is implementing the OTHER encryption algorithms >specified in isakmp-oakley-03 for phase 1. It allows DES, IDEA, Blowfish, >RC5, 3DES, and CAST. Is anyone doing anything other than DES? > >I was thinking of making sure the next implementation survey form allows >this sort of thing to be specified. > From owner-ipsec Fri Jun 20 16:24:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA02702 for ipsec-outgoing; Fri, 20 Jun 1997 16:24:48 -0400 (EDT) Message-ID: <01BC7D7D.D47124A0@vpnet139.vpnet.com> From: Bill Hunt To: "ipsec@tis.com" Subject: RE: A little social engineering Date: Fri, 20 Jun 1997 13:28:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id QAA02699 Sender: owner-ipsec@ex.tis.com Precedence: bulk Ultimately, the strength of an encryption algorithm is proven by its longevity. Which is one of the strong reasons DES was chosen initially. 3DES seems like a natural recommendation for stronger encryption. >From a market perspective, the bulk of our customers prefer 3DES over other algorithms, so it certainly has the perception of strength. Regards, Bill --- Bill Hunt (bill@vpnet.com) Director, Software Engineering VPNet Technologies, Inc. -----Original Message----- From: Robert Moskowitz [SMTP:rgm3@chrysler.com] Sent: Friday, June 20, 1997 9:36 AM To: ipsec@tis.com Subject: A little social engineering For the moment, my Chrysler and AIAG hats are off, but my first comment as the new co-chair. Our Default cypher in the docs is 56bit DES, and I am not inclined to change it. However, perhaps agreement can be reached on a Recommended cypher of greater strength. Now our official policy is we do not concern ourselves with any government policy like crypto export. But if DES is giving us problems, 3DES is even worst. I understand that Isreali companies have trouble exporting 3DES code, and no trouble exporting DES. So take a look at the various cyphers. Perhaps we do not have to wait for AES to come up with a recommendation. Now putting my AIAG hat back on, this is of interest to me... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Fri Jun 20 16:47:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA02843 for ipsec-outgoing; Fri, 20 Jun 1997 16:47:28 -0400 (EDT) Message-ID: From: Roy Pereira To: "'ipsec@tis.com'" , "'rgm3@chrysler.com'" Subject: RE: A little social engineering Date: Fri, 20 Jun 1997 16:55:12 -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 Unfortunately, there doesn't seem to be any 'popular' alternatives to DES that everyone could agree on being mandatory. - RC5 is patented by RSA and, I believe, is licensable - CAST-128 is patented by Entrust, but free and is relatively new - IDEA is patented by ETH and licensable from Ascom Systek That leaves us with; - 3DES is slower than all of the above, but free - BlowFish is not that widely used and not that analyzed (Bruce Schneir would disagree) [ No slurs intended, since I'm definately not a cryptographer! ] >---------- >From: Robert Moskowitz[SMTP:rgm3@chrysler.com] >Sent: Friday, June 20, 1997 12:36 PM >To: ipsec@tis.com >Subject: A little social engineering > >For the moment, my Chrysler and AIAG hats are off, but my first comment as >the new co-chair. > >Our Default cypher in the docs is 56bit DES, and I am not inclined to >change it. > >However, perhaps agreement can be reached on a Recommended cypher of >greater strength. Now our official policy is we do not concern ourselves >with any government policy like crypto export. But if DES is giving us >problems, 3DES is even worst. I understand that Isreali companies have >trouble exporting 3DES code, and no trouble exporting DES. > >So take a look at the various cyphers. Perhaps we do not have to wait for >AES to come up with a recommendation. > >Now putting my AIAG hat back on, this is of interest to me... > > > >Robert Moskowitz >Chrysler Corporation >(810) 758-8212 > > From owner-ipsec Fri Jun 20 17:17:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA03032 for ipsec-outgoing; Fri, 20 Jun 1997 17:17:12 -0400 (EDT) Date: Fri, 20 Jun 1997 22:22:32 +0100 (BST) From: Reiser Reply-To: Reiser Subject: RE: A little social engineering To: Roy Pereira cc: "'ipsec@tis.com'" , "'rgm3@chrysler.com'" In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk What's abouth SAFER ? Peter > Unfortunately, there doesn't seem to be any 'popular' alternatives to > DES that everyone could agree on being mandatory. > > - RC5 is patented by RSA and, I believe, is licensable > - CAST-128 is patented by Entrust, but free and is relatively new > - IDEA is patented by ETH and licensable from Ascom Systek > > That leaves us with; > > - 3DES is slower than all of the above, but free > - BlowFish is not that widely used and not that analyzed (Bruce > Schneir would disagree) > > > [ No slurs intended, since I'm definately not a cryptographer! ] > > > >---------- > >From: Robert Moskowitz[SMTP:rgm3@chrysler.com] > >Sent: Friday, June 20, 1997 12:36 PM > >To: ipsec@tis.com > >Subject: A little social engineering > > > >For the moment, my Chrysler and AIAG hats are off, but my first comment as > >the new co-chair. > > > >Our Default cypher in the docs is 56bit DES, and I am not inclined to > >change it. > > > >However, perhaps agreement can be reached on a Recommended cypher of > >greater strength. Now our official policy is we do not concern ourselves > >with any government policy like crypto export. But if DES is giving us > >problems, 3DES is even worst. I understand that Isreali companies have > >trouble exporting 3DES code, and no trouble exporting DES. > > > >So take a look at the various cyphers. Perhaps we do not have to wait for > >AES to come up with a recommendation. > > > >Now putting my AIAG hat back on, this is of interest to me... > > > > > > > >Robert Moskowitz > >Chrysler Corporation > >(810) 758-8212 > > > > From owner-ipsec Fri Jun 20 17:49:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA03274 for ipsec-outgoing; Fri, 20 Jun 1997 17:48:52 -0400 (EDT) Date: Fri, 20 Jun 97 20:03:13 GMT From: "William Allen Simpson" Message-ID: <6058.wsimpson@greendragon.com> To: ipsec@tis.com Subject: DES-XEX3 was: A little social engineering Sender: owner-ipsec@ex.tis.com Precedence: bulk Goodness, a lot of traffic the past two days! > From: "Perry E. Metzger" > Rich Graveman writes: > > However, even having read the last two days' comments about performance, > > I think we should take time to consider DESX, which also appears to have > > the advantages above at single DES performance. > > If I remember correctly DESX just "whitens" DES with a repeated XOR of > each block against a static key value. My gut instinct is that I don't > trust that much. I think of it as multiple encryption of DES and a > repeated XOR pad, and certainly given that the repeated XOR pad alone > is completely trivial to break, I'm not sure why I would trust the > combination of DES with a trivial algorithm... > > Anyway, it doesn't give me comfort. > My memory (from Schneier, Byte, and CryptoBytes) is that this extends the DES 56-bits key strength up to about 120-bits for brute-force, and boosts the chosen plaintexts from 2**47 to 2**60 for differential. Even if my memory is slightly wrong on the numbers, but that's pretty good for a tiny amount of effort, and probably worthwhile. Also, the old Photuris attribute extensions -02 draft had numerous attributes defined so that ESP could be negotiated with all the subtle variations, without defining a slew of transforms. In Photuris, you would simply negotiate: ESP, XOR, DES-CBC, XOR. Never-the-less, Oakley is not as flexible, so I've agreed to write up DES-XEX3-CBC for ANX Security. Should be ready by tomorrow. If you'd read draft-simpson-ipsec-enhancement-01.txt, you'll note we list several alternatives. One is to XOR a pair of PRNG blocks against each DES block. Fast and almost as easy. So, while I'm at it, I'll write up DES-GEG3-CBC, too! WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Fri Jun 20 17:49:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA03273 for ipsec-outgoing; Fri, 20 Jun 1997 17:48:53 -0400 (EDT) Date: Fri, 20 Jun 97 20:47:04 GMT From: "William Allen Simpson" Message-ID: <6059.wsimpson@greendragon.com> To: ipsec@tis.com Subject: CAST5-128 was: A little social engineering Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Robert Moskowitz > Our Default cypher in the docs is 56bit DES, and I am not inclined to > change it. > Agreed. If we change the ephemeral keys fast enough, that should be good for data with time value of no more than a day or two. > However, perhaps agreement can be reached on a Recommended cypher of > greater strength. Now our official policy is we do not concern ourselves > with any government policy like crypto export. But if DES is giving us > problems, 3DES is even worst. I understand that Isreali companies have > trouble exporting 3DES code, and no trouble exporting DES. > > So take a look at the various cyphers. Perhaps we do not have to wait for > AES to come up with a recommendation. > My recommendation is to poke a stick in the sand at CAST5-128. It appears to be well designed, is supposedly twice as fast as DES, has variable size keys that can be long enough (up to 128), is from outside the USA, and is the right price (free). We could certainly use it for a few years until AES is defined and analysed. But do we trust the AES process? Look how NBS/NIST weakened DES from 112 to 56 bit keys 20 years ago! Folly! If we state an intention to deploy CAST5-128 widely, then maybe we will get a few outside analysts to take a hard look at it. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Fri Jun 20 18:05:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA03402 for ipsec-outgoing; Fri, 20 Jun 1997 18:05:20 -0400 (EDT) From: Uri Blumenthal Message-Id: <9706202212.AA35218@hawpub.watson.ibm.com> Subject: Re: DES-XEX3 was: A little social engineering To: wsimpson@greendragon.com (William Allen Simpson) Date: Fri, 20 Jun 1997 18:12:03 -0400 (EDT) Cc: ipsec@tis.com In-Reply-To: <6058.wsimpson@greendragon.com> from "William Allen Simpson" at Jun 20, 97 08:03:13 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk William Allen Simpson says: > My memory (from Schneier, Byte, and CryptoBytes) is that this extends > the DES 56-bits key strength up to about 120-bits for brute-force, and > boosts the chosen plaintexts from 2**47 to 2**60 for differential. If *my* memory serves me, DESX increases the key length against brute force, but has no effect wrt. differential or linear attack. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Fri Jun 20 18:40:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA03532 for ipsec-outgoing; Fri, 20 Jun 1997 18:38:57 -0400 (EDT) Date: Fri, 20 Jun 1997 18:46:25 -0400 Message-Id: <9706202246.AA26278@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: Timing of the IPSEC meeting Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk I've gotten a request that I try to reschedule the ipsec meeting so that it's not opposite the IAB meeting. I'm currently trying to see if this is possible. So, the time slot which I had posted earlier may be changing; stay tuned. - Ted From owner-ipsec Fri Jun 20 19:04:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA03658 for ipsec-outgoing; Fri, 20 Jun 1997 19:03:41 -0400 (EDT) Message-Id: <199706202310.TAA16407@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: "William Allen Simpson" cc: ipsec@tis.com Subject: Re: CAST5-128 was: A little social engineering In-reply-to: Your message of "Fri, 20 Jun 1997 20:47:04 GMT." <6059.wsimpson@greendragon.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 20 Jun 1997 19:10:03 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk "William Allen Simpson" writes: > > From: Robert Moskowitz > > Our Default cypher in the docs is 56bit DES, and I am not inclined to > > change it. > > Agreed. If we change the ephemeral keys fast enough, that should be > good for data with time value of no more than a day or two. I disagree. See the "Big Seven" paper: ftp://ftp.research.att.com/dist/mab/keylength.txt ftp://ftp.research.att.com/dist/mab/keylength.ps > My recommendation is to poke a stick in the sand at CAST5-128. Unfortunately, it is too new. I'd say we mandate DES as we do now, and recommend 3DES, which has a very solid amount of research behind it. CAST is probably a good idea in a couple of years when its been beaten up more. > We could certainly use it for a few years until AES is defined and > analysed. But do we trust the AES process? Look how NBS/NIST weakened > DES from 112 to 56 bit keys 20 years ago! Folly! They didn't weaken it, Bill. It turns out that because of Differential Cryptanalysis, LUCIFER had an inherent strenth that was far lower than the number of keys. They only made the key length correspond to reality. > If we state an intention to deploy CAST5-128 widely, then maybe we will > get a few outside analysts to take a hard look at it. It takes years to do that sort of analysis, and it will happen anyway. 3DES is my recommendation. Perry From owner-ipsec Fri Jun 20 19:11:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA03687 for ipsec-outgoing; Fri, 20 Jun 1997 19:11:32 -0400 (EDT) Message-Id: <199706202318.TAA16453@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: uri@watson.ibm.com cc: wsimpson@greendragon.com (William Allen Simpson), ipsec@tis.com Subject: Re: DES-XEX3 was: A little social engineering In-reply-to: Your message of "Fri, 20 Jun 1997 18:12:03 EDT." <9706202212.AA35218@hawpub.watson.ibm.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 20 Jun 1997 19:18:37 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Uri Blumenthal writes: > William Allen Simpson says: > > My memory (from Schneier, Byte, and CryptoBytes) is that this extends > > the DES 56-bits key strength up to about 120-bits for brute-force, and > > boosts the chosen plaintexts from 2**47 to 2**60 for differential. > > If *my* memory serves me, DESX increases the key length against brute > force, but has no effect wrt. differential or linear attack. That would make sense. Perry From owner-ipsec Fri Jun 20 19:47:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA03830 for ipsec-outgoing; Fri, 20 Jun 1997 19:46:32 -0400 (EDT) Message-Id: <2.2.32.19970620235235.0074e004@diablo.cisco.com> X-Sender: chbailey@diablo.cisco.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 20 Jun 1997 16:52:35 -0700 To: Phil Karn From: chase bailey Subject: Re: What price security? Cc: dpkemp@missi.ncsc.mil, ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk At 09:23 6/20/97 -0700, Phil Karn wrote: >>Nonetheless, there are applications (such as gigabit routers) where the >>processor-to-bandwidth ratio is smaller than pentium-over-modem. > >Which, IMHO, is yet another compelling argument for doing encryption >on an end-to-end basis whenever possible. > >Phil Yes, but the processor to bandwidth ratio have nothing in common in gigabit routers. IP Switching is now being accomplished where the processor doesn't "get in the way". /chase [chase bailey, phone: 408-527-3765, fax: 408-526-4025] director, business development, cisco systems, new technologies From owner-ipsec Sat Jun 21 10:40:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA07450 for ipsec-outgoing; Sat, 21 Jun 1997 10:38:36 -0400 (EDT) Message-Id: <3.0.1.32.19970621101613.0070b0a4@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Sat, 21 Jun 1997 10:16:13 -0400 To: Reiser From: Rodney Thayer Subject: RE: A little social engineering Cc: ipsec@tis.com In-Reply-To: References: <"Your message with ID" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Would you like to write an "ESP Shim" document proposing it? At this point the following ciphers have been talked about (I'm talking in vague terms here, just from my knowledge) DES-CBC 3DES-EDE (I think that's how you say it precisely...) RC4/ARCFOUR-128 RC5 CASTv5-128 (I trust Mr. Adams and/or the draft writers will correct my spelling) When I did the ARCFOUR cipher draft last spring I would hear from people -- "what about Blowfish", "What about CAST", "What about Safer", "What about SEAL", etc. Actually I think that's the three I heard people mention. I believe we can only think about the ones we've got ESP and/or DOI "paperwork" written for. That means, today, we think about RC5 and CAST and 3DES. You want Safer? This is a reasonable question, I believe, but someone has to write a draft... At 10:22 PM 6/20/97 +0100, you wrote: > >What's abouth SAFER ? > >Peter > >> Unfortunately, there doesn't seem to be any 'popular' alternatives to >> DES that everyone could agree on being mandatory. >> >> - RC5 is patented by RSA and, I believe, is licensable >> - CAST-128 is patented by Entrust, but free and is relatively new >> - IDEA is patented by ETH and licensable from Ascom Systek >> >> That leaves us with; >> >> - 3DES is slower than all of the above, but free >> - BlowFish is not that widely used and not that analyzed (Bruce >> Schneir would disagree) >> >> >> [ No slurs intended, since I'm definately not a cryptographer! ] >> >> >> >---------- >> >From: Robert Moskowitz[SMTP:rgm3@chrysler.com] >> >Sent: Friday, June 20, 1997 12:36 PM >> >To: ipsec@tis.com >> >Subject: A little social engineering >> > >> >For the moment, my Chrysler and AIAG hats are off, but my first comment as >> >the new co-chair. >> > >> >Our Default cypher in the docs is 56bit DES, and I am not inclined to >> >change it. >> > >> >However, perhaps agreement can be reached on a Recommended cypher of >> >greater strength. Now our official policy is we do not concern ourselves >> >with any government policy like crypto export. But if DES is giving us >> >problems, 3DES is even worst. I understand that Isreali companies have >> >trouble exporting 3DES code, and no trouble exporting DES. >> > >> >So take a look at the various cyphers. Perhaps we do not have to wait for >> >AES to come up with a recommendation. >> > >> >Now putting my AIAG hat back on, this is of interest to me... >> > >> > >> > >> >Robert Moskowitz >> >Chrysler Corporation >> >(810) 758-8212 >> > >> > > > > > > > From owner-ipsec Sat Jun 21 10:40:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA07451 for ipsec-outgoing; Sat, 21 Jun 1997 10:38:37 -0400 (EDT) Message-Id: <3.0.1.32.19970621102457.007659e0@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Sat, 21 Jun 1997 10:24:57 -0400 To: Roy Pereira From: Rodney Thayer Subject: RE: A little social engineering 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 Some more data points to consider: - there's no RC5 hardware or CAST-128 hardware, as far as I know [ok, chip makers, crawl out of the woodwork now and correct me, then send me samples :-)] - there is "running code" for 3DES, CAST-128 and ARCFOUR, that I know of. - there's no ESP docs for IDEA, present or on the radar. - there seems to be debate on whether or not 3DES is "slow". - what's wrong with "recommending you implement at least two ciphers" for the moment? In some sense we were using DES because "it had been thoroughly analyzed". Maybe it would be productive if the cryptograpy folks could help us get an idea of what of the various other ciphers around "have been analyzed" and how much? Subjectively I think 3DES and CAST-128 are the ones to look at since (a) there's code, (b) there's hardware and (c) there's a low volume of negative cryptographic opinion on them. This is an important discussion, IMO, but we want to find valid AND practical solutions rather than drilling off into techno-theological debates... At 04:55 PM 6/20/97 -0400, you wrote: >Unfortunately, there doesn't seem to be any 'popular' alternatives to >DES that everyone could agree on being mandatory. > > - RC5 is patented by RSA and, I believe, is licensable > - CAST-128 is patented by Entrust, but free and is relatively new > - IDEA is patented by ETH and licensable from Ascom Systek > >That leaves us with; > > - 3DES is slower than all of the above, but free > - BlowFish is not that widely used and not that analyzed (Bruce >Schneir would disagree) > > >[ No slurs intended, since I'm definately not a cryptographer! ] > > >>---------- >>From: Robert Moskowitz[SMTP:rgm3@chrysler.com] >>Sent: Friday, June 20, 1997 12:36 PM >>To: ipsec@tis.com >>Subject: A little social engineering >> >>For the moment, my Chrysler and AIAG hats are off, but my first comment as >>the new co-chair. >> >>Our Default cypher in the docs is 56bit DES, and I am not inclined to >>change it. >> >>However, perhaps agreement can be reached on a Recommended cypher of >>greater strength. Now our official policy is we do not concern ourselves >>with any government policy like crypto export. But if DES is giving us >>problems, 3DES is even worst. I understand that Isreali companies have >>trouble exporting 3DES code, and no trouble exporting DES. >> >>So take a look at the various cyphers. Perhaps we do not have to wait for >>AES to come up with a recommendation. >> >>Now putting my AIAG hat back on, this is of interest to me... >> >> >> >>Robert Moskowitz >>Chrysler Corporation >>(810) 758-8212 >> >> > > From owner-ipsec Sat Jun 21 13:29:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08139 for ipsec-outgoing; Sat, 21 Jun 1997 13:27:09 -0400 (EDT) Message-Id: <3.0.1.32.19970621133225.0075ea58@ranier.altavista-software.com> X-Sender: altapop@ranier.altavista-software.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sat, 21 Jun 1997 13:32:25 -0400 To: Rodney Thayer From: Matt Thomas Subject: RE: A little social engineering Cc: ipsec@tis.com In-Reply-To: <3.0.1.32.19970621102457.007659e0@pop3.pn.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:24 AM 6/21/97 -0400, Rodney Thayer wrote: >Some more data points to consider: > >- there's no RC5 hardware or CAST-128 hardware, as far as I know [ok, chip >makers, crawl out of the woodwork now and correct me, then send me samples >:-)] [Me too!] However, at least for me, 16 round RC5 (independent of keysize) is about twice as fast than CAST-128 in software. (FWIW: I get 30.5 megabits/second with RC5-R16-B128 and 16.9 megabits/second with CAST5-128 with both implementations written in C, compiled with GNU C 2.7.2.2 under NetBSD/i386 1.2G on a Pentium-133. An Alpha EV5-266 will do RC5 @ ~100 megabits per second). >- there is "running code" for 3DES, CAST-128 and ARCFOUR, that I know of. And RC5 (Why does isakmp-oakley-03 use RC5-R12-B64 instead of RC5-R16-B128.)? >- there's no ESP docs for IDEA, present or on the radar. I've thought of writing one but it hasn't been high on my list of things I might do. Given the availability of CAST5-128 and/or Blowfish, I don't see a pressing need for IDEA given that it's restrictions. [Of course, one could say the same of RC5.] >- there seems to be debate on whether or not 3DES is "slow". 3DES is slow compared to ciphers of equivalent length (CAST, RC5). (6.22 megabits/sec (as stated by Phil Karn) .vs. the numbers I quoted above). >- what's wrong with "recommending you implement at least two ciphers" for >the moment? I would make that DES and at least one other cipher. >In some sense we were using DES because "it had been thoroughly analyzed". "Better the devil you know..." >Subjectively I think 3DES and CAST-128 are the ones to look at since (a) >there's code, (b) there's hardware and (c) there's a low volume of negative >cryptographic opinion on them. At least in my brief search, I didn't find a CAST-128 implementation but it didn't take that long to write one using RFC 2144. CAST-128 may be too new to have much analysis done yet. I like it but it may be premature. -- Matt Thomas Internet: matt.thomas@altavista-software.com Internet Locksmith WWW URL: AltaVista Internet Software Disclaimer: This message reflects my own Littleton, MA warped views, etc. From owner-ipsec Sat Jun 21 13:46:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08223 for ipsec-outgoing; Sat, 21 Jun 1997 13:46:16 -0400 (EDT) Message-Id: <3.0.1.32.19970621134958.0071c5c0@ranier.altavista-software.com> X-Sender: altapop@ranier.altavista-software.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sat, 21 Jun 1997 13:49:58 -0400 To: "William Allen Simpson" From: Matt Thomas Subject: Re: calculating IVs Cc: ipsec@tis.com In-Reply-To: <6024.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk >It was the second compromise method. It is a little stronger than the >first compromise reached over 2 years ago, described in RFC-1829 and >RFC-1851. One of the problems with this group is no decision stands for >more than a year. And everything has to be explained all over again to >each new person, such as yourself. If all the "shim" ESP drafts hadd agreed on a signle common IV, I wouldn't have asked. But there was a difference and (as an implementor) I wanted to know why (I'd rather have one common method for all the ciphers, if possible). Would it not be best then to either include text on how generate an IV in the ESP draft and allow the "shim" drafts to override it? Or define it in a separate draft RFC and let each "shim" reference it? It does seem unwise to duplicate this in each "shim" RFC. >The "best" method would be to key DES-OFB over SPI+Sequence and use that >for the IV. Easy in software, but the hardware manufacturers griped >that would cause 2 chip invocations, and slow down their implementations. > >However, since then it has appeared that the "best" method can be done >with 1 invocation in CBC mode, and then replace the generated ciphertext >in the packet with the original SPI+Sequence. Simple. Elegant. > >I would be willing to change. Ask the vendors that implemented RFC-1851 >if they would be willing to change.... Since we seem to be doing our best to be incompatible with RFC 1851, why do we care? As much as I hate suggesting this, make it negotiable (with the default being the same as the current behavior). If it is really more secure (or better), those that can do it will. -- Matt Thomas Internet: matt.thomas@altavista-software.com Internet Locksmith WWW URL: AltaVista Internet Software Disclaimer: This message reflects my own Littleton, MA warped views, etc. From owner-ipsec Sat Jun 21 14:02:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA08305 for ipsec-outgoing; Sat, 21 Jun 1997 14:02:11 -0400 (EDT) Date: Sat, 21 Jun 97 11:03:58 PDT From: jim@mentat.com (Jim Gillogly) Message-Id: <9706211803.AA07412@mentat.com> To: ipsec@tis.com Subject: Time value and 56-bit DES [Re: CAST5-128 was: A little social engineering] Sender: owner-ipsec@ex.tis.com Precedence: bulk WSimpson@UMich.edu says: > > From: Robert Moskowitz > > Our Default cypher in the docs is 56bit DES, and I am not inclined to > > change it. > > > Agreed. If we change the ephemeral keys fast enough, that should be > good for data with time value of no more than a day or two. Depends also on the dollar value of the data. Michael Wiener's carefully designed hardware DES-cracker (Crypto '94 rump session, I think) would cost $1M using 1994 technology, and would produce solutions in 3.5 hrs on average. I would keep 56-bit DES as the default cipher for now, have a recommended second cipher (my preference would be 3DES-EDE because of the available analysis and intellectual property status), and be prepared to spring to another default if conditions warrant. Our finding out that someone has built a Wiener Box would be such a condition. This week's DES crack is a useful data point, but doesn't capture the threat from dedicated and specially-designed hardware. Jim Gillogly From owner-ipsec Sat Jun 21 14:07:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA08321 for ipsec-outgoing; Sat, 21 Jun 1997 14:07:41 -0400 (EDT) From: andrade@netcom.com (Andrade Software Andrade Networking) Message-Id: <199706211815.LAA19438@netcom13.netcom.com> Subject: Re: What price security? To: trei@process.com Date: Sat, 21 Jun 1997 11:15:09 -0700 (PDT) Cc: karn@Qualcomm.com, perry@piermont.com, uri@watson.ibm.com, ipsec@tis.com, andrade@netcom.com In-Reply-To: <199706201724.NAA07190@relay.rv.tis.com> from "Peter Trei" at Jun 20, 97 01:03:24 pm Sender: owner-ipsec@ex.tis.com Precedence: bulk Andrade Software & Networking Andrad@Netcom.Com X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 408 Peter Trei wrote: > > This is one place where the work that went into the DES cracking > effort can be applied. With a little one-time, startup work, you > can generate key schedules much faster than Phil's code. > This response you wrote is excellent! I'll try it out as soon as I can. - Alex -- Alex Alten P.O. Box 11406 Pleasanton, CA 94588 USA Andrade@Netcom.Com (510) 417-0159 Fax/Voice From owner-ipsec Sat Jun 21 14:36:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA08434 for ipsec-outgoing; Sat, 21 Jun 1997 14:35:41 -0400 (EDT) From: andrade@netcom.com (Andrade Software Andrade Networking) Message-Id: <199706211843.LAA21258@netcom13.netcom.com> Subject: Re: What price security? To: rgm3@chrysler.com Date: Sat, 21 Jun 1997 11:43:05 -0700 (PDT) Cc: karn@Qualcomm.com, dpkemp@missi.ncsc.mil, ipsec@tis.com In-Reply-To: <3.0.1.32.19970620143631.00a29c30@dilbert.is.chrysler.com> from "Robert Moskowitz" at Jun 20, 97 02:36:31 pm Sender: owner-ipsec@ex.tis.com Precedence: bulk Andrade Software & Networking Andrad@Netcom.Com X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 829 Robert Moskowitz wrote: > > At 09:23 AM 6/20/97 -0700, Phil Karn wrote: > >>Nonetheless, there are applications (such as gigabit routers) where the > >>processor-to-bandwidth ratio is smaller than pentium-over-modem. > > > >Which, IMHO, is yet another compelling argument for doing encryption > >on an end-to-end basis whenever possible. > > And those servers better gear up for some hefty crypto work! > Take a look at the May/June IEEE Network magazine. The 1st article by Roger Needham, "The Changing Environment for Security Protocols", is quite thought provoking. I think these technological and organizational trends he discusses will be incorporated into the future design of cryptographic protocols. - Alex -- Alex Alten P.O. Box 11406 Pleasanton, CA 94588 USA Andrade@Netcom.Com (510) 417-0159 Fax/Voice From owner-ipsec Sat Jun 21 15:01:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA08545 for ipsec-outgoing; Sat, 21 Jun 1997 15:01:12 -0400 (EDT) Date: Sat, 21 Jun 97 18:46:49 GMT From: "William Allen Simpson" Message-ID: <6070.wsimpson@greendragon.com> To: ipsec@tis.com Subject: DES futile? Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: "Perry E. Metzger" > "William Allen Simpson" writes: > > Agreed. If we change the ephemeral keys fast enough, that should be > > good for data with time value of no more than a day or two. > > I disagree. See the "Big Seven" paper: > ftp://ftp.research.att.com/dist/mab/keylength.txt > ftp://ftp.research.att.com/dist/mab/keylength.ps > I've read it. In some retrospect, you are correct; it not only depends on the time value of the data, but also the size of the attacker. Since you are in an industry where a few million $ here and there is no problem, you are saying that we need a _basic_ protection against large corporations and major governments? That is, are you saying we should abandon DES as mandatory? > > My recommendation is to poke a stick in the sand at CAST5-128. > > Unfortunately, it is too new. I'd say we mandate DES as we do now, and > recommend 3DES, which has a very solid amount of research behind > it. CAST is probably a good idea in a couple of years when its been > beaten up more. > That's why I'd poke a stick in the sand. A direction. It sounds to me like you want something "sooner". > > We could certainly use it for a few years until AES is defined and > > analysed. But do we trust the AES process? Look how NBS/NIST weakened > > DES from 112 to 56 bit keys 20 years ago! Folly! > > They didn't weaken it, Bill. It turns out that because of Differential > Cryptanalysis, LUCIFER had an inherent strenth that was far lower than > the number of keys. They only made the key length correspond to reality. > Mea Culpa, I went back and re-read Schneier on Lucifer, and you are correct. Funny how it is the "urban legend" that one remembers most clearly. I still don't trust secret design criteria and analysis! Let's remember that we are designing for the Internet, not the US NIST. Open, rough consensus, running code. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Sat Jun 21 15:25:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA08648 for ipsec-outgoing; Sat, 21 Jun 1997 15:25:43 -0400 (EDT) Date: Sat, 21 Jun 97 19:13:26 GMT From: "William Allen Simpson" Message-ID: <6071.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: calculating IVs Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Matt Thomas > If all the "shim" ESP drafts hadd agreed on a signle common IV, I > wouldn't have asked. But there was a difference and (as an implementor) > I wanted to know why (I'd rather have one common method for all the > ciphers, if possible). > Won't happen. For one thing, you are currently looking at too narrow a scope. Not all ciphers use CBC, or an IV, or the same kind of initialization. So, we cannot have "one size fits all". And the amount of code we are talking about is miniscule: switch(sp->emode){ /* Set up IV according to mode */ case DES_CBC0: case DES3_CBC0: /* IV of all zeros */ memset(iv,0,sizeof(iv)); break; case DES_CBC32: case DES3_CBC32: /* 32-bit IV repeated inverted */ pullup(bpp,iv,4); ip->length -= 4; memcpy(iv+4,iv,4); memxor(iv+4,One_bits,4); break; case DES_CBC64: case DES3_CBC64: /* Full 64-bit IV */ pullup(bpp,iv,8); ip->length -= 8; break; default: free_p(bpp); return -1; /* Unknown encryption mode */ } > >I would be willing to change. Ask the vendors that implemented RFC-1851 > >if they would be willing to change.... > > Since we seem to be doing our best to be incompatible with RFC 1851, > why do we care? Who is?!?! I'm trying my best to be compatible with what is SHIPPING. Unless there is a seriously _quantitative_ reason for changing, I'm against changing. New transforms are something else. Let's debate each on its own merits. > As much as I hate suggesting this, make it negotiable > (with the default being the same as the current behavior). If it is > really more secure (or better), those that can do it will. > What is currently written, for RFC-1829 and RFC-1851: 1) Manual configuration, leave same, selecting CBC32 (above). 2) DOI negotiation, specify change to newer version, as needed. ---- So, here's my challenge to those who want change: A) Show how much memory/bandwidth/CPU is saved or spent. B) Show the quantitative improvement in cryptographic strength. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Sat Jun 21 15:51:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA08743 for ipsec-outgoing; Sat, 21 Jun 1997 15:51:16 -0400 (EDT) Message-Id: <199706211958.PAA27695@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: Matt Thomas cc: ipsec@tis.com Subject: Re: A little social engineering In-reply-to: Your message of "Sat, 21 Jun 1997 13:32:25 EDT." <3.0.1.32.19970621133225.0075ea58@ranier.altavista-software.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Sat, 21 Jun 1997 15:58:37 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Matt Thomas writes: > [Me too!] However, at least for me, 16 round RC5 (independent of > keysize) is about twice as fast than CAST-128 in software. RC5 is patented and cannot be used without paying fees to RSADSI. > >- there's no ESP docs for IDEA, present or on the radar. > > I've thought of writing one but it hasn't been high on my list > of things I might do. Given the availability of CAST5-128 and/or > Blowfish, I don't see a pressing need for IDEA given that it's > restrictions. [Of course, one could say the same of RC5.] Blowfish worries me a bit. Many others have said long before me that the key scheduling doesn't give one a sense of comfort. > >Subjectively I think 3DES and CAST-128 are the ones to look at since (a) > >there's code, (b) there's hardware and (c) there's a low volume of negative > >cryptographic opinion on them. > > At least in my brief search, I didn't find a CAST-128 implementation There are a couple out there already, actually, but they are only now starting to pop their heads over the horizon. > but it didn't take that long to write one using RFC 2144. CAST-128 may > be too new to have much analysis done yet. I like it but it may be > premature. That is my feeling, too. I trust the creators of CAST and like the methods they employed to create it, and it feels like a good cipher to me, but I want it beaten on for a few years before I am going to trust the cipher itself. Perry From owner-ipsec Sat Jun 21 15:59:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA08783 for ipsec-outgoing; Sat, 21 Jun 1997 15:59:16 -0400 (EDT) Message-Id: <199706212006.QAA09858@coredump.cis.upenn.edu> To: "William Allen Simpson" cc: ipsec@tis.com Subject: Re: calculating IVs In-reply-to: Your message of "Sat, 21 Jun 1997 19:13:26 GMT." <6071.wsimpson@greendragon.com> Date: Sat, 21 Jun 1997 16:06:04 +0100 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In message <6071.wsimpson@greendragon.com>, "William Allen Simpson" writes: > >And the amount of code we are talking about is miniscule: > [snip code] Bill, will you stop exporting crypto code through this mailing list ? Foreigners like me might use it... - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBM6w0K70pBjh2h1kFAQGLiwQAhIVQAmis2SUrMyjGFvTZPEV8g4GA6sTI 20FyBv+REUO7ms6Jj7j4Kye09/9CAvzYTeu9qQMB2Y1ym/Q9JCbkkTU98rUn7PcS bJfDWeQAaHChSn5Red9kt8XfDAj+4XmnNZgJ1BCUwYaTPh6vYU38UL9h2Z6MRAGC iZjRRkBOl+Q= =mI2o -----END PGP SIGNATURE----- From owner-ipsec Sat Jun 21 16:13:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA08879 for ipsec-outgoing; Sat, 21 Jun 1997 16:13:17 -0400 (EDT) Message-Id: <199706212020.QAA27769@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: "William Allen Simpson" cc: ipsec@tis.com Subject: Re: DES futile? In-reply-to: Your message of "Sat, 21 Jun 1997 18:46:49 GMT." <6070.wsimpson@greendragon.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Sat, 21 Jun 1997 16:20:24 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk "William Allen Simpson" writes: > I've read it. In some retrospect, you are correct; it not only depends > on the time value of the data, but also the size of the attacker. Yup. > Since you are in an industry where a few million $ here and there is no > problem, you are saying that we need a _basic_ protection against large > corporations and major governments? > > That is, are you saying we should abandon DES as mandatory? I don't think so. I personally would prefer 3DES as the mandatory base, but it is my opinion that this working group isn't ready to do that. Remember the following: OUR PRIMARY OBJECTIVE IS TO GET THIS WORKING GROUP FINISHED AND SHUT DOWN. I cannot emphasize that enough. A battle over 3DES vs. DES as mandatory, would only slow us down. However, I can't see much resistance to making 3DES "recommended" and thus that is what I suggest -- so that we don't slow down our work. It does a lot for me anyway. If 3DES is "recommended", my clients who need it will be able to jawbone vendors to get it when they need it. We can worry about "mandatory" in a few years. Perry From owner-ipsec Sat Jun 21 21:57:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA10345 for ipsec-outgoing; Sat, 21 Jun 1997 21:56:00 -0400 (EDT) X-Sender: rah@atanda.com Message-Id: In-Reply-To: <9706211803.AA07412@mentat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 21 Jun 1997 21:52:11 -0400 To: ipsec@tis.com From: Robert Hettinga Subject: Re: Time value and 56-bit DES [Re: CAST5-128 was: A little social engineering] Sender: owner-ipsec@ex.tis.com Precedence: bulk At 2:03 pm -0400 on 6/21/97, Jim Gillogly wrote: > Depends also on the dollar value of the data. Michael Wiener's carefully > designed hardware DES-cracker (Crypto '94 rump session, I think) would > cost $1M using 1994 technology, and would produce solutions in 3.5 hrs > on average. Let's see, Moore's law gives us today, three years later than 1994, $250k. In three more years, 2000, that's, what? $62.5k? How many keys do think you need to crack to, um, amortize, that $62.5k? Hmmmmmm. So, why, exactly, do you guys *not* want to default to 3DES? Cheers, Bob Hettinga ----------------- Robert Hettinga (rah@shipwright.com), Philodox e$, 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' The e$ Home Page: http://www.shipwright.com/ From owner-ipsec Sun Jun 22 01:59:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA11425 for ipsec-outgoing; Sun, 22 Jun 1997 01:57:45 -0400 (EDT) Message-Id: <3.0.1.32.19970622013700.00af0230@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sun, 22 Jun 1997 01:37:00 -0400 To: "C. Harald Koch" , "Todd D. Ellner" From: Robert Moskowitz Subject: Re: ISAKMP encryption choices? Cc: ipsec@tis.com In-Reply-To: <97Jun20.150632edt.11650@janus.tor.securecomputing.com> References: <199706201835.LAA03809@sirius.cs.pdx.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 03:10 PM 6/20/97 -0400, C. Harald Koch wrote: >In message <199706201835.LAA03809@sirius.cs.pdx.edu>, "Todd D. Ellner" writes: >> Given the recent events in the Senate this entire discussion >> may soon become moot. The Kerrey/McCain bill (SB909) has >> REPLACED ProCODE as of last night. Mandated weak encryption, >> warrantless key recovery, only government approved algorithms, >> the whole nine yards. > >I don't know why we keep having to say this, but: > >SOME OF US ARE OUTSIDE THE USA. > >That means we can develop products (and standards!) with strong crypto, and >without key recovery, despite the foolish decisions of your politicians. > And to which countries have you been able to ship a 3DES product? Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Sun Jun 22 01:59:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA11431 for ipsec-outgoing; Sun, 22 Jun 1997 01:58:16 -0400 (EDT) Message-Id: <3.0.1.32.19970622014656.00bd52a0@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sun, 22 Jun 1997 01:46:56 -0400 To: Rodney Thayer , Reiser From: Robert Moskowitz Subject: RE: A little social engineering Cc: ipsec@tis.com In-Reply-To: <3.0.1.32.19970621101613.0070b0a4@pop3.pn.com> References: <"Your message with ID" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:16 AM 6/21/97 -0400, Rodney Thayer wrote: >Would you like to write an "ESP Shim" document proposing it? > >At this point the following ciphers have been talked about (I'm talking in >vague terms here, just from my knowledge) If anyone wishes to write an "ESP Shim", please contact me directly before you get to far into writing. A number of authors got together and came up with a consistant format. It should be published for review early next week (jul 1?). It would not be far to any new author to get too far in and then they get to rewrite. So 'call' first. I am puting together a number of documents, including an author tracking document.... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Sun Jun 22 12:07:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA13729 for ipsec-outgoing; Sun, 22 Jun 1997 12:04:29 -0400 (EDT) Date: Sun, 22 Jun 97 15:27:27 GMT From: "William Allen Simpson" Message-ID: <6072.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: calculating IVs Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: "Angelos D. Keromytis" > In message <6071.wsimpson@greendragon.com>, "William Allen Simpson" writes: > >And the amount of code we are talking about is miniscule: > [snip code] > > Bill, will you stop exporting crypto code through this mailing list ? > Foreigners like me might use it... > I'm assuming that was tongue-in-cheek :^) Of course, that code didn't meet any meaningful definition of "crypto", as it contained no cryptographic functions. But seriously, this list is the recorded minutes of an international forum conducting a conference discussing cryptographic issues. So, technically, I believe US export laws apply in the same manner that they do at IETF meetings, or Crypto'9x conferences for that matter, and the resulting published proceedings. We can and should exchange examples of cryptographic algorithms on this list. That's what we are here for.... WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Sun Jun 22 12:37:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA13849 for ipsec-outgoing; Sun, 22 Jun 1997 12:37:42 -0400 (EDT) Date: Sun, 22 Jun 1997 12:42:57 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199706221642.MAA13387@earth.hpc.org> To: ipsec@tis.com Subject: Re: What price security? Sender: owner-ipsec@ex.tis.com Precedence: bulk Is no one thinking of 100Mbs or 1Gbs ethernet or OC-3 ??? Hilarie From owner-ipsec Sun Jun 22 12:52:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA13929 for ipsec-outgoing; Sun, 22 Jun 1997 12:52:39 -0400 (EDT) Date: Sun, 22 Jun 1997 12:58:23 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199706221658.MAA13763@earth.hpc.org> To: karn@Qualcomm.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199706201923.MAA22670@baskerville.CS.Arizona.EDU> Subject: Re: What price security? Sender: owner-ipsec@ex.tis.com Precedence: bulk > I count the number of bits encrypted and divide by the "user" time > as reported by the UNIX "time" command. Don't know about your tests, but when I looked at this, almost all crypto timing tests were influenced heavily by cache effects, meaning that actual mileage is usually much lower than the tests indicate, especially on a system with a hefty job mix. Just a caveat --- real world is larger than it appears in the mirror. Hilarie From owner-ipsec Sun Jun 22 17:11:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA14861 for ipsec-outgoing; Sun, 22 Jun 1997 17:04:13 -0400 (EDT) Message-Id: <199706222122.RAA23811@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com, tcp-impl@relay.engr.sgi.com CC: vjs@mica.denver.sgi.com (Vernon Schryver) Reply-To: ipsec@tis.com Subject: ICMP must fragment and IPsec In-reply-to: Your message of "Sun, 22 Jun 1997 08:46:33 MDT." <199706221446.IAA22738@mica.denver.sgi.com> Date: Sun, 22 Jun 1997 17:22:33 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Alan" == Alan Cox writes: Alan> This is becoming more and more obvious. Also IPSEC still Alan> doesnt address the ICMP MUST FRAGMENT tcp denial attacks >>>>> "Perry" == Perry Metzger writes: Perry> What attacks would those be? Alan> Send an ICMP MUST FRAGMENT MTU=68 to someone running a secure Alan> session. Now they can pick either Alan> Alan> 1. Ignore it because it isnt signed - doesn't work because the Alan> packet may be real mtu lowering info Alan> Alan> 2. Believe it and watch the peformance crash Alan> Alan> The problem is this is the one case where we have to trust a Alan> potentially unsigned frame if we want to do TCP mtu Alan> discovery. If you drop MTU discovery from secure TCP sessions Alan> it seems ok >>>>> "Vernon" == Vernon Schryver writes: Vernon> You omitteded the most reasonable response: Vernon> 3. ignore it because 68 is so ridiculously tiny that it Vernon> is obviously bogus and if the path MTU were that bad, you Vernon> may as well close the connection. Vernon> "Be generous in what you accept" is not the same "be Vernon> stupid and do not sanity-check anything." Vernon> Reasonable systems should drop any demands for an MTU less Vernon> than 128 and probably anything less than 256. 256 is Vernon's suggestions seem rather good judgement, but the need for some kind of authenticated Path MTU discovery is important, in my opinion. One way might be to have an ICMP or TCP option that requests the other end to provide a response, giving the size of the largest fragment received. This would be enclosed in the SA that the TCP data is flowing in. This is in some sense a variation of the TCP MSS option. A TCP option is probably harder to implement, and harder to deploy, but has the advantage of not requiring another packet, and not requiring any dances with ISAKMP per-protocol/port ("connection") SA keying. However, we already have to deal with making sure that other TCP related ICMPs get transported/tunnelled properly. [ICMP_UNREACH, ICMP_SOURCEQUENCH, are there others?] An ICMP option has the advantages that it doesn't require TCP to know anything about the fragmentation of the packets, which is just gross. Still, ICMP then needs to know, but that might be easier for some people to implement. Another possibility would be to have the receiver advise the sender in a TCP option, whenever the max-size fragment received in past 2MSL changes by more than 10%. This might be more effective in the cases where the route changes in a way that affects the MTU, than Path MTU discovery, which as far as I understand, only is done at the beginning of the connection. [... not according to rfc1191. The DF bit is set on all packets, so PMTU is always done] I can't think of many cases in the current deployed internet where the MTU might change during a connection. Usually, the smallest MTU is on the edges at that 28.8 (or that 2400 baud modem) link, and that isn't likely to change suddendly. I can see mobileip possibly changing this. If/when mobileip is deployed en-mass, it will definitely include IPsec. Getting Path MTU information back to the sending TCP is not an unsurmountable challenge to VPN uses of IPsec, but it isn't easy. In the case of "Virtual Circuit" style security gateway traversal (see draft-richardson-ipsec-traversal-cert-00.txt), there are several MTU's involved: the end to end MTU, and the MTU between each security gateway. Both are important to know. An argument against the TCP option (and for an authenticated ICMP) is that it would not be usable with non-TCP things, like ESP. Note: when I say authenticated ICMP, I mean using either ESP or AH. Probably the ICMP is no less sensitive as the data, so ESP if the data is encrypted. In conclusion: an ICMP need frag message placed in the tunnel :!mcr!: | Network security programming, currently Michael Richardson | on contract with DataFellows F-Secure IPSec WWW: mcr@sandelman.ottawa.on.ca. PGP key available. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBM62XlKZpLyXYhL+BAQH9dAMAuR/oq9ylmAAvBl7Kedg/v9O4Z3/5kwwJ gzJ8WqQ8FIKXqPf7GYHNsIQxNBDztZzgZ/c+9r7sbRTqSVeelvcNr51lLp+fBhHz 3OFufP+Gn0W4TOFIPaPIbOtPf2d+rIkH =SIJJ -----END PGP SIGNATURE----- From owner-ipsec Sun Jun 22 21:57:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA16068 for ipsec-outgoing; Sun, 22 Jun 1997 21:55:59 -0400 (EDT) Message-Id: <199706230220.WAA24200@istari.sandelman.ottawa.on.ca> To: vjs@mica.denver.sgi.com (Vernon Schryver) CC: tcp-impl@relay.engr.sgi.com, ipsec@tis.com Subject: Re: ICMP must fragment and IPsec In-reply-to: Your message of "Sun, 22 Jun 1997 17:33:49 MDT." <199706222333.RAA23828@mica.denver.sgi.com> Date: Sun, 22 Jun 1997 22:20:22 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- [I'm hesitant about continuing to post this to both lists, but I'm not sure where else it should go. I know that it doesn't really fit into either charter, since we aren't documenting TCP bugs that need fixing, and aren't discussing the things that we REALLY need to finish to terminate the IPsec group. Please give me advice by private email. Maybe I should write this up as a draft, since I can see it getting more fleshed out in my mind.] >>>>> "Vernon" == Vernon Schryver writes: Vernon> What is this "other end"? If talking to the other end of Vernon> a TCP connection were enough, then the MSS negotiation Vernon> would be enough and the Path MTU Discovery mechanism would Vernon> not be needed. In fact, the MSS negotiation is often not I am assuming that packets that are sent that are too big, or become too big due to n-levels of ESP/AH transport/tunnels will be fragmented if the DF bit is not set. How much the packet gets fragmented can be determined by the receiving host and/or tunnel end-point: it can observe the largest fragment that was successfully received and participated in reassembly. This information can be relayed to the sending host via an ICMP Datagram Too Big message that can be put into the tunnel. This appears to screwed up by multiple paths with different MTUs. However, it is easily fixed by only taking PMTU information from packets that were fragmented: a larger packet that arrives intact clearly took a different route, so it doesn't matter. Eventually, if the correspondant nodes can adjust their PMTU appropriately, all packets arrive unfragmented. Clearly, the rate that ICMP's are sent needs to be limited to not more than one per RTT. This works well on the end system that reassembles the packets. So, getting an estimate of the PMTU from a transport mode, or tunnel mode terminating on the end node is easy. If the tunnel doesn't terminate on the end node (but on a security gateway), then one observes that the gateway must reassemble the ESP or AH packets to terminate the tunnel. The gateway node can there a) send an ICMP (in transport? or tunnel?) to the originating gateway, informing it of the PMTU that it sees, and the originating gateway will send an ICMP to nodes that set the DF bit when they do normal PMTU. b) alternatively, the PMTU between gateways could be communicated with an ISAKMP message. c) send an ICMP through the tunnel, to the TCP originating (TLO in the terminology of my traversal draft) node. The TLO sees this packet just like it would when it got ICMP messages when security wasn't present. However, it never sees the routes that were tunnelled through, but the far end tunnel point would collect all that info for it anyway. BTW: not all current IPsec implementations do the right thing with the DF flag. In theory, a DF flag on a packet going into a tunnel should cause the tunnel wrapper to have the DF bit set, and the ICMP Datagram Too Big messages adjusted in size and passed back to the originating host. This assumes we can trust them. At least one implementation in Detroit dropped the packets immediately, since the new packet size didn't fit the outgoing interface's MTU, so the ICMP would have been trusted in that case. My recommendation is to never set the DF bit on the outside packet until you can deal with the ICMP. That is, the problem is punted for a future working group, but it means that IPsec VPN tunnels become non-compliant routers since they don't honour the DF bit. Vernon> The trouble with authenticating path MTU information Vernon> (regardless of its form) is key distribution. How would My position is that you can't distribute the keys. Please see my draft for another place where it appears the intermediate security gateways need the keys. Vernon> The only response to worries about path MTU messages, as Vernon> well as source quences, port, net, and host Unreachables, Vernon> and many other such indications is to be to cross your Vernon> fingers and ignore any that would have serious Vernon> consequences, such as an message telling you to use an MTU Vernon> of 68. I think we can do better than that. >> ... I can't think of many cases in the current deployed >> internet where the MTU might change during a >> connection. Usually, the smallest MTU is on the edges at that >> 28.8 (or that 2400 baud modem) link, and that isn't likely to >> change suddendly. I can see mobileip possibly changing >> this. If/when mobileip is deployed en-mass, it will definitely >> include IPsec. Vernon> There is a vast amount of topology on the edges, what with Vernon> ATM (9180), FDDI (4352), Ethernet (1500 or 1492), PPP (256 Vernon> to more than 1500), and Frame Relay. But, do any of these things *change* during the course of a TCP connection? While the routing on the backbone might change, my guess is that the MTU between backbone nodes is almost always going to be more than the 1500 typical of a T1. I guess, two networks, that do ATM with their supplier could get a much lower MTU if the supplier's ATM backbone goes down, and the move their backup T1s. Vernon> Besides, if you stay away from the edges and in the center Vernon> where routes don't flap among links with different MTU's, Vernon> you may as well fix your MTU=1500 and forget Path MTU Vernon> discover. Yes, there is this option. >> Getting Path MTU information back to the sending TCP is not an >> unsurmountable challenge to VPN uses of IPsec, but it isn't >> easy. Vernon> On the contrary, I think the key distribution problem is Vernon> insurmountable and makes authenticated path MTU Vernon> information impossible. For example, look at any real I agree: trying to get the ICMP Datagram Too Big messages authenticated is not possible. I don't agree that getting authenticated PMTU information is impossible. :!mcr!: | Network security programming, currently Michael Richardson | on contract with DataFellows F-Secure IPSec WWW: mcr@sandelman.ottawa.on.ca. PGP key available. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBM63dYaZpLyXYhL+BAQEYaQL/fWe8YzpkZAGRKsGTEv8PJ0sQyM1Jlx4I NmJCIj8Y9y1+giyg1ZZeLhmh0x15nYQnt/0dH1I3sf+KXZRIYz00LfPVq13MLAkP 5uijiFUS3c6UddKCTwOrR08uqwhydSG/ =1PJL -----END PGP SIGNATURE----- From owner-ipsec Mon Jun 23 03:24:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA17602 for ipsec-outgoing; Mon, 23 Jun 1997 03:20:45 -0400 (EDT) Organization: ESAT, K.U.Leuven, Belgium Date: Mon, 23 Jun 1997 09:27:06 +0200 (METDST) From: Bart Preneel To: Rodney Thayer cc: Reiser , ipsec@tis.com Subject: RE: A little social engineering In-Reply-To: <3.0.1.32.19970621101613.0070b0a4@pop3.pn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Below a comparison of several block cipher speeds. All these ciphers have been published in the literature; most of them in the "Fast Software Encryption" series of workshops (Springer-Verlag LNCS). The numbers are taken from a paper entitled "Recent Developments in the Design of Conventional Cryptographic Algorithms" by Bart Preneel, Vincent Rijmen and Antoon Bosselaers, to appear soon in the course proceedings of the 1997 K.U.Leuven Summer Course on Cryptography (Springer-Verlag LNCS series). If you have never heard of SQUARE, visit http://www.esat.kuleuven.ac.be/~rijmen/square. The cipher has been designed by some European cryptanalysts (Daemen-Knudsen-Rijmen); it has not been pushed by a North-American company ;-) If you want pointers to descriptions or attacks (and to even more block ciphers), check the "block cipher lounge": http://www.esat.kuleuven.ac.be/~knudsen/bc No cipher has been analyzed as much as DES (>> 25 person-years). IDEA is a very distant second (a few person-years). IMHO, all the others are at about the same level (at most 1 person-year). But I would prefer a cipher of someone who has published a few serious attacks. One conclusion is that these 2 stream ciphers are still a lot faster than block ciphers (although a potential weakness of SEAL have been identified at the last Fast Software Encryption conference in Haifa). Finally a note on DES-X: - differential and linear cryptanalysis of DES-X is indeed slightly harder than that of DES (but not as much as has been claimed). - for 2**32 known plaintexts (the limit imposed by CBC-mode), the effective key size is 86 bits. Bart Preneel ------------------------------------------------------------------------------- Katholieke Universiteit Leuven tel. +32 16 32 11 48 Dept. Electrical Engineering-ESAT / COSIC fax. +32 16 32 19 86 K. Mercierlaan 94, B-3001 Heverlee, BELGIUM bart.preneel@esat.kuleuven.ac.be http://www.esat.kuleuven.ac.be/~preneel ------------------------------------------------------------------------------- Processor: 90 MHz Pentium Speed: Mbit/s Author: Antoon Bosselaers Blowfish 36.5 CAST 24.4 DES 16.9 3DES 6.20 IDEA 9.75 Performance suffers from the slow integer multiplication taking 9 cycles. A 1-cycle multiply would almost double the speed of IDEA. Khufu 43.6 RC5-32/16 29.1 SAFER K-64 22.3 SAFER SK-64 17.0 SAFER (S)K-128 13.8 SHARK 9.85 The tables are too large to fit in the on-chip cache, causing performance degradation. A large enough cache would result in an improvement of more than a factor 4 (43.2 Mbit/s).} RC5-64/24 14.4 SQUARE 35.6 Stream ciphers (good estimates): SEAL 200 Mbit/s alleged RC-4 100 Mbit/s ============================================================================== [...] > >> Unfortunately, there doesn't seem to be any 'popular' alternatives to > >> DES that everyone could agree on being mandatory. > >> > >> - RC5 is patented by RSA and, I believe, is licensable > >> - CAST-128 is patented by Entrust, but free and is relatively new > >> - IDEA is patented by ETH and licensable from Ascom Systek > >> > >> That leaves us with; > >> > >> - 3DES is slower than all of the above, but free > >> - BlowFish is not that widely used and not that analyzed (Bruce > >> Schneir would disagree) > >> > >> > >> [ No slurs intended, since I'm definately not a cryptographer! ] > >> > >> From owner-ipsec Mon Jun 23 08:23:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA19534 for ipsec-outgoing; Mon, 23 Jun 1997 08:20:35 -0400 (EDT) Date: Sun, 22 Jun 1997 17:33:49 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199706222333.RAA23828@mica.denver.sgi.com> To: tcp-impl@relay.engr.sgi.com, ipsec@tis.com Subject: Re: ICMP must fragment and IPsec Sender: owner-ipsec@ex.tis.com Precedence: bulk > To: ipsec@tis.com, tcp-impl@cthulhu.engr.sgi.com > CC: vjs (Vernon Schryver) > One way might be to have an ICMP or TCP option that requests the > other end to provide a response, giving the size of the largest > fragment received. This would be enclosed in the SA that the TCP data > is flowing in. This is in some sense a variation of the TCP MSS option. What is this "other end"? If talking to the other end of a TCP connection were enough, then the MSS negotiation would be enough and the Path MTU Discovery mechanism would not be needed. In fact, the MSS negotiation is often not enough because a vast number of boxes between the ends might legitimately tell you to reduce your MTU. The boxes in the path vary, as routes change. Not only might every router that might sometimes be in the path need to send a reduce-MTU indication of some kind, but so might bridges (e.g FDDI-Ethernet bridges that necessarily IP fragment, honor the DF bit, and send the ICMP message.) The trouble with authenticating path MTU information (regardless of its form) is key distribution. How would you get the right key to all of the boxes that might be in the path so that you could trust them? Given the implications for the security of the keys in sending them to every router in the net that might touch youyr packets, who would want to? You can't just determine that a box is who it says it is. After you authenticate box99.bad.guy.com as the sender of the ICMP error message telling you to use an MTU of 68, what do you do? The only response to worries about path MTU messages, as well as source quences, port, net, and host Unreachables, and many other such indications is to be to cross your fingers and ignore any that would have serious consequences, such as an message telling you to use an MTU of 68. > ... > I can't think of many cases in the current deployed internet where > the MTU might change during a connection. Usually, the smallest MTU is > on the edges at that 28.8 (or that 2400 baud modem) link, and that > isn't likely to change suddendly. I can see mobileip possibly changing > this. If/when mobileip is deployed en-mass, it will definitely include > IPsec. There is a vast amount of topology on the edges, what with ATM (9180), FDDI (4352), Ethernet (1500 or 1492), PPP (256 to more than 1500), and Frame Relay. Besides, if you stay away from the edges and in the center where routes don't flap among links with different MTU's, you may as well fix your MTU=1500 and forget Path MTU discover. > Getting Path MTU information back to the sending TCP is not an > unsurmountable challenge to VPN uses of IPsec, but it isn't easy. On the contrary, I think the key distribution problem is insurmountable and makes authenticated path MTU information impossible. For example, look at any real life network and see how many FDDI-EThernet bridges there are that have not been given a IP address (manually or by bootp or DHCP) and so cannot send the ICMP message when the drop an packet with the DF bit set. If people cannot manage to set their IP addresses (thus wrecking not only MTU discovery but SNMP), how can you expect them to do something useful about keys? Vernon Schryver, vjs@sgi.com From owner-ipsec Mon Jun 23 08:35:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA19724 for ipsec-outgoing; Mon, 23 Jun 1997 08:34:10 -0400 (EDT) Date: Sun, 22 Jun 1997 21:11:29 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199706230311.VAA24233@mica.denver.sgi.com> Subject: Re: ICMP must fragment and IPsec Cc: ipsec@tis.com, tcp-impl@cthulhu.engr.sgi.com Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: "Michael C. Richardson" > ... > >> ... I can't think of many cases in the current deployed > >> internet where the MTU might change during a > >> connection. ... > Vernon> There is a vast amount of topology on the edges, what with > Vernon> ATM (9180), FDDI (4352), Ethernet (1500 or 1492), PPP (256 > Vernon> to more than 1500), and Frame Relay. > > But, do any of these things *change* during the course of a TCP > connection? They do, at least for plain-vanilla IP in Silicon Graphic's internal network. (Lots of FDDI and some ATM and HIPPI backbones.) Of course, anything through the Internet will be probably filtered to 1500, but anyone with HIPPI, 802.5, FDDI, or some flavors of ATM will have other PMTU's, at least for "servers on the backbone". Add a little redundancy--say a few high-metric backup 1500 links in your campus, and it's easy to get flappying in your PMTU for some real applications. For the duration of an HTTP 1.0 transfer, you'd expect the PMTU to be constant. I often have TCP connections that stay up for days. Often when demand-dialed PPP/ISDN dies, I switch to PPP/modems, and then back to PPP/ISDN, keeping the same TCP connections alive. If I followed conventional wisdom for modems, I'd be switching between 1500 and something smaller. > While the routing on the backbone might change, my guess is that the > MTU between backbone nodes is almost always going to be more than the > 1500 typical of a T1. I guess, two networks, that do ATM with their > supplier could get a much lower MTU if the supplier's ATM backbone > goes down, and the move their backup T1s. Yes, of course, on the "backbone" (whatever that means today). But anyone with FDDI, HIPPI, ATM, 802.5, and PPP out in the marches (marshes?) has other PMTU's some of the time, at least between "big servers on the backbone." Consider big NFS servers doing network backups. > I don't agree that getting authenticated PMTU information is > impossible. Again, how? Say you do authenticate router99.bad.guy.net as the furshure source of the PMTU info, in whatever form, that you just got. How do you know that router99.bad.guy.net is in your path? It seems to me that if you could know your path reliably, a lot of problems would be vastly easier, from IP security to IP routing. For that matter, if you know which routers that might touch your packets, then also knowing the MTU's of their links is a trivial addition, and so you don't need any ad hoc or post hoc Path MTU discoverying, timers, probing, DF-bit kludges, lost user-data etc. Well, I guess you could require everyone use a link-state routing protocol that covers the entire Internet, and have every host maintain a global link-state table, and pay attention to PMTU, source quench, etc only from routers that are on a path that is close to the current minimum for your packets. Or continually use something like `traceroute` to map the path, and pay attention only to PTMU info from close to most recent path. Or we could get rid of TCP and switch to XTP--I think the initial route setup of XTP could be changed to track the path. Or best, get rid of IP and run TCP over ATM end-to-end. My point is that (reasonable) packet switching means not knowing who's moving your packets, at least in large networks, and there's no escaping the implications of that fact. Vernon Schryver, vjs@sgi.com $dOI+2ztӂjA9&\ .pdefaults .loc-cshrc .nevotinit .gamtables .signature .sgihelprc .insightrc .Xdefaults From owner-ipsec Mon Jun 23 09:55:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA20448 for ipsec-outgoing; Mon, 23 Jun 1997 09:52:28 -0400 (EDT) Date: Mon, 23 Jun 1997 09:42 -0400 From: VOLZ@process.com (Bernie Volz) Message-Id: <009B6342469A34A0.31C9@PROCESS.COM> To: vjs@mica.denver.sgi.com, TCP-IMPL@RELAY.ENGR.SGI.COM, IPSEC@tis.com Subject: Re: ICMP must fragment and IPsec X-VMS-To: SMTP%"vjs@mica.denver.sgi.com" X-VMS-Cc: TCP-IMPL@RELAY.ENGR.SGI.COM, IPSEC@TIS.COM Sender: owner-ipsec@ex.tis.com Precedence: bulk >What is this "other end"? >If talking to the other end of a TCP connection were enough, then the >MSS negotiation would be enough and the Path MTU Discovery mechanism >would not be needed. In fact, the MSS negotiation is often not enough >because a vast number of boxes between the ends might legitimately tell >you to reduce your MTU. Please don't confuse MSS with MTU. The Maximum Segment Size has *NOTHING* to do with MTU. The MSS reflects what the maximum segment size a TCP implementation is willing and able to receive and that has nothing to do with the MTU of an interface. For example ... if MSS was MTU, what would happen if a multi-homed host with an Ethernet and FDDI interface switched a connection from Ethernet (w/MTU of 1500) to FDDI (w/MTU of 4352). You would *NOT* have wanted TCP to send an MSS with only 1500. - Bernie Volz Process Software Corporation From owner-ipsec Mon Jun 23 11:21:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA21068 for ipsec-outgoing; Mon, 23 Jun 1997 11:19:41 -0400 (EDT) Message-Id: <3.0.1.32.19970623112617.00985100@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 23 Jun 1997 11:26:17 -0400 To: ipsec@tis.com From: Robert Moskowitz Subject: request for time at IPsec session in Munich Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Please get your time slot requests in to Ted and myself so we can work up an agenda. A person can request to personally discuss an issue or have an issue for general resolution. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Mon Jun 23 11:26:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA21121 for ipsec-outgoing; Mon, 23 Jun 1997 11:26:14 -0400 (EDT) Date: Mon, 23 Jun 1997 10:33:25 -0500 From: Matt Crawford Subject: Re: ICMP must fragment and IPsec In-reply-to: "22 Jun 1997 17:33:49 MDT." <"199706222333.RAA23828"@mica.denver.sgi.com> To: vjs@mica.denver.sgi.com (Vernon Schryver) Cc: tcp-impl@relay.engr.sgi.com, ipsec@tis.com Message-id: <199706231533.KAA12274@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ > One way might be to have an ICMP or TCP option that requests the > > other end to provide a response, giving the size of the largest > > fragment received. This would be enclosed in the SA that the TCP data > > is flowing in. This is in some sense a variation of the TCP MSS option. > > What is this "other end"? > If talking to the other end of a TCP connection were enough, then the > MSS negotiation would be enough ... No, I think he meant for one end to tell the other what was the size of the largest IP packet-or-fragment it has actually received. It can't rightly be a TCP option, because TCP wouldn't know this. And besides, it becomes pretty hairy at any level when you try to find out what was the largest packet received "lately." Ugh. Matt Crawford From owner-ipsec Mon Jun 23 11:30:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA21143 for ipsec-outgoing; Mon, 23 Jun 1997 11:30:46 -0400 (EDT) Message-Id: <3.0.1.32.19970623113559.00c95ec0@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Mon, 23 Jun 1997 11:35:59 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: How to negotiate key length with ISAKMP? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk With CAST (and RC5, and ARCFOUR...) we are going to want to negotiate key length. I think that we need another Attribute Class in the DOI document. Looking at draft-ietf-ipsec-ipsec-doi-02, I think we'd need to add Attibute Class 12, "Key Length". Is this how this should be handled? Is there a better way? Comments? Please assume for the moment the set of key lengths proposed in the CAST and other documents are acceptable. I don't mean to start a "how long should my key be" debate. >From: "Edward A. Russell" >To: "'Rodney Thayer'" >Subject: Negotiation Key Length >Date: Mon, 23 Jun 1997 11:17:04 -0400 > >Evidence indicates that key length is specified by the transform draft. >We would want an ISAKMP attribute associated with the transform which specifies >key length. The attribute would be optional, and the transform draft >MUST specify a default key length to be used when key length is >not specified during ISAKMP negotiation. > >Excerpt From Resolution Document - Appendix B > > When a service (such as an IPSEC transform) utilizes ISAKMP to generate > keying material, all encryption algorithm specific details (such as key > and IV generation, padding, etc...) MUST be defined by that service. > ISAKMP does not purport to ever produce keys that are suitable for any > encryption algorithm. ISAKMP produces the requested amount of keying > material from which the service MUST generate a suitable key. Details, such > as weak key checks, are the responsibility of the service. > >Excerpt from ISAKMP draft - section 1.4.1 Security Associations and Registration > >The SA attributes required and recommended for the IP Security (AH, ESP) >are defined in [RFC-1825]. The attributes specified for an IP Security SA >include, but are not limited to, authentication mechanism, cryptographic >algorithm, algorithm mode, key length, and Initialization Vector (IV). >Other protocols that provide algorithm and mechanism independent secu- >rity MUST define their requirements for SA attributes. The separation of >ISAKMP from a specific SA definition is important to ensure ISAKMP can es- >tablish SAs for all possible security protocols and applications. > >NOTE: See [IPDOI] for a discussion of SA attributes that should be consid- >ered when defining a security protocol or application. > >Edward Russell >erussell@ftp.com > > > From owner-ipsec Mon Jun 23 11:50:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA21327 for ipsec-outgoing; Mon, 23 Jun 1997 11:49:54 -0400 (EDT) Date: Mon, 23 Jun 1997 09:57:20 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199706231557.JAA25294@mica.denver.sgi.com> To: ipsec@tis.com, tcp-impl@cthulhu.engr.sgi.com Subject: Re: ICMP must fragment and IPsec Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Matt Crawford > To: vjs (Vernon Schryver) > Cc: tcp-impl@cthulhu.engr.sgi.com, ipsec@tis.com > > > One way might be to have an ICMP or TCP option that requests the > > > other end to provide a response, giving the size of the largest > > > fragment received. This would be enclosed in the SA that the TCP data > > > is flowing in. This is in some sense a variation of the TCP MSS option. > > > > What is this "other end"? > > If talking to the other end of a TCP connection were enough, then the > > MSS negotiation would be enough ... > > No, I think he meant for one end to tell the other what was the size > of the largest IP packet-or-fragment it has actually received. It > can't rightly be a TCP option, because TCP wouldn't know this. And > besides, it becomes pretty hairy at any level when you try to find > out what was the largest packet received "lately." Ugh. Yes, I foolishly missed that very interesting idea. I'm not bothered by the "lately" in "the largest packet received lately", since you must have timers even to use the DF bit. The idea just moves the timers. Instead, it bothers me that: - it requires changes in both hosts. PMTU discovery is a hack that works without any changes in the rest of the net including the peer. Consider how long it has taken for routers to support the improved ICMP error message. - it also requires protocol changes. The IETF aint what it used to be. - when would you re-probe to discover if the PMTU has increased? This is not a showstopper, but doesn't have an obviously neat answer. - I think it assumes UDP does not need PMTU discovery. - it assumes no intermediate router is doing fragment reassembly I don't know of any that do that, but it is a recurring idea for good reasons. - the largest fragment is as large as PMTU. First, since all but the last IP fragment must be a multiple of 8 bytes, the largest fragment will generally be the largest multiple of 8 less or equal to the MTU. For example, you'll probably guess 1496 or 1488 instead of 1500 or 1492 for an Ethernet segment. Second, instead of the usual algorithm, a router might try to fragment into evenly sized pieces. At the cost of a divide instruction (cheap on modern CPU's), that can reduce the total fragmentation should the datagram have to be fragmented twice. Consider the silly UDP/IP fragment sizes seen often seen from NFS servers with FDDI interfaces. Vernon Schryver, vjs@sgi.com From owner-ipsec Mon Jun 23 14:27:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA22418 for ipsec-outgoing; Mon, 23 Jun 1997 14:25:11 -0400 (EDT) Message-Id: <199706231726.KAA12912@gecko.nas.nasa.gov> To: Matt Crawford cc: vjs@mica.denver.sgi.com (Vernon Schryver), tcp-impl@cthulhu.engr.sgi.com, ipsec@tis.com Subject: Re: ICMP must fragment and IPsec In-reply-to: Your message of "Mon, 23 Jun 1997 10:33:25 CDT." <199706231533.KAA12274@gungnir.fnal.gov> Date: Mon, 23 Jun 1997 10:26:29 -0700 From: "Kevin M. Lahey" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199706231533.KAA12274@gungnir.fnal.gov>Matt Crawford writes >> > One way might be to have an ICMP or TCP option that requests the >> > other end to provide a response, giving the size of the largest >> > fragment received. This would be enclosed in the SA that the TCP data >> > is flowing in. This is in some sense a variation of the TCP MSS option. >> >> What is this "other end"? >> If talking to the other end of a TCP connection were enough, then the >> MSS negotiation would be enough ... > >No, I think he meant for one end to tell the other what was the size >of the largest IP packet-or-fragment it has actually received. It >can't rightly be a TCP option, because TCP wouldn't know this. And >besides, it becomes pretty hairy at any level when you try to find >out what was the largest packet received "lately." Ugh. Then, too, wouldn't this would fail under IPv6, since only the originating host can fragment packets? If routers are just dropping the packets (and sending ICMP messages) rather than fragmenting and forwarding, the end system would never get any useful fragment sizes to deal with. Kevin Lahey kml@nas.nasa.gov From owner-ipsec Mon Jun 23 14:56:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA22670 for ipsec-outgoing; Mon, 23 Jun 1997 14:56:31 -0400 (EDT) Date: Mon, 23 Jun 97 11:57:48 PDT From: jim@mentat.com (Jim Gillogly) Message-Id: <9706231857.AA18883@mentat.com> To: ipsec@tis.com Subject: Re: Time value and 56-bit DES [Re: CAST5-128 was: A little social engineering] Sender: owner-ipsec@ex.tis.com Precedence: bulk Bob Hettinga says: > > At 2:03 pm -0400 on 6/21/97, Jim Gillogly wrote: > > Depends also on the dollar value of the data. Michael Wiener's carefully > > designed hardware DES-cracker (Crypto '94 rump session, I think) would > > cost $1M using 1994 technology, and would produce solutions in 3.5 hrs > > on average. > > Let's see, Moore's law gives us today, three years later than 1994, $250k. > In three more years, 2000, that's, what? $62.5k? How many keys do think you > need to crack to, um, amortize, that $62.5k? >... > So, why, exactly, do you guys *not* want to default to 3DES? As Perry Metzger points out, the idea is to get a standard quickly that the group can agree on. While DES is not adequate for protecting individual sessions, it's a first step that would be a severe bar to anyone hoovering up all Internet traffic and trying to make sense out of it, especially with frequent key changes -- thus its ubiquitious use would be a plus for general security. A specific target isn't safe, but the collateral damage is limited. If people want real security, they can use the recommended stronger cipher. DES doesn't make the Net go dark to the attacker, but it's a fairly good shade of gray for a start. Jim Gillogly From owner-ipsec Mon Jun 23 15:42:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA23019 for ipsec-outgoing; Mon, 23 Jun 1997 15:41:33 -0400 (EDT) Message-Id: <199706231948.PAA00733@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: Rodney Thayer cc: ipsec@tis.com Subject: Re: How to negotiate key length with ISAKMP? In-reply-to: Your message of "Mon, 23 Jun 1997 11:35:59 EDT." <3.0.1.32.19970623113559.00c95ec0@pop3.pn.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 23 Jun 1997 15:48:31 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Rodney Thayer writes: > With CAST (and RC5, and ARCFOUR...) we are going to want to negotiate key > length. Not to say that you aren't right about needing to negotiate key lengths in general, and certainly with RC4 and RC5, but I believe CAST-64 and CAST-128 are really different algorithms, not a single algorithm with a variable sized key length. Perry From owner-ipsec Mon Jun 23 18:10:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA23824 for ipsec-outgoing; Mon, 23 Jun 1997 18:05:52 -0400 (EDT) Message-Id: <199706232229.SAA28872@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: How to negotiate key length with ISAKMP? In-reply-to: Your message of "Mon, 23 Jun 1997 15:48:31 EDT." <199706231948.PAA00733@jekyll.piermont.com> Date: Mon, 23 Jun 1997 18:29:11 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Perry" == Perry E Metzger writes: Perry> Not to say that you aren't right about needing to negotiate Perry> key lengths in general, and certainly with RC4 and RC5, but Perry> I believe CAST-64 and CAST-128 are really different Perry> algorithms, not a single algorithm with a variable sized Perry> key length. But, are we really going to want 76 bit and 72 bit rc4? I think there might be three, maybe four key sizes, and that is it. I know that there are two: 40 bit and 128 bit. Are there really more? I think that algorithms of differing key sizes are as different from a policy point of view as different algorithms. :!mcr!: | Network security programming, currently Michael Richardson | on contract with DataFellows F-Secure IPSec WWW: mcr@sandelman.ottawa.on.ca. PGP key available. From owner-ipsec Mon Jun 23 18:48:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA24070 for ipsec-outgoing; Mon, 23 Jun 1997 18:48:03 -0400 (EDT) Message-ID: <01BC7FED.CC9DC680@BIGHUGE> From: Rob Adams To: "'Michael C. Richardson'" , "ipsec@tis.com" Subject: RE: How to negotiate key length with ISAKMP? Date: Mon, 23 Jun 1997 15:54:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Blowfish has a variable length key up to 448. Just throwing it out there, I know people don't want to hear it because "Blowfish hasn't been tested." However.... In any case, there is a difference between the length of the key used for a particular algorithm and the length of the keying material required.. Here we are at slicing and dicing again. I've haven't been following the discussion much lately due to some overwhelming commitments.. In any case, were are we on the slicing and dicing issue. I know there were concerns about entropy which I don't think were resolved. Please forgive if any of my comments are counter to a resolution to slicing and dicing made in this group. And if my comments are counter, could someone please post the solution/resolution??? If we are allowing the IPSEC algorithms themselves to do the slicing and dicing, then one big slab o' keying material should be negotiated by ISAKMP. The IPSEC algorithm should be able to suggest its desired key length and ISAKMP should provide a hunk of keying material of the requested size or larger. How the keying material is used by IPSEC is irrelevant no? Whether it be a variable length Blowfish key plus a key to do HMAC SHA with or simply a 128 bit MD5 key doesn't matter, does it? -Rob -----Original Message----- From: Michael C. Richardson [SMTP:mcr@sandelman.ottawa.on.ca] Sent: Monday, June 23, 1997 3:29 PM To: ipsec@tis.com Subject: Re: How to negotiate key length with ISAKMP? >>>>> "Perry" == Perry E Metzger writes: Perry> Not to say that you aren't right about needing to negotiate Perry> key lengths in general, and certainly with RC4 and RC5, but Perry> I believe CAST-64 and CAST-128 are really different Perry> algorithms, not a single algorithm with a variable sized Perry> key length. But, are we really going to want 76 bit and 72 bit rc4? I think there might be three, maybe four key sizes, and that is it. I know that there are two: 40 bit and 128 bit. Are there really more? I think that algorithms of differing key sizes are as different from a policy point of view as different algorithms. :!mcr!: | Network security programming, currently Michael Richardson | on contract with DataFellows F-Secure IPSec WWW: mcr@sandelman.ottawa.on.ca. PGP key available. From owner-ipsec Mon Jun 23 18:56:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA24154 for ipsec-outgoing; Mon, 23 Jun 1997 18:56:34 -0400 (EDT) Message-Id: <199706232303.TAA02274@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: "Michael C. Richardson" cc: ipsec@tis.com Subject: Re: How to negotiate key length with ISAKMP? In-reply-to: Your message of "Mon, 23 Jun 1997 18:29:11 EDT." <199706232229.SAA28872@istari.sandelman.ottawa.on.ca> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 23 Jun 1997 19:03:54 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk "Michael C. Richardson" writes: > But, are we really going to want 76 bit and 72 bit rc4? I think > there might be three, maybe four key sizes, and that is it. I know > that there are two: 40 bit and 128 bit. Are there really more? > I think that algorithms of differing key sizes are as different from > a policy point of view as different algorithms. You have a point. .pm From owner-ipsec Tue Jun 24 07:56:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA28583 for ipsec-outgoing; Tue, 24 Jun 1997 07:54:17 -0400 (EDT) Date: Tue, 24 Jun 1997 07:54:17 -0400 (EDT) From: owner-ipsec@ex.tis.com From: Greg Carter To: "'perry@piermont.com'" Cc: "'ipsec@tis.com'" Subject: RE: How to negotiate key length with ISAKMP? Date: Tue, 24 Jun 1997 07:43:22 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk >---------- >From: Perry E. Metzger[SMTP:perry@piermont.com] >Sent: Monday, June 23, 1997 3:48 PM >To: Rodney Thayer >Cc: ipsec@tis.com >Subject: Re: How to negotiate key length with ISAKMP? > > >Rodney Thayer writes: >> With CAST (and RC5, and ARCFOUR...) we are going to want to negotiate key >> length. > >Not to say that you aren't right about needing to negotiate key >lengths in general, and certainly with RC4 and RC5, but I believe >CAST-64 and CAST-128 are really different algorithms, not a single >algorithm with a variable sized key length. > >Perry > No they are the same algorithm. >From the CAST-128 RFC 2144 2.5. Variable Keysize The CAST-128 encryption algorithm has been designed to allow a key size that can vary from 40 bits to 128 bits, in 8-bit increments (that is, the allowable key sizes are 40, 48, 56, 64, ..., 112, 120, and 128 bits). For variable keysize operation, the specification is as follows: .... [SNIP] .... In order to avoid confusion when variable keysize operation is used, the name CAST-128 is to be considered synonymous with the name CAST5; this allows a keysize to be appended without ambiguity. Thus, for example, CAST-128 with a 40-bit key is to be referred to as CAST5-40; where a 128-bit key is explicitly intended, the name CAST5-128 should be used. ---- Greg Carter Entrust Technologies carterg@entrust.com > From owner-ipsec Tue Jun 24 08:22:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA28773 for ipsec-outgoing; Tue, 24 Jun 1997 08:21:54 -0400 (EDT) Message-ID: From: Roy Pereira To: "'Matt Thomas'" , "'perry@piermont.com'" Cc: "'ipsec@tis.com'" Subject: RE: A little social engineering Date: Mon, 23 Jun 1997 17:52:10 -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 >> >- there's no ESP docs for IDEA, present or on the radar. I believe that Rob Adams had agreed to produce ESP IDEA. IDEA, unfortunately, suffers from it not being free. In fact its license is quite expensive. >> At least in my brief search, I didn't find a CAST-128 implementation Entrust and TimeStep successfully interoperated with ISAKMP running CAST5-128 at the Detroit interoperability tests. > From owner-ipsec Tue Jun 24 08:22:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA28772 for ipsec-outgoing; Tue, 24 Jun 1997 08:21:54 -0400 (EDT) Message-ID: From: Roy Pereira To: "'Rodney Thayer'" , "'Matt Thomas'" Cc: "'ipsec@tis.com'" Subject: RE: A little social engineering Date: Mon, 23 Jun 1997 17:55:04 -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 > >And RC5 (Why does isakmp-oakley-03 use RC5-R12-B64 instead of >RC5-R16-B128.)? Actually it has been modified to RC5-R16-B64. The 64 bit block size was chosen since all of the public source code available was using 64 bits. RC5 also states that the block size should be twice the size of the CPU word ( 2 * 32 = 64 bits ) The ESP RC5 draft uses a very similar approach. > From owner-ipsec Wed Jun 25 09:28:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA08260 for ipsec-outgoing; Wed, 25 Jun 1997 09:22:02 -0400 (EDT) Organization: ESAT, K.U.Leuven, Belgium Date: Wed, 25 Jun 1997 15:23:59 +0200 (METDST) From: Bart Preneel To: Bill Sommerfeld cc: Bart Preneel , Phil Karn , perry@piermont.com, uri@watson.ibm.com, trei@process.com, ipsec@tis.com, Antoon Bosselaers Subject: Re: What price security? In-Reply-To: <199706201608.AA230252914@hpcsos.col.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > To make this more relevant to ipsec, how, umm, "agile" is this 3DES? > > I think there are three relevant measurements: > > - How much memory is required by the key schedules 2K data and about 4K code. > - How long does it take to set them up About 5.2 uS on a 133MHz Pentium per key, providing code and local data reside in cache. So less than 11 uS for 2-key 3DES. > - How well does it perform on short blocks (64 bytes to ~4k bytes), > if you have to change to a new key schedule after every block > (assume you're rotating among 10 to 100 different keys). 2-key 3DES including key set-up runs at 3.7 Mbit/s on a 133MHz Pentium. Bart Preneel ------------------------------------------------------------------------------- Katholieke Universiteit Leuven tel. +32 16 32 11 48 Dept. Electrical Engineering-ESAT / COSIC fax. +32 16 32 19 86 K. Mercierlaan 94, B-3001 Heverlee, BELGIUM bart.preneel@esat.kuleuven.ac.be http://www.esat.kuleuven.ac.be/~preneel ------------------------------------------------------------------------------- On Fri, 20 Jun 1997, Bill Sommerfeld wrote: > > FYI: > > The 3DES code of my colleague Antoon Bosselaers runs > > at 9.2 Mbit/s on a 133MHz Pentium. > > Bart, > > To make this more relevant to ipsec, how, umm, "agile" is this 3DES? > > I think there are three relevant measurements: > > - How much memory is required by the key schedules > - How long does it take to set them up > - How well does it perform on short blocks (64 bytes to ~4k bytes), > if you have to change to a new key schedule after every block > (assume you're rotating among 10 to 100 different keys). > > Clearly one can (and perhaps should) cache precomputed key schedules > into your SA data structure(s), but whether to do it and how long to > retain it is clearly a memory vs time engineering tradeoff.. > > - Bill > From owner-ipsec Wed Jun 25 09:30:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA08336 for ipsec-outgoing; Wed, 25 Jun 1997 09:30:02 -0400 (EDT) From: andrade@netcom.com (Andrade Software Andrade Networking) Message-Id: <199706251337.GAA00868@netcom13.netcom.com> Subject: Re: What price security? To: ho@earth.hpc.org (Hilarie Orman) Date: Wed, 25 Jun 1997 06:37:21 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <199706221642.MAA13387@earth.hpc.org> from "Hilarie Orman" at Jun 22, 97 12:42:57 pm Sender: owner-ipsec@ex.tis.com Precedence: bulk Andrade Software & Networking Andrad@Netcom.Com X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 231 > > Is no one thinking of 100Mbs or 1Gbs ethernet or OC-3 ??? > > Hilarie > Yes, some people are thinking ahead. - Alex -- Alex Alten P.O. Box 11406 Pleasanton, CA 94588 USA Andrade@Netcom.Com (510) 417-0159 Fax/Voice From owner-ipsec Wed Jun 25 15:11:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA10919 for ipsec-outgoing; Wed, 25 Jun 1997 15:09:27 -0400 (EDT) Date: Wed, 25 Jun 1997 12:16:12 -0700 (PDT) Message-Id: <199706251916.MAA08833@servo.qualcomm.com> From: Phil Karn To: ho@earth.hpc.org CC: ipsec@tis.com In-reply-to: <199706221658.MAA13763@earth.hpc.org> (ho@earth.hpc.org) Subject: Re: What price security? Sender: owner-ipsec@ex.tis.com Precedence: bulk >Don't know about your tests, but when I looked at this, almost all >crypto timing tests were influenced heavily by cache effects, meaning >that actual mileage is usually much lower than the tests indicate, Well....yes. But I'd expect the effect on cache hit ratios from task switching to be fairly minimal except under very unusual circumstances. The inner core of a cipher is usually pretty small, and it probably doesn't take very long after a task switch (or after execution begins, for that matter) for all the important bits to get loaded into the cache. So unless the task switch rate is extraordinarily high, I wouldn't expect the effect to be very significant. IDEA is probably better than DES in this regard, as it lacks DES's lookup tables. Furthermore, level 2 caches are getting pretty big these days, to where I'd expect much of the cipher code and data to still be there after a brief digression to another process. (If the cipher task is suspended more than briefly, then it doesn't matter as much Also, my benchmarks were taken on a system that, while otherwise idle, still had a clock ticking away at a fairly rapid clip. Phil From owner-ipsec Wed Jun 25 16:55:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA11700 for ipsec-outgoing; Wed, 25 Jun 1997 16:51:54 -0400 (EDT) Message-ID: From: Greg Carter To: "'ipsec@tis.com'" Subject: CAST-128 - A few Comments from the Author... Date: Wed, 25 Jun 1997 16:49:01 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Below are Carlisle Adams (principle author of CAST-128) comments on the recent discussions of a need for a recommended cipher stronger than DES. Pointers to additional analysis of CAST are given. If anybody has additional requests for information on CAST-128 feel free to send them to greg.carter@entrust.com or carlisle.adams@entrust.com. Thanks Bye. ---- Greg Carter Entrust Technologies greg.carter@entrust.com >---------- >From: Carlisle Adams >Sent: Wednesday, June 25, 1997 4:21 PM >To: Greg Carter >Subject: A few comments on CAST-128... > >Hello, > >Given the discussion that has been occurring with respect to a recommended >cipher for IPSec, I'd like to make a few comments regarding CAST-128. > > >1) Bart Preneel said: > > "No cipher has been analyzed as much as DES (>> 25 person-years). > >[Quite an understatement here, since DES easily had ">>25 person-years" of >analysis by 1977!] > > "IDEA is a very > distant second (a few person-years). IMHO, all the others are at about the > same level (at most 1 person-year)." > >"At most 1 person-year" is certainly wrong for CAST-128. The CAST design >procedure itself was initially developed between 1988 and 1990 (like IDEA, it >constituted the primary focus of a Ph.D. dissertation), and has undergone >significant examination since then. (See, for a sampling of CAST-related >papers, the site http://adonis.ee.queensu.ca:8000/cast/cast.html). The >particular instantiation called CAST-128 has existed for about a year (the >s-boxes were completed last summer, but all other details of this particular >cipher were finalized a couple of years ago) and it has received a lot of >scrutiny by cryptanalysts within industry, academia, and certain government >agencies in that time. > > >2) Bart also included some speed information: > > Processor: 90 MHz Pentium > Speed: Mbit/s > Author: Antoon Bosselaers > > CAST 24.4 > >Note that for environments in which a shorter key (80 bits or less) is >sufficient, CAST-128 uses 12 rounds rather than 16, so the speed above would >be increased to roughly 32.5 Mbit/s. > > >3) Perry Metzger said: > > > At least in my brief search, I didn't find a CAST-128 implementation > > There are a couple out there already, actually, but they are only now > starting to pop their heads over the horizon. > >One example that I've seen recently is: www.interchg.ubc.ca/janke/fastcast/ > > >4) Perry also said: > > I'd say we mandate DES as we do now, and > recommend 3DES, which has a very solid amount of research behind it. > >Note that if 128-bit strength is desired, this cannot be achieved with 2-key >triple-DES (only 112 bits anyway, and even "easier" with time-memory tradeoff >attacks). Note also that even 3-key triple-DES has a so-called >"certificational weakness" (a theoretical attack requiring 2**56 time, 2**56 >memory, and 2**56 (chosen) plaintext-ciphertext pairs); see Menezes/van >Oorschot/Vanstone p.236, for example. > >Finally, the speed of triple-DES may not be totally unacceptable *if* you >have a very, very, highly optimized implementation. However, most people do >not have DES code that has been tuned to such an extreme so, for most people, >speed really is an issue. > >I'm therefore not convinced that triple-DES is the right recommendation. A >single 128-bit cipher with reasonable speed seems preferable to slow >triple-encryption with 168-bit keys and a certificational weakness. Granted, >years more intense analysis on any cipher would make everyone feel more >confident, but (obviously) this takes years. Perhaps for a cipher that is >RECOMMENDED (as opposed to MANDATED), this extra level of confidence is not >quite so critical, especially since you can never have 100% confidence >anyway... > >Alternatively, hedge your bets: mandate DES and recommend two others. > > > >JOPO (Just One Person's Opinion), > > >-------------------------------------------- >Carlisle Adams >Entrust Technologies >cadams@entrust.com >-------------------------------------------- > > > From owner-ipsec Thu Jun 26 17:25:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA20526 for ipsec-outgoing; Thu, 26 Jun 1997 17:18:00 -0400 (EDT) Message-Id: <3.0.1.32.19970626172514.00a10100@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 26 Jun 1997 17:25:14 -0400 To: "'ipsec@tis.com'" From: Robert Moskowitz Subject: IPsec documents Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Ted is on vacation this week, so I have been working at double capacity to jumpstart this workgroup. As a result, some pieces of information of what is occuring has been filtering out. I had no intension of working off line, but a series of events made the process equivalent to this. Water over the dam. Here goes. The following classes of documents have been on the horizon of this group: Architecture Transforms Transform implementations KMP DOI KMP The two transform classes came about to limit information repetition for each cipher or authenticator. Steve Kent has been working on the first (main) transform class. However, there was limited work on the implementations. There was a standing recognition that Hughes and Glenn drafts needed to be re-worked, but were not. This was discussed in the first Memphis session. To this end, my first task was to round up the various volunteers to write these implementations in a consistent manner. Interestingly, this process has become a sort of a 'proof' of the completeness of the main transform documents and the DOI and Oakley resolution. So these authors were contacted as well. By the middle of next week, Ted's and my goal is to have a set of documents ready for review by the whole workgroup. First off, in the process of writing a large set of cipher documents, a framework document evolved. A number of authors felt that this would be useful for everyone, so an IPsec Document Framework document will be the first new item for the workgroup. Next the following ciphers are being written: DES-CBC with implicit IV DES-CBC with explicit IV 3DES-CBC (most likely with implicit IV, stay tuned on this IV item) CAST 128 RC5 Blowfish Idea Might see a DESX let also. The following authenticators are being written in a manner that can be used for either AH or ESP (ie, ESP with authentication): HMAC MD5 96 HMAC SHA1 96 Writing these have already resulted in changes for DOI, and most likely for Oakley Resolution. Lessons learned. They are also raising some questions for ESP and AH (To Be Address). So take this as a heads up to lub your printers and break out your magnifying glasses. Constructive review is important. We are working hard to get them done in time for one round of changes before ID cutoff. Thank you all. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Fri Jun 27 09:59:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA25685 for ipsec-outgoing; Fri, 27 Jun 1997 09:56:29 -0400 (EDT) Message-Id: <3.0.1.32.19970627100217.006c5ee8@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Fri, 27 Jun 1997 10:02:17 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: RC4 esp draft from a while back... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Caronni (I hope I spelled that correctly) wrote an RC4 draft a while back, more than 6 months. If anyone has an email address for him or a copy of the draft I'd like to get it. Thanks. -- Rodney Thayer Sable Technology Corporation 246 Walnut Street Newton MA 02160 U.S.A. +1 617 332 7292 +1 617 332 7970(Fax)