From ipsec-request@ans.net Thu Sep 7 10:17:00 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12710 (5.65c/IDA-1.4.4 for ); Thu, 7 Sep 1995 08:00:12 -0400 Received: by interlock.ans.net id AA38649 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 7 Sep 1995 07:54:41 -0400 Message-Id: <199509071154.AA38649@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 7 Sep 1995 07:54:41 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 7 Sep 1995 07:54:41 -0400 Date: Thu, 7 Sep 95 10:17:00 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: minor Photuris changes I spent the past day visiting NRL in DC with Atkinson and Schertler. We were unable to come to closure on merging or making Photuris compatible with ISAKMP. There were minor changes we could agree upon. 1) Certificate TLVs need an authority field. Some of the certificate types do not indicate their root inherently, and we need to be able to choose among roots (for DNS-SIG and X.509). Some places (large multi-national corporations) will not use or trust the basic DNS tree. I was not aware of this, and need guidance as to the format. Bellovin? 2) Expand the LifeTime field to 24 bits. Allows a key to live more than a day. Seemingly far too long (in my view), but something that they wouldn't reveal needs longer-lived keys. (I hate the secrecy.) If you don't think this is much of a compromise, you should know that the alternative was adding a length field to every timestamp to allow completely variable time bases (as ISAKMP does). KISS. 3) Expand the Moduli Index cum Group Index to 16 bits. Rename as Exchange Method (from ISAKMP) or something similar (Scheme?). As you may recall, this was originally just a simple index for moduli for modular exponentiation. Then, broadened to indicate the "group" to allow use by other public-key techniques, such as elliptical curves. They claim that there will be thousands of proprietary (government) key management schemes, which they want to indicate during cookie exchange. So, we can reserve the first 256 for "well-known" values, and leave the rest for "proprietary". Again, I resisted making this a TLV, or having fixed subfields. Flat numbering should work, as we only will require support for _one_ value in this field. The others can certainly allocate as many from their proprietary values as they like, since they will have to distinguish themselves in some other way. Also, they want to be able to indicate non-public key techniques. This seems to violate the very principles of Photuris, which is designed around public-key exchange. My first inclination was to agree with Karn on this one. For other keying variants, use another UDP port and another set of messages. Trying to shoe-horn extra messages or more variable values will make the actual key management process nearly impossible to formally prove or verify. We are already pushing the edge with variable moduli, variable key generation method, variable signature methods, and completely variable final security association attributes. There's 4!/2 (12) combinations to verify already, assuming we use only D-H, MD5, DES and PGP RSA as our verification base. It balloons rapidly. However, Atkinson claims that it would be useful for the same overall message exchange of security association parameters (what he calls the SAMP) together with a KDC such as Kerberos. The public value fields could be replaced with Kerberos tickets or something. So, I agreed to expand this field to allow the attempt, as long as we don't waste short term working group time and confusion exploring the issue. If Ran doesn't actually come out with a Kerberos scheme in two years, he owes me dinner.... Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Thu Sep 7 16:21:19 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12278 (5.65c/IDA-1.4.4 for ); Thu, 7 Sep 1995 12:30:38 -0400 Received: by interlock.ans.net id AA60862 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 7 Sep 1995 12:22:42 -0400 Message-Id: <199509071622.AA60862@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 7 Sep 1995 12:22:42 -0400 From: Ran Atkinson Date: Thu, 7 Sep 1995 12:21:19 -0400 Reply-To: rja@cs.nrl.navy.mil X-Mailer: Z-Mail (3.2.1 10apr95) To: ipsec@ans.net Subject: possible AH & IPv4 compromise Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: rja@bodhi.cs.nrl.navy.mil Folks, Bill Simpson was in town in late August and unexpectedly telephoned me and then dropped by NRL 30 minutes later for a chat about IPv4 options and AH. This discussion largely consisted of Bill "educating" me about things. It turns out that the way one might read LSRR's specification is not the way it has been implemented in most systems that implement it. It has been implemented so that the addresses recorded are NOT the arriving interfaces of the listed intermediate systems but instead the next-hop after leaving each listed intermediate system. This last isn't predictable in the general case. I can see both interpretations in the text of RFC-791, but what matters is what has been implemented. Similarly, SSRR originally lists the inbound address of each intermediate hop but records the outbound address of each intermediate hop (at least in real world implementations). Again, this makes SSRR unpredictable in the general case. RFC-791 does appear to say this upon re-reading, but it is too subtly worded for my taste. This leaves only IPSO/BSO, IPSO/ESO, SATID, NOP and EOL as the only really invariant options. Of these, EOL and NOP don't impact security. The software that Bill has mentioned that did reorder IPv4 options is now ancient and has long been superceded by software releases that do not reorder IPv4 options. None of the major router vendors (by market share) ever used the particular implementation that Bill cited. I believe that implementations that reorder IP options are broken (ignoring security, it is a PAINFUL performance hit) and should be ignored in our mulling things over. Bill, Craig, and I think we have a compromise position on IPv4 AH processing. At least one router vendor that Bill talks with has also agreed that this is reasonable. I am altering the freely distributable NRL implementation to reflect this compromise. The compromise goes like this: Included in AH computation: IP Version IP Header Length Total Length Ident Protocol Source Address Destination Address IPSO/BSO IPSO/ESO CIPSO (Option # available from Assigned Numbers, Option Length should be in the usual place) SATNET ID Zeroed for AH computation: TOS (enough real world routers munge this one that it ought to be excluded even though router munging of this sort really is evil) Frag Offset Flags Field TTL IP-layer Checksum All existing documented IP options other than IPSO/*, CIPSO, and SATNET ID Ran rja@cs.nrl.navy.mil On behalf of Bill, Craig, and Ran... From ipsec-request@ans.net Fri Sep 8 14:13:54 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA16904 (5.65c/IDA-1.4.4 for ); Fri, 8 Sep 1995 11:31:19 -0400 Received: by interlock.ans.net id AA61420 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 8 Sep 1995 11:13:44 -0400 Message-Id: <199509081513.AA61420@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 8 Sep 1995 11:13:44 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 8 Sep 1995 11:13:44 -0400 Date: Fri, 8 Sep 95 14:13:54 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: minor Photuris changes > From: Hilarie Orman > We've been looking at this some, and we feel that Photuris must have > the class identifiers that ISAKMP uses. Did your discussions get around > to this? > We discussed the convoluted/layered class/sets et alia at some length, and we concluded this is more of a implementation command processing issue than a protocol issue. It is much more rational for the implementor to decide which are the few useful combinations of attributes, than to have each user try to configure the correct classes and sets of attributes in each environment. Reduces the number of points of interoperability failure. Phil, Ran and I all deemed that there were too many variable layerings, although Phil is even more conservative than I am on this topic. Experience has shown that this is very difficult for many implementors to handle correctly. As the IP length versus UDP length, PPP packet length versus sum of option lengths, etc, showed us in the past. Therefore, Photuris indicates in the Appendix which attributes are useful for which operations (an addition I made between drafts 00 and 01 at the request of a WG member). Perhaps more text could be provided for implementation notes? I will try to add more detail in the next draft. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Fri Sep 8 14:41:24 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA10759 (5.65c/IDA-1.4.4 for ); Fri, 8 Sep 1995 11:31:19 -0400 Received: by interlock.ans.net id AA49640 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 8 Sep 1995 11:13:43 -0400 Message-Id: <199509081513.AA49640@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 8 Sep 1995 11:13:43 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 8 Sep 1995 11:13:43 -0400 Date: Fri, 8 Sep 95 14:41:24 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Blocks of SPIs One of Ran's suggestions that came up in discussion was allocating entire blocks of SPIs (and therefore keys) with the same attributes. It might permit much faster session-key changes under high bandwidth*delay. This is very easy in Photuris, since a change in SPI makes a change in session key. A list of SPIs will have widely variant keys (assuming the mixing function of MD5, SHA, etc, works well). Note that reducing the number of Photuris exchanges reduces the amount of analysis material available, too. After thinking, it seems easiest to make this an attribute: type, length, #SPIs, time By default (no attribute), only one SPI would be generated. Each exchange would allocate some number of SPIs starting with the current one (say, 1000 is the SPI, then <#SPIs> = 100 would allocate 1000-1099), and the next SPI would be used every