From ipsec-request@ans.net Fri Aug 4 18:51:00 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14772 (5.65c/IDA-1.4.4 for ); Fri, 4 Aug 1995 17:00:22 -0400 Received: by interlock.ans.net id AA62455 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 4 Aug 1995 16:52:44 -0400 Message-Id: <199508042052.AA62455@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Fri, 4 Aug 1995 16:52:44 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 4 Aug 1995 16:52:44 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 4 Aug 1995 16:52:44 -0400 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 4 Aug 1995 16:52:44 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 4 Aug 1995 16:52:44 -0400 Date: 4 Aug 95 13:51:00 -0500 To: ipsec@ans.net Subject: IPSEC Minutes 33rd IETF in Stockholm - July 1995 CURRENT MEETING REPORT Minutes of the IP Security Working Group (IPSEC) Reported by Antonio Fernandez (afa@bellcore.com) and Mark Schertler (mjs@tycho.nsa.gov) The IP Security (IPSEC) Working Group met on Wednesday July 19th from 9:00-12:00 during the 33rd IETF. Paul Lambert chaired the meeting, which was broadcast on the mbone. The meeting covered the status of the IP ESP and AH documents, a presentation and discussion about the Internet Key Management Protocol (IKMP) and a presentation of DNS Security Extensions (DNSSEC) to provide long term keys on the Internet. Martin Patterson announced a SKIP BOF. Several implementations of SKIP have been developed and alignment of SKIP with ESP and AH is being discussed. The main purpose of the BOF is to get the people implementing versions of SKIP together. IPSEC Document Status The following IPSEC Specifications have been advanced to Proposed Standard: 1. Security Architecture for the Internet Protocol 2. IP Authentication Header 3. IP Encapsulating Security Payload (ESP) 4. IP Authentication using Keyed MD5 5. The ESP DES-CBC Transform The IP Authentication using Keyed MD5 specification before it is forwarded to the RFC editor will be edited to reflect Hugo Krawczyk's comments concerning having the prepended key padded with a one (1) and some number of zeros (0) to a length of 512 bits. Jeff Schiller, Security Area Director, will provide the official response to the comments received during the last call period. Several implementations of ESP and AH are being developed and an implementor's mailing list has been started. Contact Perry Metzger (perry@imsi.com) if you are an implementor and would like to be on the mailing list. Internet Key Management Protocol (IKMP) Currently IPSEC is considering two Internet Key Management Protocol (IKMP) Proposals: 1. Photuris 2. Internet Security Association Key Management Protocol (ISAKMP) ); Tue, 8 Aug 1995 13:51:39 -0400 Received: by interlock.ans.net id AA14504 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 8 Aug 1995 13:37:42 -0400 Message-Id: <199508081737.AA14504@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 8 Aug 1995 13:37:42 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 8 Aug 1995 13:37:42 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 8 Aug 1995 13:37:42 -0400 X-Mailer: exmh version 1.6 4/21/95 To: ipsec@ans.net Subject: What can applications running over ipsec assume? Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 08 Aug 1995 13:37:31 -0400 From: Bill Sommerfeld -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii I've been following the ipsec work for just about a year now, from (among other things) the point of view of being a potential user of these protocols. As best I can tell, the current IPSEC architecture documents make no mention of what services are visible from the point of view of *applications* running on top of transport-layer protocols running over ipsec. Clearly, certain guarantees need to be made in order for IPSEC to provide useful security services to applications. A number of them seem fairly obvious to me.. but if everyone doesn't agree on what these guarantees are, either interoperability or security or both will suffer. As a specific example, all of the TCP implementations I'm familiar with do not expose TCP packet boundaries to the application. Therefore, a system which implements ipsec should (or must) ensure that all packets sent in one direction on a TCP connection come from the same sender and are protected equivalently. All the encryption and integrity protection in the world won't help you if a spoofer can just forge an unauthenticated packet and hijack your TCP connection. [I'll note in passing here that requiring that all packets on a given TCP connection share the same SPI seems to be too strong a requirement, as it appears from some comments in the current Photuris draft (draft-ietf-ipsec-photuris-02) that SPI's are fairly ephemeral, and a given TCP connection may long outlive the SPI it was opened under.] More generally, what information contained in a security association must be made visible to applications? And what must not? - Bill -----BEGIN PGP SIGNATURE----- Version: 2.6.1 iQCVAwUBMCeg2Fpj/0M1dMJ/AQELpgP8DnMhaovL/ivBmP+Nh7cuZOmJn+BItvMX qcQefhITZrOFSbJAcM7D+KE8ri2cMBGndyJdNN9hx/osPVkpMjWcT//HDThMzT0H FsX1D/Ei2Odk7JIWTOsZIJmzjhsi2j1eXyRbpDzh6Sq2SdjC6Koeon4zJEAFhpB2 pgscbnCEDJI= =XCu/ -----END PGP SIGNATURE----- From ipsec-request@ans.net Tue Aug 8 10:32:43 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15727 (5.65c/IDA-1.4.4 for ); Tue, 8 Aug 1995 14:45:32 -0400 Received: by interlock.ans.net id AA61890 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 8 Aug 1995 14:36:55 -0400 Message-Id: <199508081836.AA61890@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 8 Aug 1995 14:36:55 -0400 From: smb@research.att.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 8 Aug 1995 14:36:55 -0400 To: Bill Sommerfeld Cc: ipsec@ans.net Subject: Re: What can applications running over ipsec assume? Date: Tue, 08 Aug 95 14:32:43 EDT -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii I've been following the ipsec work for just about a year now, from (among other things) the point of view of being a potential user of these protocols. As best I can tell, the current IPSEC architecture documents make no mention of what services are visible from the point of view of *applications* running on top of transport-layer protocols running over ipsec. Clearly, certain guarantees need to be made in order for IPSEC to provide useful security services to applications. A number of them seem fairly obvious to me.. but if everyone doesn't agree on what these guarantees are, either interoperability or security or both will suffer. My own view is that the ipsec layer should pass the security characteristics of a received packet up to the transport layer. It, in turn, must match those characteristics against what the user has requested. Packets that don't meet those requirements are dropped. From ipsec-request@ans.net Tue Aug 8 21:37:58 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14349 (5.65c/IDA-1.4.4 for ); Tue, 8 Aug 1995 17:48:27 -0400 Received: by interlock.ans.net id AA32216 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 8 Aug 1995 17:38:07 -0400 Message-Id: <199508082138.AA32216@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 8 Aug 1995 17:38:07 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 8 Aug 1995 17:38:07 -0400 To: ipsec@ans.net Subject: Re: What can applications running over ipsec assume? In-Reply-To: Your message of "Tue, 08 Aug 1995 14:32:43 EDT." <199508081836.AA61890@interlock.ans.net> Date: Wed, 09 Aug 1995 07:37:58 +1000 From: Bob Smart > My own view is that the ipsec layer should pass the security characteristics > of a received packet up to the transport layer. It, in turn, must > match those characteristics against what the user has requested. Packets > that don't meet those requirements are dropped. > This seems sensible. It implies modifications to APIs at 2 layer boundaries. I guess if there was work proceeding to define these API changes you would have mentioned it... Bob Smart From ipsec-request@ans.net Tue Aug 8 22:40:23 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12943 (5.65c/IDA-1.4.4 for ); Tue, 8 Aug 1995 18:56:21 -0400 Received: by interlock.ans.net id AA53214 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 8 Aug 1995 18:40:32 -0400 Message-Id: <199508082240.AA53214@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 8 Aug 1995 18:40:32 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 8 Aug 1995 18:40:32 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 8 Aug 1995 18:40:32 -0400 X-Mailer: exmh version 1.6 4/21/95 To: Bob Smart Cc: ipsec@ans.net Subject: Re: What can applications running over ipsec assume? In-Reply-To: smart's message of Wed, 09 Aug 1995 07:37:58 +1000. <199508082138.AA32216@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 08 Aug 1995 18:40:23 -0400 From: Bill Sommerfeld -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii > My own view is that the ipsec layer should pass the security characterist ics > of a received packet up to the transport layer. It, in turn, must > match those characteristics against what the user has requested. Packets > that don't meet those requirements are dropped. > This seems sensible. I think a generalized form of this would be: Each layer above ipsec needs to: 1) provide some form of access control limiting which incoming packets are accepted and passed upwards, based on the identity of the sender and the quality of protection 2) where appropriate, pass up information about the identity of the sender and the quality of protection of data passed upwards. (That's worded awkwardly.. anyone got a better phrasing?) Some applications would want to rely on (1); others would want to rely on (2). For instance, an SMTP server would most likely not deny service to an unauthenticated sender, but might want to log the identity of the sender if it was known. You could of course, use both (1) and (2) in conjunction (i.e., insist on confidentiality and/or data origin authentication, but let the application make the final access control decisions). It implies modifications to APIs at 2 layer boundaries. I guess if there was work proceeding to define these API changes you would have mentioned it... I haven't seen any public discussion of API's for this yet and I suspect that such discussion would be premature until more of this is nailed down.. - Bill -----BEGIN PGP SIGNATURE----- Version: 2.6.1 iQCVAwUBMCfn0lpj/0M1dMJ/AQHSlwP+Jd45lCKOr4OQ9qF+p2MnrCcPsWsjNs1H 7tDmovWtfLae1/gm0baHoCy3UR8JxTwZNIM8SriM/FtnNyXvoo3SAVOQbQ5VNXVP h30OUSxBabMu7+R1+b+NP01LK2cRV6bMs7KmkMjRFYvzs2a33URxDfudTX3l5A0v U0KsE1kEaBs= =NvQl -----END PGP SIGNATURE----- From ipsec-request@ans.net Tue Aug 8 16:54:42 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA11760 (5.65c/IDA-1.4.4 for ); Tue, 8 Aug 1995 21:05:15 -0400 Received: by interlock.ans.net id AA23418 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 8 Aug 1995 20:56:33 -0400 Message-Id: <199508090056.AA23418@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 8 Aug 1995 20:56:33 -0400 From: smb@research.att.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 8 Aug 1995 20:56:33 -0400 To: Bob Smart Cc: ipsec@ans.net Subject: Re: What can applications running over ipsec assume? Date: Tue, 08 Aug 95 20:54:42 EDT > My own view is that the ipsec layer should pass the security charac teristics > of a received packet up to the transport layer. It, in turn, must > match those characteristics against what the user has requested. P ackets > that don't meet those requirements are dropped. > This seems sensible. It implies modifications to APIs at 2 layer boundaries. I guess if there was work proceeding to define these API changes you would have mentioned it... Well... The interfaces from IP to the transport layer and from the transport layer to the user I/O layer aren't open. That there's any coherency at all is because of the common ancestry of most UNIX networking code -- and at that, there are now two very different interfaces, mbufs+sockets and streams. The interesting API is the user-to-kernel interface. The only work I've seen is draft-mcdonald-ipv6-sec-api-00.txt, which I didn't like for various reasons. (My apologies for being vague here; I had some specific objections, but I don't remember them clearly any more, and I'd rather not blather.) I suspect we won't really know what the API should be like until we've built a few. From ipsec-request@ans.net Wed Aug 9 11:39:35 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12118 (5.65c/IDA-1.4.4 for ); Wed, 9 Aug 1995 07:49:28 -0400 Received: by interlock.ans.net id AA16169 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 9 Aug 1995 07:43:52 -0400 Message-Id: <199508091143.AA16169@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 9 Aug 1995 07:43:52 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 9 Aug 1995 07:43:52 -0400 Organization: To: ipsec@ans.net Subject: Photuris Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <16641.807968375.1@forthnet.gr> Date: Wed, 09 Aug 1995 14:39:35 +0300 From: "Aggelos D. Keromitis" The Photuris draft says that the local address should be used for cookie generation and distinguishing simultaneous key generation sessions with the same host. However, there is no (portable?) way to find over what local interface a UDP packet arrived. I think the draft should be modified to exclude the use of the local address (and possibly local port as well). Of course, one could have the daemon bind to each and every address of the host, but it doesn't sound like a good solution, especially when there's not much gain from using the local address/port (the secret value is enough). -Aggelos From ipsec-request@ans.net Wed Aug 9 12:27:48 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA11737 (5.65c/IDA-1.4.4 for ); Wed, 9 Aug 1995 08:36:24 -0400 Received: by interlock.ans.net id AA61999 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 9 Aug 1995 08:30:10 -0400 Message-Id: <199508091230.AA61999@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 9 Aug 1995 08:30:10 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 9 Aug 1995 08:30:10 -0400 Organization: To: ipsec@ans.net Subject: Followup question Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <29502.807971267.1@forthnet.gr> Date: Wed, 09 Aug 1995 15:27:48 +0300 From: "Aggelos D. Keromitis" Something i forgot to ask in my previous mail: Photuris draft, Page 8, paragraph 2.1: "The UDP checksum is required. Any messages with an incorrect or zero UDP checksum is silently discarded." How can this be enforced from a user level process ? -Aggelos From ipsec-request@ans.net Thu Aug 10 20:49:27 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15358 (5.65c/IDA-1.4.4 for ); Thu, 10 Aug 1995 16:56:24 -0400 Received: by interlock.ans.net id AA35942 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 10 Aug 1995 16:49:41 -0400 Message-Id: <199508102049.AA35942@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 10 Aug 1995 16:49:41 -0400 To: smb@research.att.com Cc: ipsec@ans.net Subject: Re: What can applications running over ipsec assume? In-Reply-To: Your message of Tue, 08 Aug 95 14:32:43 -0400. <199508081836.AA61890@interlock.ans.net> Date: Thu, 10 Aug 95 16:49:27 -0400 From: Steve Kent Steve, It might be most appropriate for applications to express security QoS parameters during connection establishment, but initially applications will not be prepared to do this. Moreover, one of the motivations for IP layer security is the flexibility to implementing it remotely from an end system, where an application has no direct means of passing on its security QoS parameters. So, I think it is very important to provide very good management tools that allow a system administrator to express security QoS for classes of associations, so that appropriate services can be selected automatically, without explicit invocation by (or notification to) applications. Steve From ipsec-request@ans.net Thu Aug 10 12:54:58 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15114 (5.65c/IDA-1.4.4 for ); Thu, 10 Aug 1995 16:58:46 -0400 Received: by interlock.ans.net id AA35842 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 10 Aug 1995 16:56:18 -0400 Message-Id: <199508102056.AA35842@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 10 Aug 1995 16:56:18 -0400 From: smb@research.att.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 10 Aug 1995 16:56:18 -0400 To: Steve Kent Cc: ipsec@ans.net Subject: Re: What can applications running over ipsec assume? Date: Thu, 10 Aug 95 16:54:58 EDT Steve, It might be most appropriate for applications to express security QoS parameters during connection establishment, but initially applications will not be prepared to do this. Moreover, one of the motivations for IP layer security is the flexibility to implementing it remotely from an end system, where an application has no direct means of passing on its security QoS parameters. So, I think it is very important to provide very good management tools that allow a system administrator to express security QoS for classes of associations, so that appropriate services can be selected automatically, without explicit invocation by (or notification to) applications. Agreed, absolutely. My point was more that an application *can* behave differently if it knows the security level of a connection. Thus, rlogin -- which uses address-based authentication, and hence is not secure -- may be acceptable if the address is cryptographically validated, and the administrator has reason to trust the originating machine. Your point about remote implementations is also a good one. Some time ago, I suggested that we needed some mechanism -- a header, or IP options -- by which an IPSEC-aware host could request, or be informed of, the security functions implemented by a remote encryptor (possibly a bump-in-the-cord unit). There's an obvious analogy to the IP security label, which specifies this information implicitly. Naturally, the administrator would have to configure a machine to believe such labels, and this should only be done in the proper physical environment. From ipsec-request@ans.net Fri Aug 11 21:57:49 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12982 (5.65c/IDA-1.4.4 for ); Fri, 11 Aug 1995 17:11:24 -0400 Received: by interlock.ans.net id AA34329 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 11 Aug 1995 17:01:35 -0400 Message-Id: <199508112101.AA34329@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 11 Aug 1995 17:01:35 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 11 Aug 1995 17:01:35 -0400 To: ipsec@ans.net Cc: ipng@sunroof.eng.sun.com Subject: My thoughts on three timely IPsec issues... Date: Fri, 11 Aug 1995 16:57:49 -0500 From: Craig Metz As I had mentioned on the IPsec developers' list, I had some specific thoughts on some IP security issues that are currently being discussed, but I wanted to wait until I had built some code before making them known because I wanted to be sure that my ideas were implementable. I have, it mostly works, there are no outstanding questions as to whether something is doable or not, so I have prepared my thoughts into three messages to form a long tirade. I am carbon- copying this and these to the IPng list, because at some point, in order to be IPng spec-compliant, all IPng implementations will have to do security processing, so these issues need to be thought about by IPng people. The first message I will send (part one) is some general background discussion. The second message I will send (part two) is on IPv4 options that we can't handle. IPng people may want to skip this one, but I believe that some of the discussion is relevant. The third message I will send (part three) is a detailed listing of my conclusions as to the variance/invariance/predictability of every defined field in every IP (IPv4 and IPv6) network-level header I could find a spec for. These messages are intended to prompt discussion. Please direct this discussion to the mailing list, NOT the mailing list. Unfortunately, I will not have very good network access for the next month, so I will not be able to participate in this discussion as much as I would like to. -Craig From ipsec-request@ans.net Fri Aug 11 21:58:32 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14521 (5.65c/IDA-1.4.4 for ); Fri, 11 Aug 1995 17:11:25 -0400 Received: by interlock.ans.net id AA22047 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 11 Aug 1995 17:01:39 -0400 Message-Id: <199508112101.AA22047@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 11 Aug 1995 17:01:39 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 11 Aug 1995 17:01:39 -0400 To: ipsec@ans.net Cc: ipng@sunroof.eng.sun.com Subject: Part One: Background Date: Fri, 11 Aug 1995 16:58:32 -0500 From: Craig Metz Throughout these notes, I am assuming that we are not dealing with fragments. Fragment processing creates wrinkles that have been discussed previously, and I think that omitting the special case of fragmentation will help to keep things on-track. In a nutshell, fragments cannot be subject to intermediate network authentication unless they are passively re-assembled (which I believe is not a good thing) because authentication processing happens before fragmentation and after reassembly (think of AH as an ULP instead of a network option for fragmentation/reassembly purposes). First, I have some background architectural points to make. I view the IP Authentication Header as being able to provide two different types of security assurances. The first of these is what I will call "intermediate authenticity", which I define as having guarantees that a packet must have come from a finite set of senders because of authentic tunnels and network design. This is not the same as "intermediate network authentication," which I define as a specific mid-point in a network processing the Authentication Header in a packet to determine whether or not the packet-in-transit is currently authentic. The second of these is guaranteed authenticity end-to-end (i.e., at the sender and receiver). You might think of the former as implicit security and the latter as explicit security. First assertion: End-to-end authenticity assurances imply intermediate authenticity, but the reverse is not true. This all seems fairly obvious, but I think that some of the subtleties might turn into "gotchas" that people need to consider. Several of Steve Bellovin's attacks are cases where I believe these two assurance levels have been confused. My first example is a simple use of the "AH Tunnel", where virtual links between gateways are built by taking the packet in transit, encapsulating it using IP-IP tunneling, and doing normal AH processing on the resulting packet. This case supports both assurances of security for A and B. It supports end-to-end security between A and B if they use an explicit Authentication Header in their packets. It provides intermediate authenticity assurances for A and B because there is a finite set of possible senders. It also supports intermediate network authentication at C and D of packets between A and B. Consider this fictitious network: A------| |------ B |----- C ===== D -----| I------| |------ J (Legend for this note: '=' is a configured AH tunnel, '-' is a link, and '|' is a network) B has received a packet that claims to be from A to B that carries no Authentication Header. B has no guarantee that A really sent the packet -- any other machine in this diagram could have forged it. If C and D have the security policy that they only allow packets from the tunnel (and won't forward other packets onto the nets), then, without doing any AH processing itself, B has an intermediate authenticity guarantee: If the packet is forged, there is a finite set of possible forgers: I, C, D, J, and B. Random machines on the Internet, which is where we can envision the tunnel from C to D traversing, cannot forge a packet from A to B. If D receives a packet from the tunnel, from the end-to-end authenticity, it has a stronger guarantee: the packet presumably from A to B that it received from the tunnel must have been sent to D by C. This is because C and D are sending packets that carry the Authentication Header, which gets C and D end-to-end (tunnel-end to tunnel-end, really) assurances. If B wants to be guaranteed that the packet could only have come from A, it must require that there be an authentication header on the packet as sent by A. In this case, B will get both assurances and you will actually have two authentication headers (as well as two IP headers) between C and D. This is, however, the only way to provide end-to-end security in this configuration. My second example is more complex. Consider this fictitious network: A------| |------ B |----- C ===== D ===== E ===== F -----| I------| |------ J For extra fun, A is source-routing its packet to B through C, D, E, and F. The packet goes from A to C without an Authentication Header. C encapsulates the packet in a new IP packet and authenticates it with a C->D key. D verifies the auth header, decapsulates the packet, processes the source route to find the next destination E, encapsulates the packet in a new IP packet, and authenticates it with D->E key. E does the same thing as D, though shifted along the chain. F checks the auth header against the E->F key, decapsulates the packet, and sends it to B without an Authentication Header. When B gets a packet claiming to be from A, it knows that it can only have come from a finite set of senders because of the intermediate authenticity: A, C, D, E, F, I, J, and B. The packet could not have been forged between C and D, D and E, or E and F, thanks to the authenticated tunnels between those hosts. Again, A could explicitly add an Authentication Header to its packet to B to provide end-to-end protection, which would result in the tunnels carrying a total of two IP headers and two AH headers on the lines between them (one for the tunnel and one end-to-end). Now, let's say that B gets a packet claiming to be from E. The set of senders who could forge that packet is F, J, and B. A, J, C, and D cannot forge the packet assuming reasonable security policy because E will find that its source address is on a packet it received from D and is forwarding, which is not correct. This has the nifty property of helping to drop packets caught in a routing loop. F, however, can guarantee using end-to-end authentication that the packet it is receiving is from E because it verifies it in the E->F key. Let's say that A sends an end-to-end authenticated packet to B over this network. C and F can add and remove, respectively, any options it wants from this packet so long as the packet from F->B is the same (except for obviously variant fields that are exempt from AH processing) as the packet from A->C. In this case, while you have end-to-end authenticity, your packet will fail intermediate network authentication. This property has implications for people doing real intermediate network authentication are is beyond the scope of our current worries. Second assertion: Intermediate changes will not affect end-to-end authenticity so long as they are reversed. This is important for routers with a reputation of mucking with packets in transit. As long as a router puts things back the way they were before the packet gets to the receiver, end-to-end authenticity is preserved. If a router does not, the packet at the receiver MUST fail authentication, because it is not end-to-end authentic -- the sender didn't send the packet that way. More on this later. My third example is a recent attack scenario from Steve Bellovin: A-----| |------B C-----| Steve's attack goes something like this: C sends B an IP-in-IP tunneled packet (not from a configured tunnel) where the outside is authenticated using the C->B key and the inside header claims to be from A. B verifies the packet, marks it as authentic, decapsulates the inside packet, and processes it, thinking that it came from A. My belief here is that this is a case of B confusing the two assurances of authentication. B is getting intermediate authenticity -- B knows that the "tunneled" C->B packet is authentic, but B is not getting end-to-end authenticity -- B doesn't know that the inside packet (that claims to be from A->B) is authentic. This is a costly mistake. Third assertion: When processing a tunneled packet, outside header authenticity is an issue of intermediate security and inside header authenticity is an issue of end-to-end security. If you take my second example and make F and B one system, this might become clearer. Fourth assertion: If your system or network policy is FUBAR, so are your security guarantees. If your system or network policy does something obviously drain bamaged such as depending on intermediate security to provide end-to-end security, then your security assurances are going to be very weak. Some sites will want to use intermediate security for performance reasons or because they believe that only "outside" machines are a risk. These sites must be careful not to fall into the trap of believing that they have a higher level of authenticity assurance than they really have. From ipsec-request@ans.net Fri Aug 11 21:59:12 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12474 (5.65c/IDA-1.4.4 for ); Fri, 11 Aug 1995 17:11:25 -0400 Received: by interlock.ans.net id AA10788 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 11 Aug 1995 17:01:43 -0400 Message-Id: <199508112101.AA10788@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 11 Aug 1995 17:01:43 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 11 Aug 1995 17:01:43 -0400 To: ipsec@ans.net Cc: ipng@sunroof.eng.sun.com Subject: Part Two: IPv4 Options We Can't Handle Date: Fri, 11 Aug 1995 16:59:12 -0500 From: Craig Metz I have heard several statements on this issue that I disagree with, and now I have working (well, mostly ;) code that I can use to back up my disagreement. The first thing I've heard that I disagree with is that we should not include IPv4 options in the IPv4 authentication computation. There are two main reasons given: 1. If we get an option that we can't process, we must ignore it (RFC1122). If we can't process it, though, we don't know whether the fields are invariant, so we might be dropping the packet solely because we can't process the option, which conflicts with RFC1122. 2. Routers might insert, remove, or re-order options. I will discuss the latter one first. When routers mess with the options attached to the packet, you are guaranteeing that the packet does not have intermediate authenticity because the packet at some points along its path of travel is not the same as the packet as sent by the sender. Therefore, whenever routers modify the packet in any way other than the modification of specific variant fields, you do not have intermediate authenticity anymore at some or all points along your path. In the context of my second example, C may legitimately insert an IPSO option, but if E or F is the router stripping that option and restoring the packet, the packet will not have intermediate authenticity at D because the packet is not what A sent or what A intends B to receive. However, end-to-end authenticity guarantees are not mutually exclusive with routers that modify options *as long as they put things back the way they found them somewhere along the line*. In the context of my second example, C may legitimately insert an IPSO option so long as D, E, or F removes it and restores the packet to its original form. As long as it does, B will see the packet as A intended it to be seen, and it is therefore end-to-end authentic. If C inserts the IPSO option and no router removes it, the packet at B is not end-to-end authentic because the packet at B is not what A sent or intended B to see. It is important that the AH verification procedure fail in this case exactly because the packet has been modified in transit. AH has no concept of good or bad modifications, but it has a strict concept of authenticity. This packet is not authentic because it has been modified. One of our resident experts on routers that insert, examine, and remove IPSO options into IPv4 packets tells me that "no known router ships configured to perform IPSO modifications and that such modifications only happen if the router admin actively configures the router to do so. Further, IPSO modifications are directly security-relevant -- we do want packets with intermediate IPSO modifications to fail end-to-end authenticity checks". Now to discuss the first problem. A number of interpretations of RFC1122 have been posted in this discussion, but I would like to work from what RFC1122 says about options you can't process: "The IP and transport layer MUST each interpret those IP options that they understand and silently ignore the others." The problem here is one of how we can determine whether fields of an option are variant or not. I think that we all can agree that if we know how to handle an option, we can presumably get some sort of consensus on what is and isn't variant and implement that. So the question is really what "silently ignore" means. The reason I quote the text here is because most people have substituted the word "skip" for "silently ignore" and operated with the assumption that this is the only legitimate interpretation. I disagree. Consider transport headers and transport data. They're not network- level, we have no right at the AH level to mess with them. What do we do with them for AH computation? We run the cryptographic checksum straight over them with no variance substitutions. Therefore, I believe that a reasonable definition of "ignore" is also to simply run the cryptographic checksum straight over the options we can't handle with no variance substitutions. Another possibility, which I don't recommend, is to zero out the options we can't process except for their type and length fields (more on this later). There are three classes of unknown options for purposes of evaluating which definition of "silently ignore" is most reasonable. The first are unpredictably variant options. For example, the timestamp option. The second are invariant options. For example, the IPSO option. The third are predictably-variant options. For example, the SSRR option. Fifth assertion: If both sides cannot process an option and both sides do the same thing in cases of unknown options (either skip/omit, zero, or blind-hash), all three methods will work. Only in the last case, however, will the contents of the option be protected from modification in transit. In this case, the best option is a blind-hash. Now we have the case, which I consider more common and more interesting, where one side does not know how to process the option but the other does. If you "skip over" (omit from computation) options you can't handle, you lose for all three cases because the side that does know how to process the option will include data, some of which may be zeroed out, from the option at that position in its computation. If you zero out options you can't process except for the type and length, you win for fields of the first class. In the case of the second class, the field will be hashed blindly as its value, and you will lose if its value doesn't happen to be zero. In the case of the third class, the field has a value that is computed for authentication to match what it would look like at the receiver -- if it doesn't happen that the value should be zero, you lose. If you blindly hash options you can't process, you lose for the first class unless the values you blindly hash happen to be zero. You never lose in the second class. You lose in the third class unless you are the receiver, in which case the values you see and hash are also what you're supposed to see at the receiver (because you ARE the receiver). Skipping over the options you can't process is clearly bad to me because you always lose if one of the ends can process the option. Coincidental zeros aside, you lose in two of the three cases if you zero out the fields other than type and length. Coincidental zeros aside, you lose in one case all the time and another if you are not the receiver if you blindly hash the options you can't process. Sixth assertion: Blindly hashing the value gives you clearly better security if both sides can't process an option and slightly better security if one side can't process an option. It also provides for a simpler implementation versus hashing the type and length and zeroing the rest, which would otherwise be the next best way to handle the problem of IPv4 options you can't process. For purposes of processing IPv4 options when you don't know how, keep in mind this statement from RFC1122: "For this purpose, every IP option except NOP and END-OF-LIST will include a specification of its own length." RFC791 says that there are two forms an IPv4 option can take: "Case 1: a single octet of option-type. Case 2: An option-type octet, an option-length octet, and the actual option-data octets.". Seventh assertion: There are no options of case 1 that make sense other than NOP and END-OF-LIST, which all non-brain-damaged systems can handle. Therefore, all options that you do not know how to process will be of case 2, and you can therefore determine the length of options you can't handle. This allows you to get back on track when an unknown option is followed by a known option. You're walking with a safety-net here -- in the event that this assertion is not true, you will eventually either run into an option that looks legitimate or come into a situation where you are out of option data. Eighth assertion: If you encounter an out-of-option-data situation or encounter the END-OF-LIST option with more data between it and the end of the option space data (the IP header length with the size of the base IP header subtracted), you treat all offending data as an unknown option and, therefore, you blindly hash it. If you run into, for instance, a source route, and that source route's length points outside the option space data length (computed as aforementioned), something is wrong with the source route and you can't process it properly. If you know with certainty that the option is bad, immediately drop the packet. There is no point in computing the hash over a known-bogus packet and/or passing it on to the next hop. Padding between the END-OF-LIST option and the end of option space data "is zero" [RFC791]. This data should be blind-hashed. From ipsec-request@ans.net Fri Aug 11 21:59:42 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14268 (5.65c/IDA-1.4.4 for ); Fri, 11 Aug 1995 17:11:26 -0400 Received: by interlock.ans.net id AA69161 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 11 Aug 1995 17:01:51 -0400 Message-Id: <199508112101.AA69161@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 11 Aug 1995 17:01:51 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 11 Aug 1995 17:01:51 -0400 To: ipsec@ans.net Cc: ipng@sunroof.eng.sun.com Subject: Part Three: Field Variance Analysis Date: Fri, 11 Aug 1995 16:59:42 -0500 From: Craig Metz The second thing that I've heard that I disagree with is that the IP header has so many more variant fields and fields that aren't critical to security that we should just use a pseudo-header. One thing in these arguments I disagree with is the definition of "critical to security". Ninth assertion: Fields that can be used for denial-of-service attacks must be authenticated so that the denial-of-service attack can be detected and logged. Even if mucking with a field can't be used to get into a system, steal a connection, or something direct like that, it frequently has the ability to cause other denial-of-service situations. When any denial-of- service attack is in progress, you need to be able to know this in order to stop it. Fields that aren't critical to system security but could be modified to create a denial-of-service attack should still be authenticated for the sole purpose of detecting that attack. Also, I'm not a cryptographer and I don't play one on TV, but it would seem to me that known nonzero but not really important values are probably better than zero values and should not be worse. It would seem to me that information of that sort should be stirred into the pot just to have some nonzero bits in the stew. Someone who knows more about cryptography and cryptographic checksums could offer better input on this subject, but, unless someone with more crypto experience can explain otherwise, I am working from the assumption that nonzero fields are better than zero fields. Some discussion should be given to reserved fields. Currently, I believe that reserved fields should be included in the hash for exactly the same reason unknown option fields should be. The argument and cases is exactly the same. That all said, this is what I concluded for variance: Legend: Classes: Invariant = If this field changes, the packet is not authentic (C) = Changed by some routers. By definition, however, the packet is not actually authentic if this field is changed and not changed back before the next AH check. Variant = If this field changes, the packet is still authentic (L) = Due to layering (e.g., of fragmentation below AH) (T) = Due to transit Predictable = This field changes deterministically, so we can figure out what it will look like at the receiver Actions: Hash = Run straight through hash (R) = Redundant, i.e., should be authentic by virtue of getting to AH processing, but we still want a crypto guarantee Zero = Run a same-size zero block through hash Roll = "Roll-forward"/compute how it would look at the receiver after re-assembly, run result through hash Other Symbols: (deprecated) = Obsolete or never caught on. If I label your favorite option deprecated, don't think I'm trying to slam it. It's just that I don't know of any system that uses it. You can probably get away with not processing deprecated options, but I wouldn't recommend that you do so. (*)(+) = Indicate footnotes follow with more info. ==== IPv4 ==== IPv4 Header: [RFC791] Field Size Class Action Version 4 bits Invariant Hash (R) IHL 4 bits Invariant (C) Hash (R) TOS 8 bits Invariant (C) Hash Total length 16 bits Invariant (C) Hash (R) Identification 16 bits Invariant Hash Flags: Reserved 1 bit Invariant Hash DF 1 bit Invariant Hash MF 1 bit Predictable Roll (=Zero) Fragment off. 13 bits Predictable Roll (=Zero) Time to Live 8 bits Variant (T) Zero Protocol 8 bits Invariant Hash (R) Header Checksum 16 bits Variant (L) Zero (R) Source Address 32 bits Invariant Hash Destination Ad. 32 bits Predictable(*) Roll(*) (*) If a source route is present and the pointer is less than the length (indicating that this is not the final destination), the Destination Address field must be filled in with the last destination address in the source route's list. IPv4 End of Option List Option: [RFC791] Field Size Class Action Type 8 bits Invariant Hash IPv4 No Operation: [RFC791] Field Size Class Action Type 8 bits Invariant Hash IPv4 Security Option: [RFC791] (*) (deprecated) Field Size Class Action Type 8 bits Invariant Hash Length 8 bits Invariant Hash Security (S) 16 bits Invariant Hash Compartments(C) 16 bits Invariant Hash Handling Rst(H) 16 bits Invariant Hash Trans. Ctl(TTC) 24 bits Invariant Hash (*) This option has the same type value (130) as the IPv4 Basic Security option [RFC1108]. IPv4 Loose/Strict Source and Record Route options: [RFC791] Field Size Class Action Type 8 bits Invariant Hash Length 8 bits Invariant Hash Pointer 8 bits Predictable(*) Roll Data var. Predictable(+) Roll (*) At the final destination, the Pointer will be equal to (Length+1) (+) The algorithm for rolling source route data is: 0. If Pointer > Length, don't roll (you have it already) 1. Hash up to the octet before the one pointed to by Pointer 2. Hash the destination address in the IP header 3. If (Pointer + (size of dest address)) > Length, you're done 4. Hash from Pointer to (Length - (size of the dest. address)) IPv4 Record Route option: [RFC791] Field Size Class Action Type 8 bits Invariant Hash Length 8 bits Invariant Hash Pointer 8 bits Variant Zero Data var. Variant Zero IPv4 Stream Identifier option: [RFC791] (deprecated) Field Size Class Action Type 8 bits Invariant Hash Length 8 bits Invariant Hash Stream ID 16 bits Invariant Hash IPv4 Internet Timestamp option: [RFC791] (deprecated) Field Size Class Action Type 8 bits Invariant Hash Length 8 bits Invariant Hash Pointer 8 bits Variant Zero Overflow 4 bits Variant Zero Flag 4 bits Invariant Hash Data var. Variant Zero IPv4 Probe/Reply MTU options: [RFC1063] (*) (deprecated) Field Size Class Action Type 8 bits Invariant Hash Length 8 bits Invariant Hash Value 16 bits Variant Zero (*) RFC1700, Assigned Numbers, lists RFC1191 as being the current specification for these options. RFC1191 is the current specification for Path MTU Discovery and obseletes RFC1063, but it does not mention this option at all. RFC1063 defines the latest version of this options. IPv4 Basic Security option: [RFC1108] (*) Field Size Class Action Type 8 bits Invariant Hash Length 8 bits Invariant Hash Classification 8 bits Invariant Hash Protection Auth var. Invariant Hash (*) This option has the same type value (130) as the IPv4 Security option [RFC791]. IPv4 Extended Security option: [RFC1108] Field Size Class Action Type 8 bits Invariant Hash Length 8 bits Invariant Hash Add. Info Fmt. 8 bits Invariant Hash Add. Info var. Invariant Hash IPv4 Traceroute option: [RFC1393] (deprecated) Field Size Class Action Type 8 bits Invariant Hash Length 8 bits Invariant Hash ID Number 16 bits Invariant Hash Outbound Hop C. 16 bits Variant Zero Return Hop Cnt. 16 bits Variant Zero Originator IP 32 bits Invariant Hash ==== IPv6 ==== IPv6 Header: [draft-ietf-ipngwg-ipv6-spec-02] Field Size Class Action Version 4 bits Invariant Hash (R) Priority 4 bits Invariant Hash Flow Label 24 bits Invariant Hash Payload Length 16 bits Invariant Hash (R) Next Header 8 bits Invariant Hash (R) Hop Limit 8 bits Variant (T) Zero Source Address 128 bit Invariant Hash Destination Ad. 128 bit Predictable(*) Roll(*) (*) If a source route is present and the pointer is less than the length (indicating that this is not the final destination), the Destination Address field must be filled in with the last destination address in the source route's list. IPv6 Hop-by-Hop/Destination Options Headers: [draft-ietf-ipngwg-ipv6-spec-02] Field Size Class Action Next Header 8 bits Invariant Hash Hdr Ext Len 8 bits Invariant Hash Option Data var. var.(*) var.(*) (*) If the third-highest-order bit in the Option Type is set, the Option Data MUST be Zeroed. If the third-highest-order bit in the Option Type is not set, you must either Hash or Roll, depending on the option. IPv6 Pad1 Option: [draft-ietf-ipngwg-ipv6-spec-02] Field Size Class Action Option Type 8 bits Invariant Hash IPv6 PadN Option: [draft-ietf-ipngwg-ipv6-spec-02] Field Size Class Action Option Type 8 bits Invariant Hash Option Length 8 bits Invariant Hash Option Data var. Invariant Hash IPv6 Jumbo Payload Option: [draft-ietf-ipngwg-ipv6-spec-02] Field Size Class Action Option Type 8 bits Invariant Hash Option Length 8 bits Invariant Hash Option Data 32 bits Invariant Hash IPv6 Routing Header: [draft-ietf-ipngwg-ipv6-spec-02] Field Size Class Action Next Header 8 bits Invariant Hash Routing Type 8 bits Invariant Hash (*) (*) (*) (*) (*) More data follows depending on type. IPv6 Routing Header Type 0: [draft-ietf-ipngwg-ipv6-spec-02] Field Size Class Action Next Header 8 bits Invariant Hash Routing Type 8 bits Invariant Hash Num Addrs 8 bits Invariant Hash Next Addr 8 bits Predictable(*) Roll(*) Reserved 8 bits Invariant Hash Strict/Loose 24 bits Invariant Hash Addresses var. Predictable(+) Roll(+) (*) At the final destination, the Next Addr field will be equal to the Num Addrs field (+) The algorithm for rolling source route data is: 0. If Next Addr = Num Addrs field, don't roll (you have it) 1. Hash Address[0] through Address[Next Addr - 1] 2. Hash the destination address in the IPv6 header 3. If (Next Addr + 1) > Length, you're done 4. Hash from Address[Next Addr] through Address[Num Addrs - 2] IPv6 Fragment Header: (*) [draft-ietf-ipngwg-ipv6-spec-02] Field Size Class Action Next Header 8 bits Invariant Hash Reserved 8 bits Invariant Hash Fragment Offset 13 bits Predictable Roll (=Zero) Res 2 bits Invariant Hash M flag 1 bit Predictable Roll (=Zero) Identification 32 bits Predictable Hash (*) This is academic, since you MUST not ever authenticate fragments except when the fragments are inside a tunnel (AH processing is done before fragmentation and after re-assembly). ==== IPv4/IPv6 Common ==== IP Authentication Header: (*) [RFC1826] Field Size Class Action Next Header 8 bits Invariant Hash Length 8 bits Invariant Hash Reserved 16 bits Invariant Hash Security Param. 32 bits Invariant Hash Auth. Data var. Variant (L)(+) Zero (*) Yes, you have to authenticate the authentication header. (+) You have to zero this field or you get a chicken-and-egg problem. IP Encapsulating Security Payload: [RFC1827] Field Size Class Action Security Associ 32 bits Invariant Hash Opaque Transfor var. Invariant(*) Hash(*) (*) Unless the authenticating point participates in the ESP key management, it doesn't know what the transform. Treating all of this data as opaque seems to be the most reasonable thing given the nature of the data and the currently defined DES-CBC transform. From ipsec-request@ans.net Fri Aug 11 23:44:22 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15511 (5.65c/IDA-1.4.4 for ); Fri, 11 Aug 1995 18:55:27 -0400 Received: by interlock.ans.net id AA59909 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 11 Aug 1995 18:46:44 -0400 Message-Id: <199508112246.AA59909@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Fri, 11 Aug 1995 18:46:44 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 11 Aug 1995 18:46:44 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 11 Aug 1995 18:46:44 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 11 Aug 1995 18:46:44 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 11 Aug 1995 18:46:44 -0400 From: pau@watson.ibm.com (Pau-Chen Cheng) X-Mailer: exmh version 1.5.3 12/28/94 To: Craig Metz Cc: ipsec-dev@eit.com, ipsec@ans.net Subject: Re: Part Three: Field Variance Analysis In-Reply-To: (Your message of Fri, 11 Aug 95 16:59:42 EST.) <199508112101.AA69161@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 11 Aug 95 18:44:22 -0500 Craig, I just glanced over your 3 parts. I have not thought them over in details yet. But I have a simple question : I got the impression if a IP header field is labeled "invariant" by you, it does not mean it will not be changed. It means that if it is changed, then the packet should be considered "bad". Is my impression correct ? Thank you. Regards, Pau-Chen From ipsec-request@ans.net Sat Aug 12 02:54:44 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13331 (5.65c/IDA-1.4.4 for ); Fri, 11 Aug 1995 23:38:06 -0400 Received: by interlock.ans.net id AA21252 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 11 Aug 1995 23:01:51 -0400 Message-Id: <199508120301.AA21252@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 11 Aug 1995 23:01:51 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 11 Aug 1995 23:01:51 -0400 From: Germano Caronni Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 11 Aug 1995 23:01:51 -0400 Subject: SKIP (Security on the IP Layer) Sources To: skip-info@tik.ee.ethz.ch, ipsec@ans.net, chris@phil15.uni-sb.de (Chris Blum), roessler@sobolev.rhein.de (Thomas Roessler), rmuchsel@iiic.ethz.ch, lubich@tik.ee.ethz.ch (Hannes Lubich), plattner@tik.ee.ethz.ch (Bernhard Plattner), maurer@tik.ee.ethz.ch, almesber@di.epfl.ch (Werner Almesberger), skip@tik.ee.ethz.ch (SKIP Software), freeskip@incog.com, boyns@sdsu.edu, guru@arl.wustl.edu, etter@tik.ee.ethz.ch (Felix Etter), wilde@tik.ee.ethz.ch (Erik Wilde), bauer@tik.ee.ethz.ch (Daniel Bauer), gutekuns@tik.ee.ethz.ch (Thomas Gutekunst), iialan@iifeak.swan.ac.uk Date: Sat, 12 Aug 1995 04:54:44 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24 PGP5a] Content-Type: text Content-Length: 1547 -----BEGIN PGP SIGNED MESSAGE----- Hello everybody, the Swiss version of SKIP is now available as a pre-alpha source code release for IRIX, NetBSD, Nextstep and Solaris. You may get it from ftp://ktik0.ethz.ch/~ftp/pub/packages/skip. Have fun, Germano Excerpt from the README: ======================================================================== This is ENskip, pre-alpha 0.10. ENskip is a security module for the TCP/IP stack. It provides encryption, authentication and sequencing of packets on the IP layer between two or more machines. For more information on the SKIP protocol, see the Internet Draft draft-ietf-ipsec-aziz-skip-00.txt and following. You might also want to check http://skip.incog.com for information about the background, the protocol itself and future directions of it. ENskip is pre-alpha. If you are not absolutely sure what this is all about, you might want to read the draft, and perhaps reconsider using this package. No bug-fixes, installation help or any other support is granted. If you have any suggestions, comments or contributions to make ENskip work better, mail to skip@tik.ee.ethz.ch. Enjoy! M. Hauber and Ch. Schneider G. Caronni ======================================================================= -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMCwX8rH8jId7euXhAQEJ4gP9EiwqFbUQI7XsLRDmZidFdzGHsTk2CQYx GnDBM9Z5F117UDd5NLyK99h2QVuffjK9LxMd4KbTrO5gwKM/OeZHoJTdkfQHb3mN FJrg++hWlrTggrrv6mPQuB2j4TzbsHwed2uLN/f9HmImFQtZ5UPqIUgTueJy5DDa 3DKmCVnpsfU= =sjb1 -----END PGP SIGNATURE----- From ipsec-request@ans.net Sat Aug 12 15:48:57 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13376 (5.65c/IDA-1.4.4 for ); Sat, 12 Aug 1995 11:56:44 -0400 Received: by interlock.ans.net id AA47741 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 12 Aug 1995 11:53:02 -0400 Message-Id: <199508121553.AA47741@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Sat, 12 Aug 1995 11:53:02 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 12 Aug 1995 11:53:02 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 12 Aug 1995 11:53:02 -0400 To: Bob Smart Cc: ipsec@ans.net, bound@zk3.dec.com Subject: Re: What can applications running over ipsec assume? In-Reply-To: Your message of "Wed, 09 Aug 95 07:37:58 +1000." <199508082138.AA32216@interlock.ans.net> Date: Sat, 12 Aug 95 11:48:57 -0400 From: bound@zk3.dec.com X-Mts: smtp > My own view is that the ipsec layer should pass the security characteristics > of a received packet up to the transport layer. It, in turn, must > match those characteristics against what the user has requested. Packets > that don't meet those requirements are dropped. > >This seems sensible. It implies modifications to APIs at 2 layer boundaries. >I guess if there was work proceeding to define these API changes you would >have mentioned it... This would be very useful and if we do an API can we PLEASE make sure its not just for UNIX but can be used by MVS, VMS, NT, WINSOCK, etc.. thanks /jim From ipsec-request@ans.net Sat Aug 12 19:15:00 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12595 (5.65c/IDA-1.4.4 for ); Sat, 12 Aug 1995 15:20:48 -0400 Received: by interlock.ans.net id AA30711 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 12 Aug 1995 15:17:04 -0400 Message-Id: <199508121917.AA30711@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Sat, 12 Aug 1995 15:17:04 -0400 X400-Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Sat, 12 Aug 1995 15:17:04 -0400 X400-Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 12 Aug 1995 15:17:04 -0400 X400-Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 12 Aug 1995 15:17:04 -0400 Date: Sat, 12 Aug 1995 15:15:00 -0400 X400-Originator: /dd.id=1618054/g=warwick/i=ws/s=ford/@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.209:12.07.95.19.15.57] X400-Content-Type: P2-1984 (2) Content-Identifier: Proposal for ... From: "warwick (w.s.) ford" Sender: "warwick (w.s.) ford" To: pem-dev@tis.com, cat-ietf@mit.edu, ipsec@ans.net, e-payment@cc.bellcore.com, www-security@ns2.rutgers.edu, ietf-payments@cc.bellcore.com, pki-twg@nist.gov Subject: Proposal for New IETF WG on PKI Over the past couple of weeks, a group of interested individuals has been putting together a proposal for a new IETF Working Group to develop Internet standards for an X.509-based public-key infrastructure. The result is the draft WG Charter attached below. Since plans were announced last year to form this WG (and to shut down the PEM WG) it is considered reasonable to start up the new WG without the usual preliminary BOF at the next IETF. Steve Kent and I have offered our services to co-chair this group, and Chandra Shrivastava has offered to run a mailing list. The following mailing list has now been established for discussion of this proposal: ietf-pkix@tandem.com. To subscribe to the mailing list, send a messsage to listserv@tandem.com with the following in the body: subscribe ietf-pkix Warwick Ford -------------------------------------------------------------------- Public-Key Infrastructure (X.509) Group IETF Working Group Charter --------------------------------------- Chair(s): Applications Area Director(s) Area Advisor: Mailing lists: General Discussion: To Subscribe: In Body: Archive: Description of Working Group: Many Internet protocols and applications which use the Internet employ public-key technology for security purposes and require a public-key infrastructure (PKI) to securely deliver public keys to widely-distributed users or systems. The X.509 standard constitutes a widely-accepted basis for such an infrastructure, defining data formats and procedures related to distribution of public keys via certificates digitally signed by certification authorities (CAs). RFC 1422 specified the basis of an X.509-based PKI, targeted primarily at satisfying the needs of Internet Privacy Enhanced Mail (PEM). Since RFC 1422 was issued, application requirements for an Internet PKI have broadened tremendously, and the capabilities of X.509 have advanced with the development of standards defining the X.509 version 3 certificate and version 2 certificate revocation list (CRL). The task of the Working Group will be to develop Internet standards needed to support an X.509-based PKI. The goal of this PKI will be to facilitate the use of X.509 certificates in multiple applications which make use of the Internet and to promote interoperability between different implementations choosing to make use of X.509 certificates. The resulting PKI is intended to provide a framework which will support a range of trust/hierarchy environments and a range of usage environments (RFC1422 is an example of one such model). Candidate applications to be served by this PKI include, but are not limited to, PEM, MOSS, GSS-API mechanisms (e.g., SPKM), ipsec protocols, Internet payment protocols, and www protocols. This project will not preclude use of non-infrastructural public-key distribution techniques nor of non-X.509 PKIs by such applications. Efforts will be made to coordinate with the IETF White Pages (X.500/WHOIS++) project. The group will focus on tailoring and profiling the features available in the v3 X.509 certificate to best match the requirements and characteristics of the Internet environment. Other topics to be addressed potentially include: - Alternatives for CA-to-CA certification links and structures, including guidelines for constraints - Revocation alternatives, including profiling of X.509 v2 CRL extensions - Certificate and CRL distribution options (X.500-based, non-X.500-based) - Guidelines for policy definition and registration - Administrative protocols and procedures, including certificate generation, revocation notification, cross-certification, and key-pair updating - Naming and name forms (how entities are identified, e.g., email address, URN, DN, misc.) Goals and Milestones: Sep, 95 Agreement on draft Working Group charter Nov, 95 Completion of initial strawman PKI specification Dec, 95 First Working Group meeting (Dallas IETF) Jul, 96 Submit PKI (X.509) specification for consideration as Proposed standard. From ipsec-request@ans.net Mon Aug 14 08:54:53 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA04255 (5.65c/IDA-1.4.4 for ); Mon, 14 Aug 1995 04:39:28 -0400 Received: by interlock.ans.net id AA67745 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 14 Aug 1995 04:33:49 -0400 Message-Id: <199508140833.AA67745@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 14 Aug 1995 04:33:49 -0400 From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: SKIP (Security on the IP Layer) Sources To: caronni@tik.ee.ethz.ch (Germano Caronni) Date: Mon, 14 Aug 1995 09:54:53 +0100 (BST) Cc: skip-info@tik.ee.ethz.ch, ipsec@ans.net, chris@phil15.uni-sb.de, roessler@sobolev.rhein.de, rmuchsel@iiic.ethz.ch, lubich@tik.ee.ethz.ch, plattner@tik.ee.ethz.ch, maurer@tik.ee.ethz.ch, almesber@di.epfl.ch, skip@tik.ee.ethz.ch, freeskip@incog.com, boyns@sdsu.edu, guru@arl.wustl.edu, etter@tik.ee.ethz.ch, wilde@tik.ee.ethz.ch, bauer@tik.ee.ethz.ch, gutekuns@tik.ee.ethz.ch In-Reply-To: <199508120254.EAA01312@ktik6> from "Germano Caronni" at Aug 12, 95 04:54:44 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 923 > This is ENskip, pre-alpha 0.10. ENskip is a security module for the TCP/IP > stack. It provides encryption, authentication and sequencing of packets on > the IP layer between two or more machines. For more information on the SKIP > protocol, see the Internet Draft draft-ietf-ipsec-aziz-skip-00.txt and > following. You might also want to check http://skip.incog.com for information > about the background, the protocol itself and future directions of it. > > ENskip is pre-alpha. If you are not absolutely sure what this is all about, > you might want to read the draft, and perhaps reconsider using this package. Well RMS will probably dislike your license which effectively is a derivative work of the GLPL and thus quite possibly a copyright violation in itself, and I can't use the code with the Linux kernel with its present license. I'll stick to playing with IP-AH, IP-ESP for the moment on that basis Alan From ipsec-request@ans.net Mon Aug 14 09:07:02 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12972 (5.65c/IDA-1.4.4 for ); Mon, 14 Aug 1995 04:49:22 -0400 Received: by interlock.ans.net id AA67554 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 14 Aug 1995 04:46:00 -0400 Message-Id: <199508140846.AA67554@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 14 Aug 1995 04:46:00 -0400 From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: SKIP (Security on the IP Layer) Sources [OOPS] To: caronni@tik.ee.ethz.ch (Germano Caronni) Date: Mon, 14 Aug 1995 10:07:02 +0100 (BST) Cc: skip-info@tik.ee.ethz.ch, ipsec@ans.net, chris@phil15.uni-sb.de, roessler@sobolev.rhein.de, rmuchsel@iiic.ethz.ch, lubich@tik.ee.ethz.ch, plattner@tik.ee.ethz.ch, maurer@tik.ee.ethz.ch, almesber@di.epfl.ch, skip@tik.ee.ethz.ch, freeskip@incog.com, boyns@sdsu.edu, guru@arl.wustl.edu, etter@tik.ee.ethz.ch, wilde@tik.ee.ethz.ch, bauer@tik.ee.ethz.ch, gutekuns@tik.ee.ethz.ch In-Reply-To: <199508120254.EAA01312@ktik6> from "Germano Caronni" at Aug 12, 95 04:54:44 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 82 Sincere apologies all. That was meant to be a reply to the originator only Alan From ipsec-request@ans.net Mon Aug 14 16:09:52 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13016 (5.65c/IDA-1.4.4 for ); Mon, 14 Aug 1995 11:35:34 -0400 Received: by interlock.ans.net id AA23962 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 14 Aug 1995 11:14:17 -0400 Message-Id: <199508141514.AA23962@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 14 Aug 1995 11:14:17 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 14 Aug 1995 11:14:17 -0400 To: Pau-Chen Cheng Cc: ipsec@ans.net Subject: Re: Part Three: Field Variance Analysis In-Reply-To: Your message of "Fri, 11 Aug 1995 18:44:22 EST." <9508112244.AA20004@ixextra2.watson.ibm.com> Date: Mon, 14 Aug 1995 11:09:52 -0500 From: Craig Metz In message <9508112244.AA20004@ixextra2.watson.ibm.com>, Pau-Chen Cheng writes: >Craig, I just glanced over your 3 parts. I have not thought them over in >details >yet. But I have a simple question : > > I got the impression if a IP header field is labeled "invariant" by you, > it does not mean it will not be changed. It means that if it is changed, > then the packet should be considered "bad". Is my impression correct ? Yes. "Invariant = If this field changes, the packet is not authentic". This is to say that there exists a set of fields, which I call invariant, that MUST be passed through the network without change in order for the packet to maintain authenticity. If these invariant fields are changed, then the packet is not authentic. Which fields fall within this definition of invariant is a decision that we need to make by some sort of reasonable consensus. I described my conclusions as a starting point for this. -Craig From ipsec-request@ans.net Mon Aug 14 15:49:41 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15427 (5.65c/IDA-1.4.4 for ); Mon, 14 Aug 1995 12:11:01 -0400 Received: by interlock.ans.net id AA22227 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 14 Aug 1995 11:48:32 -0400 Message-Id: <199508141548.AA22227@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 14 Aug 1995 11:48:32 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 14 Aug 1995 11:48:32 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 14 Aug 1995 11:48:32 -0400 To: bound@zk3.dec.com Cc: ipsec@ans.net Subject: Re: What can applications running over ipsec assume? In-Reply-To: bound@zk3.dec.com's message of 12 Aug 1995 16:05:53 -0000 Date: Mon, 14 Aug 1995 11:49:41 -0400 From: Marc Horowitz >> This would be very useful and if we do an API can we PLEASE make sure >> its not just for UNIX but can be used by MVS, VMS, NT, WINSOCK, etc.. This is a laudable goal, but I suspect it's also a rathole of planetary proportions. Just a warning :-) Marc From ipsec-request@ans.net Mon Aug 14 18:43:13 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12899 (5.65c/IDA-1.4.4 for ); Mon, 14 Aug 1995 16:12:05 -0400 Received: by interlock.ans.net id AA68240 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 14 Aug 1995 15:48:48 -0400 Message-Id: <199508141948.AA68240@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 14 Aug 1995 15:48:48 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 14 Aug 1995 15:48:48 -0400 Date: Mon, 14 Aug 95 18:43:13 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Field Variance Analysis > From: Craig Metz > Yes. "Invariant = If this field changes, the packet is not authentic". > This is to say that there exists a set of fields, which I call invariant, that > MUST be passed through the network without change in order for the packet to > maintain authenticity. If these invariant fields are changed, then the packet > is not authentic. Which fields fall within this definition of invariant is > a decision that we need to make by some sort of reasonable consensus. > First, I will agree with Craig's statement, there are header fields that must pass though the network unchanged. Second, I will then utterly disagree with the remainder of his analysis! The unspoken fundamental assumption is that it is better to throw traffic away in the event of uncertainty. I do not agree. We must design for _only_ the utmost certainty. We are not authenticating packet headers. We are authenticating payload data. The purpose is to get that data across a diverse network, not throw as much as possible away. Therefore, in order to promote _use_ of authentication, we need to make it as easy and robust to _use_ as possible! Suddenly discovering that data stops flowing because of a change in some router somewhere that is not under the user's control will not be a big win, folks.... ---- As to specific IP header fields, I have written code that is widely deployed that changes the TOS en route. That is not a "security" violation, it does not affect the _DATA_, it just changes the path characteristics.... I have worked on at least 3 routers that set the "reserved" bit in the IP header when congestion is experienced, and every router and host that I have worked on passes that bit transparently (even if it doesn't use or understand it). My current software base does not use most IP options, and certainly not the IPSO. I do not care about its authenticity, since it does not affect the Security Association that I have with my peer. In short, I am not currently working on software that could possibly talk to Craig's software. That is up to him. It may be his security policy. But I plan on _giving_ this software away to every compatible router vendor that I have ever worked with, and I won't design a security policy that could cause the Internet to fragment! ---- There are only a few fields that require authentication: - the Destination, as it is the field that together with the SPI will determine the Security Association. - the Source, since we probably want to send a response. - the Length, to preclude appending attacks. There are a couple of other fields that we might as well authenticate, as they well known to be invariant: - Version (has to be constant). - Identification (invariant end-to-end, or fragmentation would fail). - Protocol (it had better be ours, or processing will fail anyway). ---- Here is the pseudo header that I have implemented (so far only in the receive direction). I beleive this is similar if not identical to what other vendors have implemented, and hope to test this week. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL | 0 | Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |0 0 0| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Protocol | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options = 0 | Padding = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The rationale is that since we can't predict rearrangement of options, we can't verify them. But if some router _ADDS_ or _REMOVES_ them, or lengthens or shortens existing ones, that in itself could be a security violation, which we can easily test for, using IHL and zero placeholders. I am zeroing not just the Option data fields, but the lengths and types, too. I don't care what they are, as they have absolutely no effect on the authenticity of the payload. Routers can rearrange them to their heart's content.... I never reverse LSRR, so I do not care how authentic it may be. 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 Mon Aug 14 22:27:57 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14759 (5.65c/IDA-1.4.4 for ); Mon, 14 Aug 1995 18:41:35 -0400 Received: by interlock.ans.net id AA52434 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 14 Aug 1995 18:18:16 -0400 Message-Id: <199508142218.AA52434@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 14 Aug 1995 18:18:16 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 14 Aug 1995 18:18:16 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 14 Aug 1995 18:18:16 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 14 Aug 1995 18:18:16 -0400 Date: Mon, 14 Aug 1995 15:27:57 -0700 From: ashar@osmosys.incog.com (Ashar Aziz) To: ipsec@ans.net Subject: SKIP BOF minutes X-Sun-Charset: US-ASCII Here are the minutes from the SKIP BOF, held at the Stockholm IETF meeting. SKIP BOF (July, 19th 1995; 3:30 pm) ==================================== Working Group Session: Simple Key Management for IP Chairperson: Martin Patterson (martinp@france.sun.com) Minutes reported by Hemma Prafullchandra (hemma@incog.com). Agenda: 3:30 Intro and reason for the BOF - Martin Patterson (chair) 3:35 SKIP in AH/ESP 4:05 Presentation of ETHZ SKIP implementation 4:30 Presentation of ELVIS+ SKIP implementation 4:55 Presentation of End-System SKIP implementation 5:20 Q&A and general discussion SKIP in AH/ESP Tom Markson -------------------------- Q1: How is the Kp algorithm related to the ipsec security transforms algorithm ? Kp algorithm is specified using eight bits, so one can assign a number for every transform defined by ipsec. Q2: What if it requires more than eight bits ? Would Sun/author be willing to change the specification to allow it to inter-work with ESP ? Yes, as our goal is to allow SKIP to inter-work with ESP. Q3: What is the lifetime of Kij ? The lifetime of Kij is dependent on the lifetime of the Diffie-Hellman keys of the communicating parties. The lifetime of Kijn is implementation dependent, meaning whenever n is changed Kijn will change. n is never zero. Comment: For interoperability, how n changes also needs to be defined and not only how the initial value is established. Q4: Why not use ephimereal half keys instead of Kijn ? (Hilarie Orman -- we could not answer this to Hilarie's satisfaction. Ashar will have to address this one.) Comment from Hilarie: there are other more elegant solutions ... Q5: The skip header appears in every ESP packet, any plans to integrate skip further into ESP ? No clear consensus. What is the overhead per packet considering there is a skip hdr in every packet ?? Martin --> refered performance numbers on skip... mention of path mtu discovery. Point was made that crypto performance is often CPU bound. (note: Cheryl Madson informed me that path mtu discovery and multicast is not intended to work for ipv4 as per Steve Deering) A request was made for some performance figures on unencrypted data but with skip hdrs to evaluate the skip hdr overhead per packet issue. Also, some figures on cpu/network throughput. A suggestion was made to make use of compressed headers even though state would have to be maintained. (from Jeff Schiller) Q6: what are we doing about certificate distribution ? There is quite a bit of work in progress in this area, no specifications as this time. We have a limited protocol implemented to do bilateral certificate exchange, we are also working on both chained and cross-certification models of the X.509/PEM world and the PGP web-of-trust. We would like to work within ipsec on this. Q7: How many bits of the Diffie-Hellman keys are used to derive the shared secret ? Q8: Now that we are also discussing the key distribution problem why was skip not presented at the ipsec wg session during the key management session ? skip assumes that the communicating parties have already established certified Diffie-Hellman public keys for the corresponding party/parties. Now, we are working on solving the problem of certificate distribution; we have nothing to present yet ! Germano Caronni (skip@tik.ethz.ch) on ETHZ SKIP implementation -------------------------------------------------------------- - based on first draft + modifications - ipsp protocol 79 - unicast only - transport and encapsulated mode - des, idea and "rc4" - keyed MD5 - manual keying - solaris 2.4, NeXTstep, NetBSD - not interoperable with the other implementations ftp over ip with DES+MD5 (ss10 -> ss20) => ~ 300kB/sec This work will be released in the public domain around the 15th of August. Q: why skip and not photuris ? In Feb '95, when my work was started the photuris spec. was not concrete. SKIP much more simple, basically context free. SKIP works with gateways, and has concept for small multicast groups. Still missing: - multicast - key management (key distribution for bilateral key exchange on its way) - no ASN.1, X.509 -- next Differences from spec: - defined padding of Kp if required - for transport mode, used reserved byte after next-p-field to transmit number of pad bytes - authentication over next-p-field, reserved bytes, sequence number, data Q1: which level of OS was this implemented to ? For Solaris, to binary (no source available). For NeXtStep, as a binary patch. For NetBSD, catch interrupts ... ELVIS+ Nickolai Tzarev ---------------------- Two realizations: a) Solaris 2.4 - unicast - simple command line interface - simple graphical interface - MD5 - final release in October Futures: support for multicast and key distribution b) DOS/Windows - NDISv2 compliance driver - NDIS v3 next - final release in November Futures: windows for workgroups and windows95 Q1: cryptography is Russia is banned, how is this going to effect your work ? Encryption/decryption is banned but if used for privacy of personal information then is it okay. Also, the president has signed the decree, the parliament has not. ES-SKIP (Tom Markson) --------------------- Slides from Tom. Q1: Loadable kernel module ? yes, but tried to limit the dependencies on the kernel. Q2: does it always have to below ip layer ? yes Q3: the draft is not sufficient to implement SKIP, the faq's are also required. Are you planning to interate the changes into the draft ? yes, a revision of the draft will be made Q4: what are the node-ids ? Martin -> explanation. Q5: Other groups of algorithms that can be used, is skip flexible enough to support other algorithms, e.g. elliptic curves ? Martin -> yes, though Diffie-Hellman is the implicit default. Q6: How do negotiate what values of the Diffie-Hellman modulus was used ? If you have a 512 bit modulus and a 1024 bit modulus, will they interoperate ? skip does not negotiate this. It is done out-of-band. 512 bit DH keys will not interoperate with 1024 bit DH keys. For interoperability, a set of 512 bits and 1024 bits DH params should be published as part of the draft. Generate a set of these parameters that impeachable in the IETF forum. Internet standards need to be specified in a manner that independent implementations can interoperate. photuris negotiates almost everything, so that if independent implementations existed they are very likely to interoperate. Skip should be able to negotiate which Kij and Kp algorithms are supported by the remote party. Q7: should the faq's be folded incorporated into th skip draft ? Jeff S. -> not necessarily, they can be specified as separate drafts, but all the information needs to be provided, and there needs to concensus on the drafts. Q8: what is the relation with ipsec ? At this point Jeff decided to take a straw-poll. Q: How many people would be happy with skip moving into the standards track as an elective standard ? 80% of the attendees raised their hands, Jeff -> I think there is concensus here to move SKIP into the stds track. Ashar needs to discuss with Jeff S., Paul L. and Ran A. the process by which to proceed further; clearly some changes will be required to the internet-draft. SKIP BOF ROSTER (July, 19th 1995; 3:30 pm) =========================================== Martin Patterson martinp@france.sun.com (Chair) Hemma Prafullchandra hemma@incog.com Joseph Reveane jreveane@france.sun.com Denis Pinkas D.pinkas@frcl.bull.fr Uwe Ellermann Ellermann@cert.dfn.de Ward Bathrick Ward@mls.hac.com Eric Fleischman Ericf@atc.hvery.com Math Aarnro Mea@funet.fi Dragan Greboviom Dragan@bnr.ca Antonin Fernandez Afa@bellcore.com Eric Rescorla Ekr@eit.com Jeff Schiller Jis@mit.edu Richard Graveman Rfg@ctt.bellcore.com Tatu Ylonen Ylo@cs.hut.fi Charlie Kaufman Charlie_Kaufman@iris.com Germano Caronni Caronni@tik.ethz.ch Nick Tzarev Nick@elvis.ru Roman Sagalaev kanat@elvis.ru Don Stephenson Dons@eng.sun.com Masayaki Abe Abe@isl.ntt.jp Marc Hasson Marc@mentat.com Hiroshi Tachibaa Tachi@iij.ad.jp Hilarie Orman Ho@cs.arizona.edu Sven Tafvelin Tafvelin@ce.chalmers.se David Johnson Dbj@cs.cmu.edu Dan Frommer Dan@radguard.co il Brett Chappell Bchappe@relay.nsmc.navy.mil Bill Medlin Billmd@cap.hp.com Cyrus Chow Cyrus.Chow@arc.nasa.gov Peter Yee Yee@Spyrus.com Sean Kennedy Liam@bbnplanet.com Mark Hollinger Myth@ucx.lkg.dec.com Mark Scherther Mjs@tycho.ncsc.mil David Carrel Carrel@cisco.com Leonid Yegoshin Egoshin@ihep.su Marcus Leech Mleech@bnr.ca Matti Huvila Matti.Huvila@abo.fi Randy Catoe Randy@mci.net Bob Gilligan Gilligan@Eng.sun.com Johan Sandfeldt Johan.Sandfeldt@it.ki.se Carl Smith Cs@Eng.sun.com Hans Davidson Hans.Davidson@it.ki.se Nevil Brownlee N.Brownlee@auckland.ac.nz Gunnar Lindberg Lindberg@cs.chalmers.se Fumio Teraoka Tera@csl.sony.co.jp Joaquim Macedo Macedo@umunho.pt Don Bonaddio Donbon@it.hq.nasa.gov Cheryl Madson Cmadson@baynetworks.com Chris Shenton Cshenton@wirehead.hq.nasa.gov Paul Lambert Paul_Lambert@email.mot.com Joseph Ferracin Joseph.Ferracin@ed.nce.sita.int Juha-Pekka Ahopello Juha-Pekka.Ahopello@ntc.nokia.com Urs Eppenberger Eppenberger@switch.ch Osman Ismael Osman@france.sun.com Bo Kullmar Bo.Kullmar@riksbank.se Henry Sihnreich Hsinreich@mcimail.com William R. Soley Soley@eng.sun.com Alon Cohen Alon@vocaltec.com Ute Bormam Ute@informatikuni-bremen.de M. Hampton M.Hampton@ic.ac.uk Peter Ford Pford@mci.net Tom Markson Markson@incog.com From ipsec-request@ans.net Tue Aug 15 03:20:08 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12138 (5.65c/IDA-1.4.4 for ); Mon, 14 Aug 1995 22:30:53 -0400 Received: by interlock.ans.net id AA60218 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 14 Aug 1995 22:21:07 -0400 Message-Id: <199508150221.AA60218@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 14 Aug 1995 22:21:07 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 14 Aug 1995 22:21:07 -0400 To: William Allen Simpson Cc: ipsec@ans.net Subject: Re: Field Variance Analysis In-Reply-To: Your message of "Mon, 14 Aug 1995 18:43:13 GMT." <199508141948.AA68240@interlock.ans.net> Date: Mon, 14 Aug 1995 22:20:08 -0500 From: Craig Metz In message <199508141948.AA68240@interlock.ans.net>, "William Allen Simpson" wr ites: >First, I will agree with Craig's statement, there are header fields that >must pass though the network unchanged. Well, at least we agree here. > >Second, I will then utterly disagree with the remainder of his analysis! While I find this unfortunate, it's important that we be talking about these things and come to some sort of consensus. >The unspoken fundamental assumption is that it is better to throw >traffic away in the event of uncertainty. I do not agree. We must >design for _only_ the utmost certainty. I think that we are disagreeing as to what certainty we would like to provide with the Authentication Header. It is my opinion that we need to provide certainty that the packet that arrives at the receiver is what the sender expected the receiver to receive and that the claimed sender is the actual sender. These guarantees are at odds with certainty of packet delivery in some cases that you have brought up. I have not seen a case presented yet, however, in which it was not my clear opinion that the spirit, if not the letter, of the appropriate standards and reasonable network practice was being violated. >We are not authenticating packet headers. We are authenticating payload >data. The purpose is to get that data across a diverse network, not >throw as much as possible away. This is a fundamentally important design decision. I believe that this has already been decided. If it has not, then we better do so now before trying to proceed, because it has a dramatic effect on further directions. It is my understanding that there are basically three "checklist" attacks that IPsec must offer reasonable protection against, and it is my understanding that these are requirements that we either meet or pack up and go home: 1. TCP connection stealing 2. Source-route attacks 3. IPSO modifications The third is one that many people discount, claiming that IPSO is just broken and shouldn't be a factor. I'm not here to judge IPSO, but certain government organizations have a large IPSO deployed base and they won't buy into IPsec at all if it leaves them SOL with IPSO. Both the second and third on this list implies no alternative but to protect IPv4 options if we are going to defend against these attacks. If we aren't going to defend against these attacks, then we can talk in terms of not authenticating options. >Therefore, in order to promote _use_ of authentication, we need to make it >as easy and robust to _use_ as possible! Suddenly discovering that data >stops flowing because of a change in some router somewhere that is not >under the user's control will not be a big win, folks.... Bill, I've been at sites that use Proxy-ARP as an IGP across multiple buildings. I've been at sites where admins ROUTINELY assign multiple machines the same IP address. I've been at sites where a single, massive Ethernet has over three hundred machines directly attached (no routers, no bridges, all gobs of big hubs). You and I can probably agree that these are three scenarios that are examples of bad network design. In none of those cases did the parts used to build those networks come out of the box drain bamaged -- bonehead network administrators made them that way. And they won't go and fix it BECAUSE IT SEEMS TO WORK. This has a lot to do with my fundamental disagreement with you on the Cisco/Telebit router issue. On the Ciscos, yes, you can configure them in ways that will cause them to munge IPv4 headers. This is a configuration that is as valid per the specs as using Proxy ARP as your IGP, and it's a configuration that is just as dead wrong. Causing these kinds of setups to break is more of a feature to me because it forces the admins into the realization that they are doing something that is really brain damaged and that they better fix it. IPsec might just provide a suitable carrot to these network admins to fix things. Also, I strongly believe that sites with Cisco routers configured to munge IPv4 headers are in the vast minority of deployed IP sites. This seems analogous to engineering all UNIX software to run on a VAX 11/780 just because some sites still use them. Do you want to be the person at Cisco that tells large corporate customers who do things right that the security guarantees they're getting from IPsec aren't as strong as they could be because it might break some sites who are doing things that are drain bamaged? I know that I wouldn't want to be. And on the NetBlazer... I've used one for a good bit of time, and I have never noticed it messing with my TOS bits. I'd be interested in more data on this example of yours (as with the Cisco example, you have provided a canned conclusion as a reason for why network-level data must be all but omitted from IPsec without much data to independently confirm or deny your claims). RFC791 doesn't say it, but it seems to me that routers that twiddle the TOS bits aren't conforming to the spirit of the spec even if they might be conforming to the letter. TOS bits tell routers what kind of data the packet is in a form that routers might be able to deal with in a very simplistic way (i.e., low-delay, bulk-data). If a router changes the TOS bits, the routers upstream are getting a different request for treatment than what the sender asked, and I doubt that the router mucking with the TOS bits has more information about the type of data being sent than the sending host. Please don't interpret this to mean that I'm against operating with the installed base. This is not so. I'm for trying to push technology, in this case, trying to push people who've been doing the wrong thing into fixing what they've got. IPsec could provide the motivation for them to do it. >As to specific IP header fields, I have written code that is widely >deployed that changes the TOS en route. That is not a "security" >violation, it does not affect the _DATA_, it just changes the path >characteristics.... It remains unclear to me how a router can know more than the sending host what kind of data is in transit. If we find that enough systems mess with the TOS bits, we can call them variant and move on. Protecting the TOS bits is a Good Thing, IMO, because it pushes people in the direction I believe is correct. The TOS bits are mostly unusable even today because so many widely deployed implementations have completely drain bamaged TOS processing. While I'd like to see that get fixed, I can live with calling TOS a loss and moving on. We all have bigger fish to fry. >I have worked on at least 3 routers that set the "reserved" bit in the >IP header when congestion is experienced, and every router and host that >I have worked on passes that bit transparently (even if it doesn't use >or understand it). Is it just me, or do these statements directly conflict? >My current software base does not use most IP options, and certainly not >the IPSO. I do not care about its authenticity, since it does not >affect the Security Association that I have with my peer. Again, these are design decisions. >In short, I am not currently working on software that could possibly >talk to Craig's software. That is up to him. It may be his security >policy. As I understand it right now, we have a number of bubbles forming of IPsec implementations that won't talk to each other. This is why we need to come to a consensus as to what goes into the authentication soup. >But I plan on _giving_ this software away to every compatible router >vendor that I have ever worked with, and I won't design a security >policy that could cause the Internet to fragment! Then I expect that you'll make sure to give away something that follows the consensus that develops. >There are only a few fields that require authentication: > > - the Destination, as it is the field that together with the SPI will > determine the Security Association. > > - the Source, since we probably want to send a response. The source is also a part of the security association nowadays. Also, source and dest frequently are needed for transport demuxes (for instance, finding the right TCP connection). > - the Length, to preclude appending attacks. Strictly speaking, the total length isn't necessary by your logic, since appending without also munging the checksum will cause the packet to fail auth, and the transport has a length field in all cases I know of. >There are a couple of other fields that we might as well authenticate, >as they well known to be invariant: > > - Version (has to be constant). > > - Identification (invariant end-to-end, or fragmentation would fail). > > - Protocol (it had better be ours, or processing will fail anyway). How do you define this "might as well authenticate"? Could you expand as to how you are making these conclusions? On what basis are you classifying these fields? >Here is the pseudo header that I have implemented (so far only in the >receive direction). I beleive this is similar if not identical to what >other vendors have implemented, and hope to test this week. > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Version| IHL | 0 | Total Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Identification |0 0 0| 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0 | Protocol | 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Source | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Destination | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Options = 0 | Padding = 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >The rationale is that since we can't predict rearrangement of options, >we can't verify them. But if some router _ADDS_ or _REMOVES_ them, or >lengthens or shortens existing ones, that in itself could be a security >violation, which we can easily test for, using IHL and zero placeholders. Again, this is a design question. I can predict that if I send a packet over our routers, it will either get there with its options the same way I sent them or it will get dropped because our filter got it. We have Cisco routers. It just happens that we don't have configurations on our routers that cause them to go munging packets. For that matter, Bill, I've never seen a site in my entire life that has a router that messes with IPv4 options on a packet in transit. Maybe they're more common in your environment. >I am zeroing not just the Option data fields, but the lengths and types, >too. I don't care what they are, as they have absolutely no effect on >the authenticity of the payload. Routers can rearrange them to their >heart's content.... Again, this is a design decision. >I never reverse LSRR, so I do not care how authentic it may be. Personally, I could easily live without source routes. I don't like them -- never have, never will. But there are a number of legitimate cases in which you might need them. Do we tell people who have systems that might process source routes that they're SOL if they use them, or do we try to give them some guarantees through AH? I believe that source routes can be authenticated, and I explained how I think it can be done. I have code that has been able to authenticate IPv4 source routes. If you believe that my method of handling source routes is in error, please elaborate. If you believe that we shouldn't be authenticating options, as you seem to have been indicating, then please explain this conclusion. We need to talk about this. Simply saying that it's not right, we shouldn't do it because people could break, or that you don't care doesn't seem to me to be a good alternative to putting facts on the table that back up your conclusions. -Craig From ipsec-request@ans.net Tue Aug 15 02:58:10 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12235 (5.65c/IDA-1.4.4 for ); Mon, 14 Aug 1995 23:08:24 -0400 Received: by interlock.ans.net id AA65199 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 14 Aug 1995 22:58:10 -0400 Message-Id: <199508150258.AA65199@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 14 Aug 1995 22:58:10 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 14 Aug 1995 22:58:10 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 14 Aug 1995 22:58:10 -0400 Date: Mon, 14 Aug 1995 19:58:10 -0700 From: Hilarie Orman To: cmetz@sundance.itd.nrl.navy.mil Cc: ipsec@ans.net In-Reply-To: Yourmessage <199508150221.AA60218@interlock.ans.net> Subject: Re: Field Variance Analysis > The third is one that many people discount, claiming that IPSO is > just broken and shouldn't be a factor. I'm not here to judge IPSO, but > certain government organizations have a large IPSO deployed base and they > won't buy into IPsec at all if it leaves them SOL with IPSO. Both the second > and third on this list implies no alternative but to protect IPv4 options > if we are going to defend against these attacks. If we aren't going to > defend against these attacks, then we can talk in terms of not authenticating > options. Might not the certain government organizations use encapsulation with a MD5 transform as a method of protecting the IPSO? From ipsec-request@ans.net Tue Aug 15 03:08:10 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14820 (5.65c/IDA-1.4.4 for ); Mon, 14 Aug 1995 23:14:59 -0400 Received: by interlock.ans.net id AA59814 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 14 Aug 1995 23:08:15 -0400 Message-Id: <199508150308.AA59814@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 14 Aug 1995 23:08:15 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 14 Aug 1995 23:08:15 -0400 To: Craig Metz Cc: ipsec@ans.net Subject: Re: Field Variance Analysis In-Reply-To: Your message of "Mon, 14 Aug 1995 22:20:08 CDT." <199508150221.AA60218@interlock.ans.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 14 Aug 1995 23:08:10 -0400 From: "Perry E. Metzger" Craig Metz writes: > Again, this is a design question. I can predict that if I send a > packet over our routers, it will either get there with its options > the same way I sent them or it will get dropped because our filter got it. > We have Cisco routers. It just happens that we don't have configurations > on our routers that cause them to go munging packets. For that matter, > Bill, I've never seen a site in my entire life that has a router that > messes with IPv4 options on a packet in transit. Maybe they're more > common in your environment. I recall that you were mentioning IPSO. I seem to vaguely remember that CISCOs can be set to add IPSO tags to outgoing packets. This would seem to be something that could screw things up. Anyone recall if this is the case? .pm From ipsec-request@ans.net Tue Aug 15 03:12:03 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12072 (5.65c/IDA-1.4.4 for ); Tue, 15 Aug 1995 07:41:21 -0400 Received: by interlock.ans.net id AA39771 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 15 Aug 1995 07:15:10 -0400 Message-Id: <199508151115.AA39771@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 15 Aug 1995 07:15:10 -0400 From: smb@research.att.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 15 Aug 1995 07:15:10 -0400 To: perry@piermont.com Cc: Craig Metz , ipsec@ans.net Subject: Re: Field Variance Analysis Date: Tue, 15 Aug 95 07:12:03 EDT Craig Metz writes: > Again, this is a design question. I can predict that if I send a > packet over our routers, it will either get there with its options > the same way I sent them or it will get dropped because our filter g ot it. > We have Cisco routers. It just happens that we don't have configurat ions > on our routers that cause them to go munging packets. For that matte r, > Bill, I've never seen a site in my entire life that has a router tha t > messes with IPv4 options on a packet in transit. Maybe they're more > common in your environment. I recall that you were mentioning IPSO. I seem to vaguely remember that CISCOs can be set to add IPSO tags to outgoing packets. This would seem to be something that could screw things up. Anyone recall if this is the case? You're absolutely correct. From ipsec-request@ans.net Tue Aug 15 13:36:06 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA04153 (5.65c/IDA-1.4.4 for ); Tue, 15 Aug 1995 09:44:37 -0400 Received: by interlock.ans.net id AA38654 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 15 Aug 1995 09:36:16 -0400 Message-Id: <199508151336.AA38654@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 15 Aug 1995 09:36:16 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 15 Aug 1995 09:36:16 -0400 To: Hilarie Orman Cc: cmetz@sundance.itd.nrl.navy.mil, ipsec@ans.net Subject: Re: Field Variance Analysis In-Reply-To: Your message of "Mon, 14 Aug 1995 19:58:10 PDT." <199508150258.AA65199@interlock.ans.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 15 Aug 1995 09:36:06 -0400 From: "Perry E. Metzger" Hilarie Orman writes: > > The third is one that many people discount, claiming that IPSO is > > just broken and shouldn't be a factor. I'm not here to judge IPSO, > > but certain government organizations have a large IPSO deployed > > base and they won't buy into IPsec at all if it leaves them SOL > > with IPSO. Both the second and third on this list implies no > > alternative but to protect IPv4 options if we are going to defend > > against these attacks. If we aren't going to defend against these > > attacks, then we can talk in terms of not authenticating options. > > Might not the certain government organizations use encapsulation with > a MD5 transform as a method of protecting the IPSO? I believe that Hilarie has hit on the way to cut the gordian knot. If the originating system wants to protect options under IPv4, it probably should encapsulate the whole packet and not just the transport. Perry From ipsec-request@ans.net Tue Aug 15 14:51:15 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14543 (5.65c/IDA-1.4.4 for ); Tue, 15 Aug 1995 11:03:15 -0400 Received: by interlock.ans.net id AA06122 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 15 Aug 1995 10:58:56 -0400 Message-Id: <199508151458.AA06122@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 15 Aug 1995 10:58:56 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 15 Aug 1995 10:58:56 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 15 Aug 1995 10:58:56 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 15 Aug 1995 10:58:56 -0400 To: ipsec@ans.net Subject: Re: Field Variance Analysis Date: Tue, 15 Aug 95 10:51:15 -0400 From: Andy Bayerl X-Mts: smtp Craig metz writes: I recall that you were mentioning IPSO. I seem to vaguely remember that CISCOs can be set to add IPSO tags to outgoing packets. This would seem to be something that could screw things up. Anyone recall if this is the case? And in fact, not only CAN they be configured to mess with IPSO, CISCO's are shipped with a DEFAULT behaviour that allows only unclassified BSO traffic thru. To allow other IPSO (of the RFC1108 flavor) thru you have to jump thru hoops to figure out how to configure the routers. And to this day I am not sure how to do that. Someone obviously decided that this was proper behaviour to keep classified data from accidently being routed to unclassified networks, but it makes deployment of classified networks an administrative nightmare. Now, having gotten that off my chest, I can get off my soapbox and try to add my 2 cents to the issue being discussed. The filtering of packets that do not meet a set of configured criteria, such as the above, is an extreme case of (perhaps inappropriate) behaviour on the part of a router, that can lead to connectivity problems. It relates only tangentially to the more general isues of: a) Whether IPSO options should/may be modified by any router b) Whether IPSO options should be part of the authentication stream c) Whether the IPSO options should be included at all The answer to (a) is yes in the most common deployed MLS (multi-level security) configurations that I am aware of. In this case, however, the "router" in question is really an MLS gateway between networks with differing security policies. It could, potentially, be something like a CISCO configured to filter and add IPSO appropriately, but will often be a B1 or B1/CMW or B2 evaluated MLS system. A configuration might look something like this: Unclassified Classified Single Level ---+ MLS +---+ WAN +---+ MLS +---+ Single Level Network Gateway 1 + Gateway 2 Network | | | + MLS +-----+ Multi-level Gateway 3 Network In this case, the single level systems are assumed to be non-MLS systems which generate and expect traffic with no IPSO. The MLS gateways add IPSO with the appropriate classification and compartments before putting it on the WAN. They strip the IPSO before forwarding packets to the single level networks. The MLS gateway 3 probably just passes the IPSO on unmodified but here there are also cases where the IPSO could be changed to reflect differing policies. A case in point might be where the WAN has routers that only pass RFC1108 BSO IPSO. In that case the ESO (compartments) would be dropped before going out on the WAN. The WAN is assumed to be reliably authenticated, possibly encrypted, and physically secure data link. In IPv4 this is presumably done with special hardware. In IPv6, hopefully, the authentication features would come into play. The caveat here of course would be that it is unlikely that highly classified data would be routed over the big bad Internet but certainly some of it could be. For example, unclassified and confidential compartmented data could perhaps be routed over the Internet with secret and top secret data going over the protected links. So now on to (b). I see the following cases: 1) The endpoint systems are IPv6 security aware (but not necessarily MLS) and do end-to-end authentication. Here, the answer is obviously that the IPSO CANNOT be part of the authentication stream, since the MLS gateways will be adding, stripping or possibly modifying them. This presents a problem to the gateways in that IPSO coming from the WAN cannot be authenticated and cannot be used reliably for routing/filtering decisions. 2) The endpoint systems use unauthenticated IPv6 (or IPv4) possibly with IPSO in the case of the multi-level network. In this case the MLS gateways would add the authentication. (NOTE: I am assuming that this is possible. Can someone please tell me if it is so?) In this case, if we assume the routers on the WAN do not muck with the IPSO, the IPSO could and probably should be part of the authentication stream. This gives us assurance that the IPSO is what it says it is, but it still has the well-known flaw of putting up the bright red flag that says this secured data worthy of analysis. 3) We attempt to use the Security Association features of the authentication mechanism. If the S/A is strictly end-to-end (is this TRUE?), then the answer is simple. The endpoint systems (even the single level ones in my diagram) become MLS aware to the extent that the S/A has an implied senstivity level. The MLS gateways become simple routers, since they are presumably no privy to the S/A and cannot make routing decisions based on the sensitivity level. Number (3) provides the best security and it works for deployment of new programs with endpoint systems that use the latest technology. Unfortunately, in my experience, that is rarely the case. Usually, there is a VERRRYYYY long lag time between program inception and actual deployment and once deployed it is extremely difficult to inject updates. I suspect that the answer will probably be encapsulation, as suggested by Hillarie. I am not completely sure how works in gory detail, but seems to be the only real answer in this type of configuration. /andy From ipsec-request@ans.net Tue Aug 15 18:08:08 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12146 (5.65c/IDA-1.4.4 for ); Tue, 15 Aug 1995 14:15:43 -0400 Received: by interlock.ans.net id AA23272 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 15 Aug 1995 14:09:05 -0400 Message-Id: <199508151809.AA23272@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 15 Aug 1995 14:09:05 -0400 From: Ran Atkinson Date: Tue, 15 Aug 1995 14:08:08 -0400 Reply-To: rja@cs.nrl.navy.mil X-Mailer: Z-Mail (3.2.1 10apr95) To: ipsec@ans.net Subject: IP AH code fragment from NRL Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: rja@bodhi.cs.nrl.navy.mil IP Security WG Folks, I've gotten permission to put a longish code fragment from the NRL implementation of IP Authentication Header (for IPv6 & IPv4) out for anonymous ftp at the URL below: ftp://ftp.nrl.navy.mil/pub/security/ipsec This is copyrighted but freely distributable under the license terms included at the front of the file. It is part of our overall implementation of IPv6 (including ESP and AH), IPv4 ESP, and IPv4 AH inside 4.4-lite BSD. We anticipate that our "alpha" release of all of this software will be available this fall under these same terms. NRL's work on IP Security is sponsored by ARPA/CSTO and SPAWAR. This is the code that Craig Metz has been discussing and is posted primarily to refute by existence-proof the idea that it is too hard to implement IP options processing as specified in the Proposed Standard RFC. The posted code works. Not all of the IP options supported by our AH implementation are supported by the remainder of our IPv4 stack, which serves to demonstrate that one doesn't have to add full support for all of the IPv4 options in order to process them properly for AH. I will have some other AH comments coming in a few days as I get time. I've been gone unexpectedly for part of the summer and have been busy writing code for the remainder of the summer. I have to say that writing code is among the more pleasant ways to spend one's days. Regards, Ran rja@cs.nrl.navy.mil From ipsec-request@ans.net Tue Aug 15 11:22:44 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14589 (5.65c/IDA-1.4.4 for ); Tue, 15 Aug 1995 15:28:32 -0400 Received: by interlock.ans.net id AA21519 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 15 Aug 1995 15:22:50 -0400 Message-Id: <199508151922.AA21519@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 15 Aug 1995 15:22:50 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 15 Aug 1995 15:22:50 -0400 Date: Tue, 15 Aug 95 15:22:44 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) To: ipsec@ans.net Subject: Comments on IPSO and AH/ESP [my co-chair hat is off :-] IPsec folks, % And in fact, not only CAN they be configured to mess with IPSO, % CISCO's are shipped with a DEFAULT behaviour that allows only % unclassified BSO traffic thru. To allow other IPSO (of the RFC1108 % flavor) thru you have to jump thru hoops to figure out how to % configure the routers. And to this day I am not sure how to do that. Folks at NRL and other parts of the DoD do know how to do it. It isn't THAT hard to do. Also, by default a Cisco will pass traffic without any IPSO label whatsoever. The key thing is that no router will by default munge any IPSO labels -- IPSO munging is something that the router admin must specifically turn on and configure in each router. % The filtering of packets that do not meet a set of configured criteria, % such as the above, is an extreme case of (perhaps inappropriate) behaviour % on the part of a router, that can lead to connectivity problems. It relates % only tangentially to the more general isues of: % a) Whether IPSO options should/may be modified by any router % b) Whether IPSO options should be part of the authentication stream % c) Whether the IPSO options should be included at all % The answer to (a) is yes in the most common deployed MLS (multi-level % security) configurations that I am aware of. In this case, however, % the "router" in question is really an MLS gateway between networks % with differing security policies. It could, potentially, be something like % a CISCO configured to filter and add IPSO appropriately, but will often % be a B1 or B1/CMW or B2 evaluated MLS system. A configuration might % look something like this: Note: IPSO is strictly an IPv4 option. There is currently no analogous option for IPv6. Ditto for CIPSO at present. I agree that it is not uncommon. It is widely viewed within the DoD as being a "least of all evils". Many in the DoD believe that using unauthenticated IPSO labels to perform Mandatory Access Controls for security is highly undesirable because of the security risk. I personally dislike IPSO labels for that latter reason and because they advertise "this packet is a high-value target, see the IPSO label". One of the goals of the IPsec WG from long ago was to be able to authenticate IPSO labels from source to destination, thus potentially permitting a filtering router with a MAC policy to authenticate the label to provide assurance that the MAC policy was implemented as intended and was not being spoofed. % In this case, the single level systems are assumed to be non-MLS systems % which generate and expect traffic with no IPSO. The MLS gateways add % IPSO with the appropriate classification and compartments before % putting it on the WAN. They strip the IPSO before forwarding packets % to the single level networks. They do the above only when the sys/net admin wants that done as part of policy. More often in my experience, unlabeled packets are sent, no router mangling occurs, and unlabeled packets are implicitly treated as "unclassified". The multi-level systems generally do include IPSO labels with the label reflecting the level of the data in the packet. % The MLS gateway 3 probably just passes the IPSO on unmodified but here % there are also cases where the IPSO could be changed to reflect differing % policies. A case in point might be where the WAN has routers that only % pass RFC1108 BSO IPSO. In that case the ESO (compartments) would be % dropped before going out on the WAN. Again, these are LOCAL policies. If users wish to shoot themselves in the foot, no RFC will prohibit that. But if they want to use AH with the labels, they won't want or need to configure the routers to munge IPSO options. % The WAN is assumed to be reliably authenticated, possibly encrypted, % and physically secure data link. It is always encrypted, with either a link encryptor or an IP encryptor, but never in my experience has per-packet authentication (which authentication IS needed and currently missing and is something AH ought to be providing). % The caveat here of course would be that it is unlikely that highly % classified data would be routed over the big bad Internet... Yes. Certainly it is never sent without military-grade encryption being used, typically with SP3D as the encapsulation protocol if IP encryption is in use. % 1) The endpoint systems are IPv6 security aware (but not necessarily % MLS) and do end-to-end authentication. Here, the answer is obviously % that the IPSO CANNOT be part of the authentication stream, since the % MLS gateways will be adding, stripping or possibly modifying them. Typo: Substitute "IPv4" above where it says "IPv6". IPSO is ONLY IPv4. I would contradict this directly and say that it is obvious that IPSO MUST be authenticated in order to prevent spoofing attacks and false downgrading of information. I am aware of major router vendorS that report are implementing AH for IPv4 (I can't say which ones, sorry). There are MANY users and a few good vendors who want to have routers authenticate but not modify IPSO labels. If IPSO is included in the AH computation, this desirable goal will almost certainly come to pass. If IPSO is excluded from the AH computation, this will definitely be precluded. The community is definitely on a major decision point here. % This presents a problem to the gateways in that IPSO coming from % the WAN cannot be authenticated and cannot be used reliably for % routing/filtering decisions. % 2) The endpoint systems use unauthenticated IPv6 (or IPv4) possibly % with IPSO in the case of the multi-level network. In this case % the MLS gateways would add the authentication. No. The IPv6 end systems will use authenticated or encrypted packets and will include the security level as part of the Security Association data as the specs already make clear and will NOT use IPSO [IPSO is for IPv4 only in any event. Please go read the spec language about implicit labeling being "must implement". IPv4 systems SHOULD use authentication and add their own labels. It is likely that future DoD contracts (e.g. Navy's TAC-5, worth a few Billion $) will make support for authenticated IPSO labels a "must implement in hosts if you want to bid" item. In the past, vendors have implemented new features of similar complexity in order to bid on large DoD contracts (e.g. TAC-3, TAC-4). % In this case, if we assume the routers on the WAN do not muck % with the IPSO, the IPSO could and probably should be part of the % authentication stream. This gives us assurance that the IPSO is what % it says it is, but it still has the well-known flaw of putting up the % bright red flag that says this secured data worthy of analysis. % 3) We attempt to use the Security Association features of the % authentication mechanism. If the S/A is strictly end-to-end % (is this TRUE?), then the answer is simple. The endpoint % systems (even the single level ones in my diagram) become MLS aware % to the extent that the S/A has an implied senstivity level. The MLS % gateways become simple routers, since they are presumably no privy % to the S/A and cannot make routing decisions based on the % sensitivity level. IMHO, this is the best approach, particularly if we use encryption rather than authentication. For MLS, one really wants encryption to separate the different security levels. % Number (3) provides the best security and it works for deployment of % new programs with endpoint systems that use the latest technology. % Unfortunately, in my experience, that is rarely the case. Usually, % there is a VERRRYYYY long lag time between program inception and % actual deployment and once deployed it is extremely difficult to % inject updates. Systems that can't be updated will be forced to not use ANY of the IPsec mechanisms by the same reasoning that you use in the paragraph above. For them there will be no change in the status quo. % I suspect that the answer will probably be encapsulation, as % suggested by Hillarie. I am not completely sure how works in gory % detail, but seems to be the only real answer in this type of % configuration. One obvious problem with encapsulation is that if IPSO is in the inner packet, it can't easily be examined by the routers to perform filtering as routers do right now. This means the same interoperability issues with the status quo will also exist in this case. It is really important to understand that IPSO is almost never used outside of military networks and is almost never used within The Internet. Within those military networks, the network operator has fairly total control over how the network and its routers are configured. So if they don't want to use AH or ESP, they simply decide not to use it. The specs as agreed to and as published are and always were intended to provide end2end authentication of the entire IP packet, not just the upper-layer data portion as Bill as recently misstated. I don't think it is hard to implement the specs as written and suggest perusal of the code I announced earlier today before we continue that line of discussion, if we do. Now as a process comment, the specs are out as Proposed Standard and the usual IETF way is that the next 6 months or so will be spent implementing and testing interoperability. After that period, the WG will be asked to consider moving the specs to Draft Standard. At that point the WG can alter/amend/clarify the specs as WG consensus dictates and subject, as always, to IESG approval. As document editor, I _will_ edit the documents in accordance with WG consensus, as best the co-chairs and Security AD can determine it, even if I personally disagree with the changes. NRL is ready to do interoperability testing for IPv4 or IPv6 AH or ESP today. Mind, our implementation is per the Proposed Standard RFCs. If you want to test, send me email and we can arrange something. Ran rja@cs.nrl.navy.mil employed by, but not speaking officialy for the US Naval Research Laboratory From ipsec-request@ans.net Tue Aug 15 20:14:33 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12994 (5.65c/IDA-1.4.4 for ); Tue, 15 Aug 1995 16:19:54 -0400 Received: by interlock.ans.net id AA37578 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 15 Aug 1995 16:14:39 -0400 Message-Id: <199508152014.AA37578@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 15 Aug 1995 16:14:39 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 15 Aug 1995 16:14:39 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 15 Aug 1995 16:14:39 -0400 From: Sean O'Malley Subject: Re: Comments on IPSO and AH/ESP To: atkinson@itd.nrl.navy.mil (Ran Atkinson) Date: Tue, 15 Aug 1995 13:14:33 -0700 (MST) Cc: ipsec@ans.net In-Reply-To: <199508151922.AA21519@interlock.ans.net> from "Ran Atkinson" at Aug 15, 95 03:22:44 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 844 > One obvious problem with encapsulation is that if IPSO is in the inner > packet, it can't easily be examined by the routers to perform > filtering as routers do right now. This means the same > interoperability issues with the status quo will also exist in this > case. > Why not have the IPSO option appear in BOTH IP headers. The encapsulated one to be signed and the real IP header to be looked at by the router. Now someone could change the IPSO in the real header so that the router would do something unnatural to it but unless you are expecting the router to understand IPSEC and authenticate the header (which requires that it know about IPSEC anyway and hence could compare the copies of the IPSO fields to see if they match) this is not an issue. At this point saving bits are the least of our problems. Sean O'Malley From ipsec-request@ans.net Tue Aug 15 22:53:26 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12949 (5.65c/IDA-1.4.4 for ); Tue, 15 Aug 1995 18:04:57 -0400 Received: by interlock.ans.net id AA58232 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 15 Aug 1995 17:59:35 -0400 Message-Id: <199508152159.AA58232@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 15 Aug 1995 17:59:35 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 15 Aug 1995 17:59:35 -0400 To: Hilarie Orman Cc: ipsec@ans.net Subject: Re: Field Variance Analysis In-Reply-To: Your message of "Mon, 14 Aug 1995 19:58:10 MST." <9508150258.AA04859@uncial.CS.Arizona.EDU> Date: Tue, 15 Aug 1995 17:53:26 -0500 From: Craig Metz In message <9508150258.AA04859@uncial.CS.Arizona.EDU>, Hilarie Orman writes: >> The third is one that many people discount, claiming that IPSO is >> just broken and shouldn't be a factor. I'm not here to judge IPSO, but >> certain government organizations have a large IPSO deployed base and they >> won't buy into IPsec at all if it leaves them SOL with IPSO. Both the second >> and third on this list implies no alternative but to protect IPv4 options >> if we are going to defend against these attacks. If we aren't going to >> defend against these attacks, then we can talk in terms of not authenticatin >> options. > >Might not the certain government organizations use encapsulation with >a MD5 transform as a method of protecting the IPSO? If we choose not to protect IPv4 options, then it is possible for those organizations to use IP-IP tunneling with AH on the outside packet and the IPSO option on the inside (tunnelled) packet, except that this will defeat the purpose of IPSO because routers will only look at the outside packet. So, in order to provide intermediate IPSO processing (and IPSO is meant to be used by intermediate glorified-routers to make policy decisions), we have no reasonable choice but to find a way to authenticate IPv4 options. -Craig From ipsec-request@ans.net Tue Aug 15 22:58:56 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15508 (5.65c/IDA-1.4.4 for ); Tue, 15 Aug 1995 18:04:57 -0400 Received: by interlock.ans.net id AA40577 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 15 Aug 1995 17:59:41 -0400 Message-Id: <199508152159.AA40577@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 15 Aug 1995 17:59:41 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 15 Aug 1995 17:59:41 -0400 To: perry@piermont.com Cc: ipsec@ans.net Subject: Re: Field Variance Analysis In-Reply-To: Your message of "Mon, 14 Aug 1995 23:08:10 -0400." <199508150308.XAA23251@panix4.panix.com> Date: Tue, 15 Aug 1995 17:58:56 -0500 From: Craig Metz In message <199508150308.XAA23251@panix4.panix.com>, "Perry E. Metzger" writes: > >Craig Metz writes: >> Again, this is a design question. I can predict that if I send a >> packet over our routers, it will either get there with its options >> the same way I sent them or it will get dropped because our filter got it. >> We have Cisco routers. It just happens that we don't have configurations >> on our routers that cause them to go munging packets. For that matter, >> Bill, I've never seen a site in my entire life that has a router that >> messes with IPv4 options on a packet in transit. Maybe they're more >> common in your environment. > >I recall that you were mentioning IPSO. I seem to vaguely remember >that CISCOs can be set to add IPSO tags to outgoing packets. This >would seem to be something that could screw things up. Anyone recall >if this is the case? Cisco routers can add IPSO options to outgoing packets. Question: Can they *remove* IPSO options from incoming packets? If you set your network up to symmetrically add and remove the options, the reciever receives the intended packet.. assuming that the sender didn't send an IPSO packet. The right solution is that IPSO options be sent by the sender if they're used at all. An even more right solution, of course, might be to use implicit labels as part of the security association, but this is something we don't quite yet have the technology to do (this becomes an easier case of the intermediate network authentication problem). But if your operational network has routers that take packets from hosts that never add IPSO and adds IPSO to them (which I believe is the common case subset of this already rather pathological case), then a solution is to have the routers strip them before receipt by the sender. I believe that IP-IP tunneling can also be used creatively to get around problems where routers muck with IPv4 options. Routers can muck all they want with the outside packet and the inside packet stays intact end-to- end. This MIGHT provide a reasonable solution for many cases. Compare with proposals to IP-IP tunnel if you have any IPv4 options. This shifts the extra overhead to the less common case, IMO. -Craig From ipsec-request@ans.net Tue Aug 15 23:03:33 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14541 (5.65c/IDA-1.4.4 for ); Tue, 15 Aug 1995 18:08:40 -0400 Received: by interlock.ans.net id AA44859 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 15 Aug 1995 18:04:56 -0400 Message-Id: <199508152204.AA44859@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 15 Aug 1995 18:04:56 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 15 Aug 1995 18:04:56 -0400 To: perry@piermont.com Cc: ipsec@ans.net Subject: Re: Field Variance Analysis In-Reply-To: Your message of "Tue, 15 Aug 1995 09:36:06 -0400." <199508151336.JAA04440@panix4.panix.com> Date: Tue, 15 Aug 1995 18:03:33 -0500 From: Craig Metz In message <199508151336.JAA04440@panix4.panix.com>, "Perry E. Metzger" writes: >Hilarie Orman writes: >> > The third is one that many people discount, claiming that IPSO is >> > just broken and shouldn't be a factor. I'm not here to judge IPSO, >> > but certain government organizations have a large IPSO deployed >> > base and they won't buy into IPsec at all if it leaves them SOL >> > with IPSO. Both the second and third on this list implies no >> > alternative but to protect IPv4 options if we are going to defend >> > against these attacks. If we aren't going to defend against these >> > attacks, then we can talk in terms of not authenticating options. >> >> Might not the certain government organizations use encapsulation with >> a MD5 transform as a method of protecting the IPSO? > >I believe that Hilarie has hit on the way to cut the gordian knot. If >the originating system wants to protect options under IPv4, it >probably should encapsulate the whole packet and not just the >transport. Consider the goal of protecting source routes. If you do things this way, you would build a packet of (my notation may be wierd to some): IPv4 AH IPv4 LSRR ULP You have two options. You either don't do the LSRR, in which case having it there in the first place is a waste, or you only get intermediate authenticity guarantees because each hop has to decapsulate it and re- encapsulate it, doing the appropriate AH processing on each operation. Keep in mind my second example in part 1. You can't get end-to-end LSRR security and have the LSRR do something useful using a tunnel, IMO. -Craig From ipsec-request@ans.net Tue Aug 15 23:15:59 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14046 (5.65c/IDA-1.4.4 for ); Tue, 15 Aug 1995 18:21:07 -0400 Received: by interlock.ans.net id AA09137 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 15 Aug 1995 18:16:08 -0400 Message-Id: <199508152216.AA09137@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 15 Aug 1995 18:16:08 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 15 Aug 1995 18:16:08 -0400 To: Andy Bayerl Cc: ipsec@ans.net Subject: Re: Field Variance Analysis In-Reply-To: Your message of "Tue, 15 Aug 1995 10:51:15 -0400." <199508151458.AA06122@interlock.ans.net> Date: Tue, 15 Aug 1995 18:15:59 -0500 From: Craig Metz In message <199508151458.AA06122@interlock.ans.net>, Andy Bayerl writes: > Craig metz writes: > I recall that you were mentioning IPSO. I seem to vaguely remember > that CISCOs can be set to add IPSO tags to outgoing packets. This > would seem to be something that could screw things up. Anyone recall > if this is the case? >The filtering of packets that do not meet a set of configured criteria, >such as the above, is an extreme case of (perhaps inappropriate) behaviour >on the part of a router, that can lead to connectivity problems. It relates >only tangentially to the more general isues of: IMO, it is inappropriate, but this depends on your view of things. > a) Whether IPSO options should/may be modified by any router > b) Whether IPSO options should be part of the authentication stream > c) Whether the IPSO options should be included at all > >The answer to (a) is yes in the most common deployed MLS (multi-level >security) configurations that I am aware of. In this case, however, >the "router" in question is really an MLS gateway between networks >with differing security policies. It could, potentially, be something like >a CISCO configured to filter and add IPSO appropriately, but will often >be a B1 or B1/CMW or B2 evaluated MLS system. A configuration might >look something like this: > > Unclassified Classified > Single Level ---+ MLS +---+ WAN +---+ MLS +---+ Single Level > Network Gateway 1 + Gateway 2 Network > | > | > | > + > MLS +-----+ Multi-level > Gateway 3 Network > >In this case, the single level systems are assumed to be non-MLS systems >which generate and expect traffic with no IPSO. The MLS gateways add >IPSO with the appropriate classification and compartments before >putting it on the WAN. They strip the IPSO before forwarding packets >to the single level networks. For single-level to single-level, IPSO is stripped, end of problem. For single-level to multi-level, tunneling seems reasonable to me. > 1) The endpoint systems are IPv6 security aware (but not necessarily > MLS) and do end-to-end authentication. Here, the answer is obviously > that the IPSO CANNOT be part of the authentication stream, since the > MLS gateways will be adding, stripping or possibly modifying them. > > This presents a problem to the gateways in that IPSO coming from > the WAN cannot be authenticated and cannot be used reliably for > routing/filtering decisions. Luckily, there is no IPSO in IPv6, so this isn't a problem. If you mean that they have IPv4 AH, then you can strip (single-level to single-level) or tunnel (any combination of MLS). The latter packet would be: IPv4 IPSO IPv4 AH ULP > 2) The endpoint systems use unauthenticated IPv6 (or IPv4) possibly > with IPSO in the case of the multi-level network. In this case > the MLS gateways would add the authentication. > > (NOTE: I am assuming that this is possible. Can someone please > tell me if it is so?) IPv4, yes. IPv6, no. > In this case, if we assume the routers on the WAN do not muck > with the IPSO, the IPSO could and probably should be part of the > authentication stream. This gives us assurance that the IPSO is what > it says it is, but it still has the well-known flaw of putting up the > bright red flag that says this secured data worthy of analysis. In which case use with ESP might be in order... > 3) We attempt to use the Security Association features of the > authentication mechanism. If the S/A is strictly end-to-end > (is this TRUE?), then the answer is simple. The endpoint > systems (even the single level ones in my diagram) become MLS aware > to the extent that the S/A has an implied senstivity level. The MLS > gateways become simple routers, since they are presumably no privy > to the S/A and cannot make routing decisions based on the > sensitivity level. Security associations are currently end-to-end but can be used for intermediate network authentication. The intermediate network authentication part allows one to use asymmetric cryptography to create case where the routers/gateways can verify that a packet is authentic and belongs to a certain security association (and they can thusly make policy decisions based on the implied labels) without being able to forge packets. The pieces aren't all in place yet for intermediate network authentication, though. >Number (3) provides the best security and it works for deployment of new >programs with endpoint systems that use the latest technology. Unfortunately, >in my experience, that is rarely the case. Usually, there is a VERRRYYYY >long lag time between program inception and actual deployment and once >deployed it is extremely difficult to inject updates. Implicit security labels, IMO, have a number of important benefits over IPSO. But we have IPSO in use right now, and we have no AH implicit security labels in use right now. >I suspect that the answer will probably be encapsulation, as suggested by >Hillarie. I am not completely sure how works in gory detail, but seems >to be the only real answer in this type of configuration. For single-level to single-level, stripping makes more sense to me. Involve a MLS box, and encapsulation for this case as I explained above seems more reasonable. -Craig From ipsec-request@ans.net Tue Aug 15 22:39:38 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14600 (5.65c/IDA-1.4.4 for ); Tue, 15 Aug 1995 18:45:56 -0400 Received: by interlock.ans.net id AA14114 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 15 Aug 1995 18:40:29 -0400 Message-Id: <199508152240.AA14114@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 15 Aug 1995 18:40:29 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 15 Aug 1995 18:40:29 -0400 X-Authentication-Warning: frankenstein.piermont.com: Host localhost didn't use HELO protocol From: perry@piermont.com To: Craig Metz Cc: ipsec@ans.net Subject: Re: Field Variance Analysis In-Reply-To: Your message of "Tue, 15 Aug 1995 18:03:33 CDT." <9508152303.aa07453@cs.nrl.navy.mil> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 15 Aug 1995 18:39:38 -0400 Sender: perry@frankenstein.piermont.com Craig Metz writes: > >I believe that Hilarie has hit on the way to cut the gordian knot. If > >the originating system wants to protect options under IPv4, it > >probably should encapsulate the whole packet and not just the > >transport. > > Consider the goal of protecting source routes. I'm not sure there is a point to protecting source routes. Consider the following: 1) The worst the attacker can do is force you to use a different route than the intended one. He can force you to reply on a reversed bad source route and can read your messages and keep the intended recipient from reading them. However, if he's an active attacker in the line he can do that anyway. 2) We can't authenticate to intermediate nodes so the only thing the machine on the end knows is what source route options the packet was sent with, *not* what path it took. Authentication makes source routing safe not because it makes the source routes themselves immune from attack but because it authenticates the endpoints. Perry From ipsec-request@ans.net Tue Aug 15 10:59:41 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13906 (5.65c/IDA-1.4.4 for ); Tue, 15 Aug 1995 21:30:23 -0400 Received: by interlock.ans.net id AA42299 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 15 Aug 1995 21:26:46 -0400 Message-Id: <199508160126.AA42299@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 15 Aug 1995 21:26:46 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 15 Aug 1995 21:26:46 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 15 Aug 1995 21:26:46 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 15 Aug 1995 21:26:46 -0400 Date: Tue, 15 Aug 95 17:59:41 PDT From: chandras@loc201.tandem.com (srivastava_chandra) To: wford@bnr.ca Subject: IETF PKI WG mailing list Cc: PEM-swc@tis.com, cat-ietf@mit.edu, ipsec@ans.net, e-payments@cc-bellcore.loc201.tandem.com, www-securities@ns2.rutgers.edu, ietf-payments@cc.bellcore.com, pki-twg@nist.gov, ietf-ids@umic.edu If you want to subscribe to the IETF PKIX mailing list, please send a message to listserv@tandem.com with the following in the message body: subscribe ietf-pkix Your can omit in the message, if you are sending the message from the same address that you want to put in the mailing list. The reason I am sending this message is because lot of people are sending the subscription request to ietf-pkix@tandem.com, which will not put them in the mailing list and I have received complaints. Regards Chandra Srivastava From ipsec-request@ans.net Wed Aug 16 22:47:26 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15950 (5.65c/IDA-1.4.4 for ); Wed, 16 Aug 1995 22:47:26 -0400 Received: by interlock.ans.net id AA17788 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 16 Aug 1995 22:30:37 -0400 Message-Id: <199508170230.AA17788@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 16 Aug 1995 22:30:37 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 16 Aug 1995 22:30:37 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 16 Aug 1995 22:30:37 -0400 Date: Wed, 16 Aug 95 19:07:49 From: "Housley, Russ" Encoding: 426 Text To: ipsec@ans.net, atkinson@itd.nrl.navy.mil (Ran Atkinson) Subject: Re: Comments on IPSO and AH/ESP Ran: I really like the idea of an implicit security label. The security association can be established for one particular security label. Multi-level systems simply establish multiple security associations, protected in different keys (and maybe different algorithms), one for each label. This way, all of the overhead associated with labels falls on the key management protocol, not each datagram. Russ From ipsec-request@ans.net Wed Aug 16 19:04:06 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA16307 (5.65c/IDA-1.4.4 for ); Wed, 16 Aug 1995 23:31:01 -0400 Received: by interlock.ans.net id AA63597 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 16 Aug 1995 23:15:14 -0400 Message-Id: <199508170315.AA63597@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 16 Aug 1995 23:15:14 -0400 From: smb@research.att.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 16 Aug 1995 23:15:14 -0400 To: "Housley, Russ" Cc: ipsec@ans.net, atkinson@itd.nrl.navy.mil (Ran Atkinson) Subject: Re: Comments on IPSO and AH/ESP Date: Wed, 16 Aug 95 23:04:06 EDT Ran: I really like the idea of an implicit security label. The security association can be established for one particular security label. Multi-level systems simply establish multiple security associations, protected in different keys (and maybe different algorithms), one for each label. This way, all of the overhead associated with labels falls on the key management protocol, not each datagram. Russ That's certainly my preference as well. From ipsec-request@ans.net Thu Aug 17 12:11:51 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12810 (5.65c/IDA-1.4.4 for ); Thu, 17 Aug 1995 08:20:40 -0400 Received: by interlock.ans.net id AA12541 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 17 Aug 1995 08:15:19 -0400 Message-Id: <199508171215.AA12541@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 17 Aug 1995 08:15:19 -0400 From: Ran Atkinson Date: Thu, 17 Aug 1995 08:11:51 -0400 In-Reply-To: "Housley, Russ" "Re: Comments on IPSO and AH/ESP" (Aug 16, 19:07) References: <9507168086.AA808625269@spysouth.spyrus.com> Reply-To: rja@cs.nrl.navy.mil X-Mailer: Z-Mail (3.2.1 10apr95) To: "Housley, Russ" , ipsec@ans.net Subject: Re: Comments on IPSO and AH/ESP Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: rja@bodhi.cs.nrl.navy.mil Russ, I personally could not agree more that implicit security labels are the better way to go. The recently published Proposed Standard RFCs actually require that systems claiming to provide MLS features MUST implement support for implicit labels. NRL's (otherwise single-level) implementation for 4.4 BSD supports implicit labels. For that matter, I think that data at different security levels ought to use encryption to provide separation of data (DES encryption is vastly better than no encryption, IMHO, though the military will no doubt use Type 1 algorithms instead of DES). Reality is that there are folks (primarily TSIG/CIPSO people and those who have been strongly influenced by them) who will continue using explicit labels. It would be significant risk reduction to authenticate such IPSO (or CIPSO, though that is neither standard nor widely interoperable [we run multi-vendor tests of this once in a while] or well documented) labels end-to-end using AH, hence my concern that IPSO be included in the AH computation (as the Proposed Standard RFCs already require). Thanks for your note. Regards, Ran rja@cs.nrl.navy.mil From ipsec-request@ans.net Thu Aug 17 13:53:26 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14586 (5.65c/IDA-1.4.4 for ); Thu, 17 Aug 1995 10:08:02 -0400 Received: by interlock.ans.net id AA55397 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 17 Aug 1995 10:01:46 -0400 Message-Id: <199508171401.AA55397@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 17 Aug 1995 10:01:46 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 17 Aug 1995 10:01:46 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 17 Aug 1995 10:01:46 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 17 Aug 1995 10:01:46 -0400 To: rja@bodhi.nrl.navy.mil Cc: ipsec@ans.net Subject: Re: Comments on IPSO and AH/ESP In-Reply-To: Your message of "Thu, 17 Aug 95 08:11:51 EDT." <199508171215.AA12541@interlock.ans.net> Date: Thu, 17 Aug 95 09:53:26 -0400 From: Andy Bayerl X-Mts: smtp Ran Writes: Reality is that there are folks (primarily TSIG/CIPSO people and those who have been strongly influenced by them) who will continue using explicit labels. Being one of those *TSIG/CIPSO people*, it is MHO that in the IPv6 world we will use implicit labelling unless for some reason it proves to be unworkable. I cannot speak for all TSIG vendors, but I believe that our Digital MLS+ products would most certainly make every attempt to use it. From everything that has been said, it is quite obviously the most secure mechanism available and given that it is a *must implement*, it will be the most widely available and I see no reason why any MLS vendor with IPv6 would not take advantage of it. Of course, in the IPv4 world we will still continue to use (C)IPSO since we have no choice. That wouldn't seem to be related to this discussion (unless IPv4 tunnelled thru IPv6 comes into play, but I don't think so.) The only concern I have is how the notion of the implied labelling scales to networks with a large number of compartments where the number of *potential* labels increases exponentially. Your model assumes a small number of classifications (which scales linearly) and a small comparment set. The solution may be simply a matter of using a subset of the compartments for network labelling or restricting the number of active security associations with different labels between any 2 end points. We will need to keep this in mind when we get around to discussions of how the S/A's are managed. It would be significant risk reduction to authenticate such IPSO (or CIPSO, though that is neither standard nor widely interoperable [we run multi-vendor tests of this once in a while] or well documented) labels end-to-end using AH, hence my concern that IPSO be included in the AH computation (as the Proposed Standard RFCs already require). If we assume that vendors will be able to use the implied S/A labelling, then whether or not (C)IPSO labels are authenticated may be moot. If a vendor chooses to stick with IPSO then not authenticating is certainly no worse than IPv4 and would give an incentive to using the S/A labelling. I don't think I have a strong opinion one or the other. BTW: Most MLS vendors that I know about support CIPSO. Sun and Sequent are the only exceptions I know about and I think Sun is working on it. I can't speak to how well it is documented by individual vendors and how easily configurable it is for other vendors. From the Digital perspective it is easily configurable in all of our MLS+ 3.x releases. The CIPSO specifications are accessible in the TSIG archives. (I do not want to get into a discussion of why it is not an RFC, since that predated my involvement and I would rather let it lie.) /andy From ipsec-request@ans.net Thu Aug 17 14:55:02 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA16229 (5.65c/IDA-1.4.4 for ); Thu, 17 Aug 1995 11:03:53 -0400 Received: by interlock.ans.net id AA26295 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 17 Aug 1995 10:57:00 -0400 Message-Id: <199508171457.AA26295@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 17 Aug 1995 10:57:00 -0400 From: Ran Atkinson Date: Thu, 17 Aug 1995 10:55:02 -0400 Reply-To: rja@cs.nrl.navy.mil X-Mailer: Z-Mail (3.2.1 10apr95) To: ipsec@ans.net Subject: Re: Comments on IPSO and AH/ESP Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: rja@bodhi.cs.nrl.navy.mil Andy, Thanks for your note. I'm pleased to hear that we share somewhat similar views on security labeling. [BEGIN ASIDE: My hangup with CIPSO interoperability is that different vendors have implemented different subsets of the possible "tag types". So if vendor A has implemented one subset, vendor B has implemented a slightly different subset, and vendor C has implemented a third slightly different subset of the tag types -- then users have a hard time getting all 3 kinds of systems talking (in some cases, we can't find a tag type that has been implemented by all of the systems that we are trying to get to talk with each other). A _vast_ improvement would be to require that all vendors implement at least one or two of the tag types so that users could at least be able to buy a CIPSO system and know that it is possible to get it to talk with a CIPSO system from any arbitrary different vendor. That, regrettably, is not true today, though it could be true in the future. I agree the TSIG/IETF history is best left aside at this point. END ASIDE] Your inputs/advice on how to ensure that a Security Association's Implicit Label is flexible enough to meet MLS needs would be most welcome. Its highly desirable that the Internet community get this right and your experience could well help us avoid some pitfalls. I had been hoping there would be more discussion of this in the context of NSA's ISA/KMP draft, but there hasn't been a lot of discussion of security association mgmt just yet. Regards, Ran rja@cs.nrl.navy.mil From ipsec-request@ans.net Sat Aug 19 09:34:28 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA16062 (5.65c/IDA-1.4.4 for ); Sat, 19 Aug 1995 05:41:39 -0400 Received: by interlock.ans.net id AA39827 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 19 Aug 1995 05:35:50 -0400 Message-Id: <199508190935.AA39827@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Sat, 19 Aug 1995 05:35:50 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 19 Aug 1995 05:35:50 -0400 From: Germano Caronni Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 19 Aug 1995 05:35:50 -0400 Subject: Re: SKIP (Security on the IP Layer) Sources [OOPS] (fwd) To: ipsec@ans.net, chris@phil15.uni-sb.de, roessler@sobolev.rhein.de, rmuchsel@iiic.ethz.ch, lubich@tik.ee.ethz.ch (Hannes Lubich), plattner@tik.ee.ethz.ch (Bernhard Plattner), maurer@inf.ethz.ch, almesber@di.epfl.ch, freeskip@incog.com, boyns@sdsu.edu, guru@arl.wustl.edu, etter@tik.ee.ethz.ch (Felix Etter), wilde@tik.ee.ethz.ch (Erik Wilde), bauer@tik.ee.ethz.ch (Daniel Bauer), gutekuns@tik.ee.ethz.ch (Thomas Gutekunst) Date: Sat, 19 Aug 1995 11:34:28 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24 PGP5a] Content-Type: text Content-Length: 6464 Alan Cox wrote: > From: iialan@iifeak.swan.ac.uk (Alan Cox) > Subject: Re: SKIP (Security on the IP Layer) Sources > This is ENskip, pre-alpha 0.10. ENskip is a security module for the TCP/IP > stack. It provides encryption, authentication and sequencing of packets on [...] Well RMS will probably dislike your license which effectively is a derivative work of the GLPL and thus quite possibly a copyright violation in itself, and I can't use the code with the Linux kernel with its present license. [...] sigh. The fact is that we want nobody to actually *use* this pre-alpha version in a productive environment. At the moment you can play around with it, enhance it or familiarize yourself with SKIP. It is definitively too early for using it in something commercial, or let it be used by 'security-unaware' people. Also we had the problem that neither the Gnu License nor the Gnu Library License (IMHO) fully fitted the concept of a loadable kernel module. Thus we put something together which really is closely related to the Library License, but is somewhat simpler. I really would like to hear your opinion if this license is illegal, and in what points it is too incompatible with the GPLL. Should we revert back to a pure GPLL? Wouldn't this give problems in SKIP over Irix, Solaris and NeXTstep? Please give me a hint, I really hate this legalese stuff, and would happily accept an easy solution! Germano p.s. here the text which caused the hassle: ENskip Public License ===================== This is the ENskip public License, strongly influenced by the GNU Library License V 2.0. Whenever the ENskip License does not address a certain point, you may feel free to act according to the GNU Library License V 2.0 or, at your wish, any later version. 1. You may copy and distribute verbatim copies of ENskip's complete source code as you receive it, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with ENskip. 2. You may not charge any fee for the distribution of ENskip, other than a reasonable amount to compensate for the physical act of transferring a copy. 3. You may modify your copy or copies of ENskip or any portion of it, thus forming a work based on ENskip, and copy and distribute such modifications or work under the terms of this License, provided that you cause the files modified to carry prominent notices stating that you changed the files and the date of any change. You are encouraged to notify the authors of ENskip (skip@tik.ee.ethz.ch) about your changes. 4. You may copy and distribute ENskip or a derivative of it, under the condition that you accompany it with the complete corresponding machine- readable source code, which must be distributed under the terms of this License, or point to a place where the person receiving your distribution of ENskip may reliably receive the machine-readable source code without additional costs other than a reasonable amount for the actual transfer of the data. If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. 5. A program that contains no derivative of any portion of ENskip, but is designed to work with ENskip by interacting with its run-time components, is called a "work that uses ENskip". Such a work, in isolation, is not a derivative work of the ENskip, and therefore falls outside the scope of this License. 6. You may not copy, modify, sublicense, execute, use, or distribute ENskip except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, execute, use, or distribute ENskip is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 7. Each time you redistribute ENskip (or any work based on ENskip), the recipient automatically receives a license from the original licensor to copy, distribute, execute, use or modify ENskip subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. 8. Commercial exploitation of a product based on this work or a derivative of it except as provided by section 5) of this License is expressly forbidden unless you receive written consent by the copyright holders of this work. They are reachable via or Swiss Federal Institute of Technology TIK / Germano Caronni CH-8092 Zuerich / Switzerland NO WARRANTY BECAUSE ENskip IS PROVIDED FREE OF CHARGE, THERE IS NO WARRANTY FOR THIS PACKAGE. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PACKAGE "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PACKAGE IS WITH YOU. SHOULD THE PACKAGE PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. IN NO EVENT WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PACKAGE AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PACKAGE (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PACKAGE TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. -- <...cookie space for rent...> Germano Caronni caronni@tik.ee.ethz.ch http://www.tik.ee.ethz.ch/~caronni PGP-Key-ID:7B7AE5E1 997C6DC4AF930A5D2D5D6AEAA196C33B From ipsec-request@ans.net Sat Aug 19 20:26:33 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12894 (5.65c/IDA-1.4.4 for ); Sat, 19 Aug 1995 15:33:29 -0400 Received: by interlock.ans.net id AA30800 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 19 Aug 1995 15:28:53 -0400 Message-Id: <199508191928.AA30800@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 19 Aug 1995 15:28:53 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 19 Aug 1995 15:28:53 -0400 To: Sean O'Malley Cc: ipsec@ans.net Subject: Re: Comments on IPSO and AH/ESP In-Reply-To: Your message of "Tue, 15 Aug 1995 13:14:33 MST." <199508152014.AA37578@interlock.ans.net> Date: Sat, 19 Aug 1995 15:26:33 -0500 From: Craig Metz In message <199508152014.AA37578@interlock.ans.net>, Sean O'Malley writes: >> One obvious problem with encapsulation is that if IPSO is in the inner >> packet, it can't easily be examined by the routers to perform >> filtering as routers do right now. This means the same >> interoperability issues with the status quo will also exist in this >> case. >Why not have the IPSO option appear in BOTH IP headers. The >encapsulated one to be signed and the real IP header to be >looked at by the router. Now someone could change the IPSO >in the real header so that the router would do something >unnatural to it but unless you are expecting the router to >understand IPSEC and authenticate the header (which requires >that it know about IPSEC anyway and hence could compare the >copies of the IPSO fields to see if they match) this is not >an issue. At this point saving bits are the least of our >problems. This seems pretty sensible to me, but it only seems to work in the case where both ends understand IPSO. If you have a single-level machine talking to a multi-level machine where the routers are adding IPSO options midstream, I don't think this solves the problem. If you built a packet at the single-level machine of the form IPv4 AH ULP, the midstream router would create IPv4 IPSO IPv4 IPSO AH ULP this way, and the inner packet would still fail authentication. After doing some thinking, it seems to me that a possible solution to the single-level to multi-level problem is to have the gateway that puts the IPSO option on the packet calculate/re-calculate the AH. This changes your security guarantee mode from end-to-end to intermediate and has unfortunate keying implications, but it seems to me that you are already putting a fairly heavy degree of trust in your router in this case in the first place, so the risk added isn't all that great. This would create this kind of configuration: [Singe-Level] [Multi-Level] BSD Box-----------Gateway-----------MLS Box IPv4 AH1 ULP IPv4 IPSO AH2 ULP (Note: AH1 = AH in key from BSD Box, AH2 = AH in key from Gateway) This might create key distribution problems, however. Proxy keying time, everyone. -Craig From ipsec-request@ans.net Sat Aug 19 20:41:00 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA04218 (5.65c/IDA-1.4.4 for ); Sat, 19 Aug 1995 15:47:46 -0400 Received: by interlock.ans.net id AA04104 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 19 Aug 1995 15:44:01 -0400 Message-Id: <199508191944.AA04104@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 19 Aug 1995 15:44:01 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 19 Aug 1995 15:44:01 -0400 To: perry@piermont.com Cc: ipsec@ans.net Subject: Re: Field Variance Analysis In-Reply-To: Your message of "Tue, 15 Aug 1995 18:39:38 -0400." <199508152239.SAA16243@frankenstein.piermont.com> Date: Sat, 19 Aug 1995 15:41:00 -0500 From: Craig Metz In message <199508152239.SAA16243@frankenstein.piermont.com>, perry@piermont.co m writes: >> Consider the goal of protecting source routes. > >I'm not sure there is a point to protecting source routes. >Consider the following: > >1) The worst the attacker can do is force you to use a different route > than the intended one. He can force you to reply on a reversed bad > source route and can read your messages and keep the intended > recipient from reading them. However, if he's an active attacker in > the line he can do that anyway. This is true. But source routing can expand the scope of who can be "in the line" in some cases. And it could create a class of annoyance attacks. Imagine a world where providers charge per unit volume and you select provider paths via source routes (this is being thought about seriously in an IPv6 scope). If some bozo can cause large volumes of your packets through Tokyo and Bangkok, they can run you up a nice bill. This can also hose quality-of-service guarantees. >2) We can't authenticate to intermediate nodes so the only thing the > machine on the end knows is what source route options the packet > was sent with, *not* what path it took. I disagree with your supposition that we can't authenticate to intermediate nodes. I believe that we do not yet have a solid grasp as to how to handle intermediate keying, but I believe that intermediate authentication is possible and, in the case of source routes, needs to be done. For now, this needs to be left for further study so that we can get something working, but I don't think we should write-off intermediate network authentication because it is a valuable topic for future work. When we start talking about things like providers charging by usage and guaranteed qualities of service, this may become especially important. >Authentication makes source routing safe not because it makes the >source routes themselves immune from attack but because it >authenticates the endpoints. I think that in the here and now, this is so. I believe that in the future, it may not be. In general, I have always held the opinion that source routes are bad and should be gotten rid of. In IPv6, it would seem reasonable to me that the flow support should be used as a stateful alternative to source routes, which would also make security processing easier. But people really do plan on using source routes, and some of the things they plan to use source routes for involve money, which means that a lot of users are going to want security guarantees for them. -Craig From ipsec-request@ans.net Mon Aug 21 01:56:40 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13050 (5.65c/IDA-1.4.4 for ); Sun, 20 Aug 1995 22:01:17 -0400 Received: by interlock.ans.net id AA48209 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 20 Aug 1995 21:56:46 -0400 Message-Id: <199508210156.AA48209@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 20 Aug 1995 21:56:46 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 20 Aug 1995 21:56:46 -0400 X-Sender: jis@e40-po.mit.edu (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 20 Aug 1995 21:56:40 -0400 To: ietf@cnri.reston.va.us, ipsec@ans.net From: jis@mit.edu (Jeffrey I. Schiller) Subject: Response to Last Call Comments for IPSEC Proposals -----BEGIN PGP SIGNED MESSAGE----- Response to Last Call Comments for IPSEC Proposals (RFC1825-RFC1829) Introduction The IPSEC documents describe a security protocol for the IP Layer of the Internet, both IPv4 and IPv6 are considered. These documents have undergone our normal working group process and have been in evolution for some years now. Shortly before the Danvers IETF (April 1995) the documents entered a period of "Working Group" Last Call. During the last call period issues were raised and the documents evolved based upon comments received. A rough consensus was reached. The consensus was rough, not all parties to the discussions completely agreed with the final forms of the documents, such is the process of compromise and negotiation. On June 22cd, the documents went to IETF last call prior to being elevated to the status of "Proposed Standard." The purpose of IETF last call is to give the community one last chance to review documents and flag fatal errors that should prevent a document from advancing. It is not a time to rehash the discussions that already took place within the context of the working group. It is not a time to recommend delaying progress in order to do a slightly better job. We did receive a significant number of comments during the last call. Many of these were supportive of the advancement of the document set to Proposed Standard. However there were some comments that recommended that we delay advancement and/or make major changes in the direction of the work. The purpose of this document is to answer those comments. Rather than address each message individually, I will address the broad category of complaints. Complaint: The IETF should not mandate confidentiality mechanisms for which vendors may have difficulty obtaining export approval from the United States (and some other countries as well). Response: This is an old complaint and one that the IESG, IAB and the IETF as a whole have addressed numerous times. The clear consensus of the community is that we must specify the best possible technologies based upon the requirements of Internet users world wide. Weakening of confidentiality in order to meet the arbitrary export requirements of some governments is not appropriate. Complaint: The document wording is ambiguous and some things could be stated better. Response: Indeed there is room for improvement in the particular wording of the documents. However the IESG believes that the documented *protocols* are sound and worthy of the implementation efforts that spawn from a Proposed Standard RFC. All five documents still have two important standardization steps to progress through ("Draft Standard" and "Full Standard"). We fully expect that the document authors, in cooperation with the working group, will take all such comments into consideration. As these documents evolve through the standards process they will likely become much better written, while still essentially documenting the same (or only slightly modified) protocols. Complaint: You didn't pick the absolute best algorithm for each function. Shortly, some new and/or better algorithms will be available. Response: In all endeavors there comes a time to "fish or cut bait." We have to make progress to provide the security services that the Internet community badly needs. No comment pointed out a fundamental flaw or security breach in the current proposed protocols. Instead comments were made that if we waited, we would get a little better security. The protocols provide for a choice of algorithms, so as better algorithms become available, we can incorporate them into the Internet Protocol Security standards with ease. But the IESG believes that we can no longer wait. The security provided by these protocols is more then adequate to meet the security challenges of the Internet today. The mandatory to implement algorithms are there to ensure a guarantee of interoperability between differing implementations. However implementors are free to implement other algorithms which end-users are then free to use provided both end points of an association implement a common set of algorithms. Complaint: This is all very hard stuff and we should cogitate some more on this subject. Response: The Internet is no longer a research network. Most Internet users view it as a service utility, one that is expected to be reliable, available and secure. The lack of good security on the Internet is a cause of great concern in many communities. These documents specify a much needed IP Protocol level set of security services, services that are urgently needed. The IESG believes that very little will be gained and much lost from waiting any longer. Summary Although many valuable comments were received during the last call period, none provided sufficient argument for the IESG to remand the documents back to the IPSEC working group. However many of the comments will influence the next versions of the documents as they evolve through the standards process. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMDfnb8UtR20Nv5BtAQFAzgP5AfagaHxVRL6UJZjSe11CShR7naiGrNlN ciIhH9S+ffxUBI8m/1Ogp7ERiMld5gO9KkCmU9OnRCVRi0/ue31tTvdlxmWYUHNL guDQlD2/gAV8WFX7NqKI3PyPf+xgoHIjamNiZeIE8bbk37I3DI4Z2ZY3R1JjlCn6 1QP4OSr9f8w= =MNc5 -----END PGP SIGNATURE----- From ipsec-request@ans.net Mon Aug 21 17:41:57 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12036 (5.65c/IDA-1.4.4 for ); Mon, 21 Aug 1995 13:49:20 -0400 Received: by interlock.ans.net id AA44688 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 21 Aug 1995 13:42:53 -0400 Message-Id: <199508211742.AA44688@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Mon, 21 Aug 1995 13:42:53 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 21 Aug 1995 13:42:53 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 21 Aug 1995 13:42:53 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 21 Aug 1995 13:42:53 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 21 Aug 1995 13:42:53 -0400 Subject: Managing IPSP To: ipsec@ans.net Date: Mon, 21 Aug 1995 13:41:57 -0400 (EDT) From: "Uri Blumenthal" Cc: snmpv2@tis.com X-External-Networks: yes Reply-To: uri@watson.ibm.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: 282 Hi, If you think it's worth to work on providing "manageability" to IPSP, or would like to participate in WG that will do it - please send me e-mail. I'm trying to judge the amount of interest (and participants :-). -- Regards, Uri uri@watson.ibm.com ----------- From ipsec-request@ans.net Mon Aug 21 12:19:39 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14482 (5.65c/IDA-1.4.4 for ); Mon, 21 Aug 1995 16:29:49 -0400 Received: by interlock.ans.net id AA38565 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 21 Aug 1995 16:19:44 -0400 Message-Id: <199508212019.AA38565@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 21 Aug 1995 16:19:44 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 21 Aug 1995 16:19:44 -0400 Date: Mon, 21 Aug 95 16:19:39 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) To: ipsec@ans.net Subject: IPsec managability Cc: snmpv2@tis.com Uri, Management of IPsec is within the charter of the current IPsec Working Group. There is no need for a new working group as the existing group and mailing list should completely suffice. The need for management of security functions was discussed in Danvers, for example. If you have a specific proposal, the place to put it is on the IPsec mailing list for group discussion. Thanks, Ran rja@cs.nrl.navy.mil Co-chair, IP Security WG From ipsec-request@ans.net Mon Aug 21 09:18:39 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12043 (5.65c/IDA-1.4.4 for ); Mon, 21 Aug 1995 19:30:45 -0400 Received: by interlock.ans.net id AA20568 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 21 Aug 1995 19:21:12 -0400 Message-Id: <199508212321.AA20568@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 21 Aug 1995 19:21:12 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 21 Aug 1995 19:21:12 -0400 Date: Mon, 21 Aug 95 16:18:39 PDT From: Ovidiu Rancu Subject: To: ipsec@ans.net X-Mailer: Chameleon ENGP1, TCP/IP for Windows, NetManage Inc. Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII subscribe From ipsec-request@ans.net Tue Aug 22 18:51:00 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14537 (5.65c/IDA-1.4.4 for ); Tue, 22 Aug 1995 16:57:22 -0400 Received: by interlock.ans.net id AA44334 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 22 Aug 1995 16:49:25 -0400 Message-Id: <199508222049.AA44334@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Tue, 22 Aug 1995 16:49:25 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 22 Aug 1995 16:49:25 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 22 Aug 1995 16:49:25 -0400 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 22 Aug 1995 16:49:25 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 22 Aug 1995 16:49:25 -0400 Date: 22 Aug 95 13:51:00 -0500 To: uri@watson.ibm.com Cc: ipsec@ans.net, atkinson@itd.nrl.navy.mil Subject: IPSP Management Specifications was - Re: Managing IPSP Hi Uri, The ipsec WG does need to develop a draft recommendation for "management of IPSP" (aka ah/esp). Your contributions would be greatly helpful if you are working in this area. Most of the security management problems have been worked before so you might want to check the NIST and ISO publications for NLSP (ISO11577). There was a complete CMIP MIB developed for NLSP. Some of this work could be converted to SNMP (just a rough idea for a starting point). Note that there could be specific work items for: 1) ah/esp security management (perhaps two specifications) - access control (allowed network addresses, allowed protocols, etc.) - audit / alarms - configuration - etc. 2) Security for IPSEC Management it would be nice to decouple security from the security management info What if IPSEC security management used SNMP over IPSP (aka ah/esp)?... 3) Key Management (we are already working on the real-time exchange part of this item). There still needs to be additional functionality for moving keys, managing IKMP, etc. Note that access control mechanisms should be defined both at the IKMP level and at the netework (ah/esp) level. At the IKMP level access control could be based on allowed lists of "identities". A SA would then only be created for an acceptable identity. Regards, Paul _______________________________________________________________________________ Subject: Managing IPSP Author: uri@watson.ibm.com@INTERNET Date: 8/21/95 12:41 PM X-External-Networks: yes X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 282 Hi, If you think it's worth to work on providing "manageability" to IPSP, or would like to participate in WG that will do it - please send me e-mail. I'm trying to judge the amount of interest (and participants :-). -- Regards, Uri uri@watson.ibm.com ----------- From ipsec-request@ans.net Tue Aug 22 22:47:45 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA04289 (5.65c/IDA-1.4.4 for ); Tue, 22 Aug 1995 18:42:10 -0400 Received: by interlock.ans.net id AA45352 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 22 Aug 1995 18:38:22 -0400 Message-Id: <199508222238.AA45352@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 22 Aug 1995 18:38:22 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 22 Aug 1995 18:38:22 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 22 Aug 1995 18:38:22 -0400 X-Mailer: exmh version 1.6.1 5/23/95 X-Uri: http://www.milkyway.com/People/Michael_Richardson/Bio.html To: Paul_Lambert-P15452@email.mot.com, ipsec@ans.net, snmp@psi.net Cc: fw-snmp@mid.net Subject: Re: IPSP Management Specifications was - Re: Managing IPSP References: <199508222049.AA44334@interlock.ans.net> In-Reply-To: Your message of "22 Aug 1995 13:51:00 CDT." <199508222049.AA44334@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 22 Aug 1995 18:47:45 -0400 From: Michael Richardson > (ISO11577). There was a complete CMIP MIB developed for NLSP. Some of this > work could be converted to SNMP (just a rough idea for a starting point). > > Note that there could be specific work items for: > > 1) ah/esp security management (perhaps two specifications) > - access control (allowed network addresses, allowed protocols, etc.) > - audit / alarms > - configuration > - etc. Whatever mechanism MIB is arrived at for managing security via IPSC, would transport fairly well into the firewall world. Firewalls are "security gateways" afterall. In May, there a flurry of discussion on about starting a firewall MIB group. Many of the participants (myself included) have little experience with the IETF or SNMP standards process, but we did know one thing: we wanted SNMPv2 security to manage the firewall. Much recent discussion about security in SNMPv2 (please do not follow up anything here -- I'm cross posting) suggests that using IPSEC for SNMP authentication is premature. Similarly, it seems that using SNMPv2 for IPSEC configuration may be a problem :-) A strawman MIB Charter was posted by Howard Berkowitz on May 14th if you are looking through the archives. The strawman firewall MIB is 'fw-snmp' --- ask majordomo@mid.net to add you. :!mcr!: | Milkyway Networks Corporation Michael Richardson | Makers of the Black Hole firewall NCF: aa714 || xx714 | +1 613 566-4574 ... mcr@milkyway.com Home: mcr@sandelman.ocunix.on.ca. PGP key available. From ipsec-request@ans.net Tue Aug 22 23:17:57 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA10783 (5.65c/IDA-1.4.4 for ); Tue, 22 Aug 1995 19:23:16 -0400 Received: by interlock.ans.net id AA58260 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 22 Aug 1995 19:18:37 -0400 Message-Id: <199508222318.AA58260@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Tue, 22 Aug 1995 19:18:37 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 22 Aug 1995 19:18:37 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 22 Aug 1995 19:18:37 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 22 Aug 1995 19:18:37 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 22 Aug 1995 19:18:37 -0400 Subject: Re: IPSP Management Specifications was - Re: Managing IPSP To: mcr@milkyway.com (Michael Richardson) Date: Tue, 22 Aug 1995 19:17:57 -0400 (EDT) From: "Uri Blumenthal" Cc: Paul_Lambert-P15452@email.mot.com, ipsec@ans.net In-Reply-To: <199508222238.AA45352@interlock.ans.net> from "Michael Richardson" at Aug 22, 95 06:47:45 pm X-External-Networks: yes Reply-To: uri@watson.ibm.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: 1017 Michael Richardson writes: > Whatever mechanism MIB is arrived at for managing security via IPSC, would > transport fairly well into the firewall world. Firewalls are "security > gateways" afterall. First - it's not "managing *via* IPSP - it's managing IPSP *itself*. Second - I don't think it maps onto firewall world at all. > Much recent discussion about security in SNMPv2 (please do not follow > up anything here -- I'm cross posting) suggests that using IPSEC for SNMP > authentication is premature. Similarly, it seems that using SNMPv2 for IPSEC > configuration may be a problem :-) IPSEC for SNMP auth is wrong, since SNMP is designed to go over many more transports, than IP (or IPSEC). Using SNMP for IPSEC configuration seems perfectly good idea to me. > A strawman MIB Charter was posted by Howard Berkowitz on > May 14th if you are looking through the archives. Thanks for the reference. It will be useful. -- Regards, Uri uri@watson.ibm.com angmar!uri ----------- From ipsec-request@ans.net Wed Aug 23 00:27:07 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15515 (5.65c/IDA-1.4.4 for ); Tue, 22 Aug 1995 20:19:05 -0400 Received: by interlock.ans.net id AA29488 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 22 Aug 1995 20:16:14 -0400 Message-Id: <199508230016.AA29488@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 22 Aug 1995 20:16:14 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 22 Aug 1995 20:16:14 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 22 Aug 1995 20:16:14 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 22 Aug 1995 20:16:14 -0400 X-Mailer: exmh version 1.6.1 5/23/95 X-Uri: http://www.milkyway.com/People/Michael_Richardson/Bio.html To: uri@watson.ibm.com, ipsec@ans.net Subject: Re: IPSP Management Specifications was - Re: Managing IPSP References: <9508222317.AA35218@hawpub.watson.ibm.com> In-Reply-To: Your message of "Tue, 22 Aug 1995 19:17:57 EDT." <9508222317.AA35218@hawpub.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 22 Aug 1995 20:27:07 -0400 From: Michael Richardson > First - it's not "managing *via* IPSP - it's managing IPSP *itself*. I realize that. > Second - I don't think it maps onto firewall world at all. Maybe I misunderstand the point: I assume that you want to determine a. when to encrypt --- by source, dest, service. b. when to authenticate --- src,dst,service c. when to accept without ESP, by src,dst,service d. when to accept without AH, by src,dst,service It you can do all of those things, you can have a security gateway. > IPSEC for SNMP auth is wrong, since SNMP is designed to go over many > more transports, than IP (or IPSEC). Using SNMP for IPSEC configuration > seems perfectly good idea to me. I agree about SNMP over IPSEC being wrong. Maybe in couple of weeks the the SNMPv2 proposals will settle down again with a clear security contender. --- you have to use authenticated SNMP for IPSEC configuration. :!mcr!: | Milkyway Networks Corporation Michael Richardson | Makers of the Black Hole firewall NCF: aa714 || xx714 | +1 613 566-4574 ... mcr@milkyway.com Home: mcr@sandelman.ocunix.on.ca. PGP key available. From ipsec-request@ans.net Wed Aug 23 12:15:32 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA04267 (5.65c/IDA-1.4.4 for ); Wed, 23 Aug 1995 08:34:44 -0400 Received: by interlock.ans.net id AA35081 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 23 Aug 1995 08:29:34 -0400 Message-Id: <199508231229.AA35081@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 23 Aug 1995 08:29:34 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 23 Aug 1995 08:29:34 -0400 Date: Wed, 23 Aug 1995 14:15:32 +0200 X-Sender: Pbaltzer@sun4nl.nluug.nl Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: (Recipient list suppressed) From: publish@baltzer.nl (Baltzer Science Publishers) Subject: WIRELESS NETWORKS - CONTENTS CONTENTS WIRELESS NETWORKS, ISSN 1022-0038, Co-published with the ACM (Association for Computing Machinery) The journal of mobile communication, computation and information Editor-in-Chief: I. Chlamtac, Department of Electrical and Computer Engineering, University of Massachusetts, Amherst MA 01003, USA Aims & Scope: The wireless communication revolution is bringing fundamental changes to communication and computing. From wide-area cellular systems to wireless LANs, mobile and wireless networks are on the verge of providing fully distributed and ubiquitous mobile computing and communications any time, anywhere.Through a seamless integration with fixed network infrastructures the future promises a universal communication grid, bringing an end to the tyranny of geography. A parallel evolution and proliferation of services for the mobile user are changing the scope of communication and the nature of user and machine interaction paradigms. Wireless Networks will serve as the publication vehicle for high-quality, in-depth original articles addressing networks, systems, algorithms, and applications that support the symbiosis of portable computers, wireless networks, mobile communication and computation, and their integration into the global network of the future. Regularly addressed topics will include: Network architectures for nomadic LAN to WAN communication and computation; mobile and wireless communications protocols, media access control algorithms, algorithms for mobility and mobility management including hand-off, registration, location, tracking, and routing; performance evaluation of mobile/wireless networks; systems topology design including cell architectures, capacity allocation and coverage issues, mobility, bandwidth, or intermittent connectivity related communication and computing issues; network management, control and signaling; security, scalability and reliability issues; database design and management for mobility; software principles, operating systems and resource management for nomadic computing; service integration and interworking of wired and wireless networks; applications, computing services and service algorithms in the mobile environment; enabling technologies for wireless and mobile communication including wireless signal propagation studies, portable hardware technologies, energy efficient and low-power design and components; network demonstrations, experimentation, and testbeds. Contents Volume 1, No. II pp. 129-138, J.P.M.G. Linnartz, On the performance of packet switched cellular networks for wireless data communication pp. 139-146, Z. Haas and S. Paul, Limited lifetime shared access in mobile systems pp. 147-160, I Rubin and S. Shambayati, Performance evaluation of a reservation random access scheme for packetized wireless systems with call control and hand-off loading pp. 161-174, K.Y. Eng, M.J. Karol, M. Veeraraghavan, E. Ayanoglu, C.B. Woodworth, and R.A. Valenzuela, A wireless broadband ad-hoc ATM local-area network pp. 175-186, A. Bar-Noy, I. Kessler and M. Sidi, Mobile users: To update or not to update? pp. 187-196, I. Akyildiz and J. S.M. Ho, Dynamic mobile user location update for wireless PCS networks pp. 197-210, R. Jain and Yi-Bing Lin, An auxiliary user location strategy employing forward pointers to reduce network impacts of PCS pp. 211-220, C. Rose and R. Yates, Minimizing the average cost of paging under delay constraints pp. 221-226, A. Farago, On the complexity of finding sparsest and densest parts in wireless networks pp. 227-239, M. Zorzi, Mobile radio slotted ALOHA with capture and diversity Submissions of articles and proposals for special issues are to be addressed to the Editor-in-Chief: I. Chlamtac Requests for FREE SPECIMEN copies and orders for Wireless Networks are to be sent to: E-mail: publish@baltzer.nl or see our homepage http://www.NL.net/~baltzer/ . From ipsec-request@ans.net Wed Aug 23 23:50:16 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14340 (5.65c/IDA-1.4.4 for ); Wed, 23 Aug 1995 18:56:49 -0400 Received: by interlock.ans.net id AA48449 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 23 Aug 1995 18:51:14 -0400 Message-Id: <199508232251.AA48449@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 23 Aug 1995 18:51:14 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 23 Aug 1995 18:51:14 -0400 To: "David A. Wagner" Cc: ipsec@ans.net Subject: Re: Part Three: Field Variance Analysis In-Reply-To: Your message of "Wed, 23 Aug 1995 17:16:02 -0400." <9508232116.AA19735@flagstaff.Princeton.EDU> Date: Wed, 23 Aug 1995 18:50:16 -0500 From: Craig Metz In message <9508232116.AA19735@flagstaff.Princeton.EDU>, "David A. Wagner" writ es: >> Also, I'm not a cryptographer and I don't play one on TV, but it >> would seem to me that known nonzero but not really important values are >> probably better than zero values and should not be worse. It would seem >> to me that information of that sort should be stirred into the pot just to >> have some nonzero bits in the stew. > >No. They're not. If the MD5 MAC is found insecure without those extra >ingredients in the pot, it should be thrown away without delay. (And I >want to emphasize that noone has found MD5 MAC to be insecure in that way.) This is a question for the crypto people. >> Some discussion should be given to reserved fields. Currently, I >> believe that reserved fields should be included in the hash for exactly >> the same reason unknown option fields should be. The argument and cases >> is exactly the same. > >You mean, like the reserved field in the AH header? (which *is* >explicity included in the hash) Or did you mean some other reserved >field? Yes. -Craig From ipsec-request@ans.net Wed Aug 23 23:48:20 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12038 (5.65c/IDA-1.4.4 for ); Wed, 23 Aug 1995 18:56:50 -0400 Received: by interlock.ans.net id AA68924 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 23 Aug 1995 18:51:12 -0400 Message-Id: <199508232251.AA68924@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 23 Aug 1995 18:51:12 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 23 Aug 1995 18:51:12 -0400 To: "David A. Wagner" Cc: ipsec@ans.net Subject: Re: Part Two: IPv4 Options We Can't Handle In-Reply-To: Your message of "Wed, 23 Aug 1995 17:11:39 -0400." <9508232111.AA19555@flagstaff.Princeton.EDU> Date: Wed, 23 Aug 1995 18:48:20 -0500 From: Craig Metz In message <9508232111.AA19555@flagstaff.Princeton.EDU>, "David A. Wagner" writ es: >You forgot a few: > > 3. modularity: the AH transform should be a modular protocol. Not so. IPsec reaches its tentacles into a lot of places in any layering model I've seen (in BSD, for instance, we're talking sockets, transport, and network layers). Modularity is a good design ideal, but it's not clear to me that the kind of security guarantees IPsec would like to make can be done without violating layering. > 4. functionality: the current AH spec precludes IP ESP AH .. packets. > (Do you see why?) You can't put optional headers inside an ESP payload without another IP header (giving you tunnel mode). While we can get along without this rule, it ends up making implementations much less complex on the output side. The two valid packets similar to what you have there are IP AH ESP [ULP] and IP ESP [IP AH ULP]. >I think we have here a fundamental disagreement about what data >AH should guarantee the authenticity of. Agreed, as I have said in previous messages. >We agree that AH must guarantee the authenticity of the payload >and the AH header. But we disagree beyond that: I claim that AH >should not (and need not) guarantee the authenticity of the IP >options, at least for IPv4. (More precisely, if a SA demands >authenticity of certain IP options, I believe that the implementation >should encapsulate first, saving those IP options, and then apply >AH to the resulting datagram.) > >I haven't seen any attack on my view of what AH should authenticate, >and I haven't seen any attack on your view. I think they're probably >both secure. So the argument is over issues of modularity, cleanness, >expandability, and functionality -- not over security! There are thousands of real users of IPSO right now who would not agree with your statement that IPv4 options need not be protected. The same security-conscious sites that use IPSO and CIPSO right now are a significant portion of IPsec's potential user base. Failing to deliver on what could be their main requirement for IPsec will NOT make them happy, will NOT cause them to buy into IPsec, and will NOT help IPsec's deployment. To me, IPSO/CIPSO is a harsh market reality that IPsec must face. The good news here is that, because they are invariant [or BETTER BE ;)], protecting them with AH is tractable. -Craig From ipsec-request@ans.net Thu Aug 24 06:57:50 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15389 (5.65c/IDA-1.4.4 for ); Thu, 24 Aug 1995 11:07:20 -0400 Received: by interlock.ans.net id AA07037 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 24 Aug 1995 11:00:13 -0400 Message-Id: <199508241500.AA07037@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 24 Aug 1995 11:00:13 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 24 Aug 1995 11:00:13 -0400 Date: Thu, 24 Aug 95 10:57:50 EDT From: hammonds@sol.hanscom.af.mil (Grace Hammonds) To: mjs@tycho.ncsc.mil Subject: ISAKMP formal analysis Cc: brackin@dockmaster.ncsc.mil, chin@cat.syr.edu, faustj@LONEXB.ADMIN.RL.AF.MIL, hammonds@sol.hanscom.af.mil, ipsec@ans.net, lichotar@v3.hanscom.af.mil, woolj@tango-vs1.hanscom.af.mil To Mark Schertler NSA R23 Mark, We met at the NSA Techfest. I am working with Jack Wool to identify to what extent formal security analysis using belief logic could support the development of security protocols such as the ISAKMP. I have started reviewing the internet draft from the IPSEC Working Group on ISAKMP. My initial reaction is that this development would be a good fit; our methodology can help systematically identify potential avenues for certain attacks, particularly masquerade and replay, within the protocol. We do however need more information. Please let us know where we can obtain a copy of the Karn95 paper: P. Karn and B. Simpson, "The Photuris Key Management Protocol", Internet Draft, work in progress, March 1995. This paper is referenced for information on "cookie" generation. I will be in touch by telephone as well. Grace L. Hammonds AGCS, Inc. 91 Montvale Avenue Stoneham, MA 02180 Tel. 617-279-2864 Fax. 617-279-2865 From ipsec-request@ans.net Thu Aug 24 19:31:43 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12846 (5.65c/IDA-1.4.4 for ); Thu, 24 Aug 1995 15:29:08 -0400 Received: by interlock.ans.net id AA47794 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 24 Aug 1995 15:22:09 -0400 Message-Id: <199508241922.AA47794@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 24 Aug 1995 15:22:09 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 24 Aug 1995 15:22:09 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 24 Aug 1995 15:22:09 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 24 Aug 1995 15:22:09 -0400 Date: Thu, 24 Aug 1995 12:31:43 -0700 From: ashar@osmosys.incog.com (Ashar Aziz) To: ipsec@ans.net Subject: SKIP with AH/ESP/etc. X-Sun-Charset: US-ASCII Folks, Hilarie Orman has proposed an excellent alternative protocol to integrate SKIP with the AH/ESP protocols which is in many ways superior to what we proposed at the Stockholm SKIP BOF. Since there was clear consensus at the last BOF to make SKIP a standards track protocol, I would like to make sure that there is group consensus on this alternative SKIP protocol header before we publish it in the next revision of the SKIP draft. Hilarie has proposed that we separate SKIP key-mgmt info from transform specific information (e.g. IVs, MACs etc.) and place this in a separate SKIP header that precedes the AH/ESP headers. SKIP would need its own protocol number, and would contain a next header field which would indicate AH or ESP. There are actually other possibilities as well, which I will describe below. A figure (courtesy of Paul Lambert) illustrating this is as follows: > +---------------------------------------------------------+ > | IP Header (Next Header == SKIP) | > +---------------------------------------------------------+ > | SKIP Header with key mgmt data but w/o the | > | transform data (such as IV) and NextHeader=(AH/ESP/etc)| > +---------------------------------------------------------+ > | ESP or AH exactly as per RFC-1825-1829 but with a SPI | > | value that is from the reserved SPI space and is | > | assigned to mean (look at the preceding SKIP header) | > +---------------------------------------------------------+ The big win here is that all of the current proposed standard RFCs 1825-1829 can be used directly with SKIP key-mgmt without making any new protocol transforms specific to SKIP. This includes the DES-CBC and the key-ed MD5 transform as currently specified. Any new transforms defined can be similarly accommodated. This also makes possible the use of SKIP with other protocols that also need keying material, without modifying the protocols themselves. The SKIP nextheader field would simply specify those protocols. Some examples of this are routing protocols that use keyed MD5 (and dont need/use AH for this purpose). (Thanks to Cheryl Madson for pointing out the need/possibility of these other alternatives). Because this is a much cleaner and simpler way to integrate SKIP with AH/ESP (as well as other protocols that may need keying material) I am inclined to adopt Hilarie's suggestion and specify this in the next draft of SKIP (due in a week or so from now). Please let me know if people have strong opinions on this, either for or against. Thanks, Ashar. From ipsec-request@ans.net Thu Aug 24 21:24:18 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14436 (5.65c/IDA-1.4.4 for ); Thu, 24 Aug 1995 17:31:24 -0400 Received: by interlock.ans.net id AA37671 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 24 Aug 1995 17:25:33 -0400 Message-Id: <199508242125.AA37671@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 24 Aug 1995 17:25:33 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 24 Aug 1995 17:25:33 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 24 Aug 1995 17:25:33 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 24 Aug 1995 17:25:33 -0400 X-Mailer: exmh version 1.6.1 5/23/95 X-Uri: http://www.milkyway.com/People/Michael_Richardson/Bio.html To: ashar@osmosys.incog.com (Ashar Aziz) Cc: ipsec@ans.net Subject: Re: SKIP with AH/ESP/etc. References: <199508241922.AA47794@interlock.ans.net> In-Reply-To: Your message of "Thu, 24 Aug 1995 12:31:43 PDT." <199508241922.AA47794@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 24 Aug 1995 17:24:18 -0400 From: Michael Richardson From my understanding of SKIP, the key management info is essentially the bulk encryption key encoded in long term key. I'd rather that stuff stayed with the SKIP data. Or, is there other key mgmt data that SKIP stores? To me, it seems messier, since SKIP gets special processing in an generalized ESP/AH processing system. From ipsec-request@ans.net Thu Aug 24 22:02:39 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12994 (5.65c/IDA-1.4.4 for ); Thu, 24 Aug 1995 18:06:21 -0400 Received: by interlock.ans.net id AA36851 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 24 Aug 1995 18:02:47 -0400 Message-Id: <199508242202.AA36851@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 24 Aug 1995 18:02:47 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 24 Aug 1995 18:02:47 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 24 Aug 1995 18:02:47 -0400 Date: Thu, 24 Aug 1995 15:02:39 -0700 (MST) From: Bob Wilmes To: ipsec@ans.net Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII SUBSCRIBE bwilmes@primenet.com From ipsec-request@ans.net Sun Aug 27 21:25:20 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA16485 (5.65c/IDA-1.4.4 for ); Sun, 27 Aug 1995 17:38:08 -0400 Received: by interlock.ans.net id AA30002 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 27 Aug 1995 17:25:55 -0400 Message-Id: <199508272125.AA30002@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Sun, 27 Aug 1995 17:25:55 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Sun, 27 Aug 1995 17:25:55 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Sun, 27 Aug 1995 17:25:55 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 27 Aug 1995 17:25:55 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 27 Aug 1995 17:25:55 -0400 Date: Sun, 27 Aug 1995 17:25:20 -0400 From: kutten@watson.ibm.com (S.Kutten) To: ipsec@ans.net Subject: Call for papers: Special issue on security and mobility Call for Papers For the new journal published in cooperation with the ACM: WIRELESS NETWORKS Special Issue: Mobility and Security Scope: Mobility introduces a new dimension to the problem of secure computing and communication. The securing becomes harder and often more important. This is sometimes due to the mobility of the communication devices, sometimes due to the mobility of users (without mobile device), or the mobility of objects, or that of the attackers. Papers are sought that address the requirements, designs, algorithms and implementation experience for securing networks, distributed systems, information, and applications in environments that can support mobility. Possible topics include, but are not limited to: Securing communication and distributed systems, such as: - Internet (TCP/IP, mobile IP, DNS, DHCP) - ATM - CDPD - GSM - SNA - Wireless LAN Cryptographic protocols, such as: - key distribution - authentication - payments - anonymity and privacy Cryptographic functions, such as: - encryption - message authentication - message digest - signatures Computer viruses and worms Security for intelligent and mobile objects and agents Secure electronic commerce Cryptographic hardware Security and cryptography for wireless communication systems. The authors should send 6 copies of their paper to one of the guest editors by November 15, 1995. The following time-table shall be followed: Manuscript Submission Deadline: November 15, 1995 Acceptance Notification: May 15, 1996 Final Manuscript Submission Deadline: July 15, 1996 Expected Publication Date: Last Quarter 1996 E-mail submissions are encouraged (post-script only). Set subject to `Submission to WINET special issue'. Guest Editors: Amir Herzberg IBM T.J. Watson Research Center P.O. Box 704 #H3-D18 Yorktown Heights, NY 10598 Telephone: (914) 784-6981 Facsimile: (914) 784-6205 Internet: amir@watson.ibm.com Shay Kutten IBM T.J. Watson Research Center P.O. Box 704 #H3-D38 Yorktown Heights, NY 10598 Telephone: (914) 784-7346 Facsimile: (914) 784-6205 Internet: kutten@watson.ibm.com From ipsec-request@ans.net Mon Aug 28 11:03:03 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15375 (5.65c/IDA-1.4.4 for ); Mon, 28 Aug 1995 07:09:50 -0400 Received: by interlock.ans.net id AA20708 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 28 Aug 1995 07:04:15 -0400 Message-Id: <199508281104.AA20708@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 28 Aug 1995 07:04:15 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 28 Aug 1995 07:04:15 -0400 From: Germano Caronni Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 28 Aug 1995 07:04:15 -0400 Subject: Re: SKIP with AH/ESP/etc. To: ashar@osmosys.incog.com (Ashar Aziz) Date: Mon, 28 Aug 1995 13:03:03 +0200 (MET DST) Cc: ipsec@ans.net In-Reply-To: <199508241922.AA47794@interlock.ans.net> from "Ashar Aziz" at Aug 24, 95 12:31:43 pm X-Mailer: ELM [version 2.4 PL24 PGP5a] Content-Type: text Content-Length: 1013 Ashar Aziz wrote: > Hilarie has proposed that we separate SKIP key-mgmt info > from transform specific information (e.g. IVs, MACs etc.) > and place this in a separate SKIP header that precedes > the AH/ESP headers. SKIP would need its own protocol number, > and would contain a next header field which would indicate > AH or ESP. There are actually other possibilities as well, > which I will describe below. > > Please let me know if people have strong opinions on this, > either for or against. IMHO this is a very valuable idea. The problem so far with SKIP was that it did not fit into the 'security association' philosophy with which AH and ESP are designed. With the proposed changes, SKIP would kind of establish its own security association on a per-packet base, which could then be used by the rest of the packet. Very neat! At the same time the idea does not introduce additional overhead or offline communication. I am looking forward to the new draft ;-) Friendly greetings, Germano Caronni From ipsec-request@ans.net Mon Aug 28 12:53:03 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA04306 (5.65c/IDA-1.4.4 for ); Mon, 28 Aug 1995 08:59:54 -0400 Received: by interlock.ans.net id AA51674 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 28 Aug 1995 08:53:17 -0400 Message-Id: <199508281253.AA51674@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 28 Aug 1995 08:53:17 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 28 Aug 1995 08:53:17 -0400 From: Karl Fox Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 28 Aug 1995 08:53:17 -0400 Date: Mon, 28 Aug 95 08:53:03 -0400 To: Craig Metz Cc: ipsec@ans.net Subject: Re: Part Two: IPv4 Options We Can't Handle In-Reply-To: <199508232251.AA68924@interlock.ans.net> References: <9508232111.AA19555@flagstaff.Princeton.EDU> <199508232251.AA68924@interlock.ans.net> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Craig Metz writes: > There are thousands of real users of IPSO right now who would not > agree with your statement that IPv4 options need not be protected. The same > security-conscious sites that use IPSO and CIPSO right now are a significant > portion of IPsec's potential user base. Failing to deliver on what could be > their main requirement for IPsec will NOT make them happy, will NOT cause > them to buy into IPsec, and will NOT help IPsec's deployment. > > To me, IPSO/CIPSO is a harsh market reality that IPsec must face. > The good news here is that, because they are invariant [or BETTER BE ;)], > protecting them with AH is tractable. I agree that protecting security options with the AH is desirable, but how do we do it in the face of existing IPv4 routers that reorder options? Sort them before calculating the AH? (only .5 :-) From ipsec-request@ans.net Mon Aug 28 07:24:23 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA16947 (5.65c/IDA-1.4.4 for ); Mon, 28 Aug 1995 11:29:59 -0400 Received: by interlock.ans.net id AA04003 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 28 Aug 1995 11:24:28 -0400 Message-Id: <199508281524.AA04003@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 28 Aug 1995 11:24:28 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 28 Aug 1995 11:24:28 -0400 Date: Mon, 28 Aug 95 11:24:23 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) To: ipsec@ans.net Subject: AH & IPv4 options Routers that arbitrarily reorder IP options are broken. Bill Simpson "educated" me about this issue offline. To the best of my knowledge (including my understanding of Bill's inputs) those routers never included high-volume vendors (e.g. Cisco, Wellfleet/Bay, 3COM) and the software releases that did reorder options are ancient by now. To the best of my understanding, all such routers were derived in part on a single original TCP/IP stack. That original stack has not reordered options for a long while now. I don't think we can or should make any effort to protect AH from such routers. I don't think we should change specs just to make older broken systems conforming. If the IETF started changing specs to accomodate every broken implementation that existed, we'd never make any forward progress at all, IMHO... :-) Ran rja@cs.nrl.navy.mil From ipsec-request@ans.net Mon Aug 28 07:54:15 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17095 (5.65c/IDA-1.4.4 for ); Mon, 28 Aug 1995 12:40:29 -0400 Received: by interlock.ans.net id AA80704 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 28 Aug 1995 12:30:51 -0400 Message-Id: <199508281630.AA80704@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 28 Aug 1995 12:30:51 -0400 From: smb@research.att.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 28 Aug 1995 12:30:51 -0400 To: atkinson@itd.nrl.navy.mil (Ran Atkinson) Cc: ipsec@ans.net Subject: Re: AH & IPv4 options Date: Mon, 28 Aug 95 11:54:15 EDT Routers that arbitrarily reorder IP options are broken. Bill Simpson "educated" me about this issue offline. To the best of my knowledge (including my understanding of Bill's inputs) those routers never included high-volume vendors (e.g. Cisco, Wellfleet/Bay, 3COM) and the software releases that did reorder options are ancient by now. To the best of my understanding, all such routers were derived in part on a single original TCP/IP stack. That original stack has not reordered options for a long while now. I don't think we can or should make any effort to protect AH from such routers. I don't think we should change specs just to make older broken systems conforming. What of routers -- specifically Cisco -- that will add or delete IPSO options? Bill claimed that that's broken, too -- but it certainly exists, and is probably necessary for single-level systems on, say, top secret nets. From ipsec-request@ans.net Mon Aug 28 18:12:48 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA16673 (5.65c/IDA-1.4.4 for ); Mon, 28 Aug 1995 13:21:35 -0400 Received: by interlock.ans.net id AA12738 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 28 Aug 1995 13:11:42 -0400 Message-Id: <199508281711.AA12738@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 28 Aug 1995 13:11:42 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 28 Aug 1995 13:11:42 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Aug 1995 12:12:48 -0600 To: smb@research.att.com From: hughes@hughes.network.com (James P. Hughes) Subject: Re: AH & IPv4 options Cc: atkinson@itd.nrl.navy.mil (Ran Atkinson), ipsec@ans.net >What of routers that will add or delete IPSO >options? Bill claimed that that's broken, too -- but it certainly exists, >and is probably necessary for single-level systems on, say, top secret >nets. As a vendor of routers that can be (and routinely are) profiled to add or delete options such as CIPSO, DIN6 or others. Not being able to stamp packets is an inconvenience, not the end of the world. Our filter can be programed that if the protocol is IPSEC, then do not add any labels. That is possible. Specific firewalling instructions for IPSEC will be necessary regardless of the labeling issues... This is not a problem for IP in IP, right? The inner packet is not touched by labeling... ---------------------- James P Hughes Network Systems Corporation, A Subsidiary of StorageTek. Voice (612)424-1676 FAX (612)391-1821 Key fingerprint = 68 E7 D5 75 3C 88 86 71 D4 34 36 C3 8E DD 48 17 From ipsec-request@ans.net Mon Aug 28 17:09:55 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14630 (5.65c/IDA-1.4.4 for ); Mon, 28 Aug 1995 13:21:36 -0400 Received: by interlock.ans.net id AA58610 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 28 Aug 1995 13:12:55 -0400 Message-Id: <199508281712.AA58610@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 28 Aug 1995 13:12:55 -0400 From: Ran Atkinson Date: Mon, 28 Aug 1995 13:09:55 -0400 In-Reply-To: smb@research.att.com "Re: AH & IPv4 options" (Aug 28, 11:54) References: <9508281635.AA25748@itd.nrl.navy.mil> Reply-To: rja@cs.nrl.navy.mil X-Mailer: Z-Mail (3.2.1 10apr95) To: ipsec@ans.net Subject: Re: AH & IPv4 options Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: rja@bodhi.cs.nrl.navy.mil On Aug 28, 11:54, smb@research.att.com wrote: } Subject: Re: AH & IPv4 options % What of routers -- specifically Cisco -- that will add or delete IPSO % options? Bill claimed that that's broken, too -- but it % certainly exists, IPSO mangling is turned OFF in all Cisco routers UNLESS the network admin specifically configures it on. IETF specs can't protect against users who shoot themselves in the foot by misconfiguring their networks and are then surprised when things don't work as expected. Moreover, MOST sites that do anything with IPSO in the first place ONLY apply IPSO filtering (e.g. Cisco's Access Lists) and do NOT mangle the packet by inserting/modifying/deleting IPSO labels. Having some familiarity with sites that currently use IPSO filtering (commonplace in classified networks), I can say that most of those sites desire to authenticate their IPSO options and are uncomfortable with non-authenticatable IPSO options as we have at present. The ability to authenticate IPSO labels is really really important because those labels are used for Mandatory Access Controls. % and is probably necessary for single-level systems on, say, % top secret nets. I disagree with the assertion that IPSO mangling is ever really necessary, based on experience consulting with folks who have classified networks. Moreover, the classified nets don't cross connect with The Internet and their operators DO have complete control over the network configuration so it is straight-forward to reconfigure their routers to disable IPSO mangling if it is currently enabled. Ran rja@cs.nrl.navy.mil From ipsec-request@ans.net Mon Aug 28 18:05:25 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15515 (5.65c/IDA-1.4.4 for ); Mon, 28 Aug 1995 14:17:24 -0400 Received: by interlock.ans.net id AA16953 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 28 Aug 1995 14:07:47 -0400 Message-Id: <199508281807.AA16953@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 28 Aug 1995 14:07:47 -0400 To: smb@research.att.com Cc: Ran Atkinson , ipsec@ans.net Subject: Re: AH & IPv4 options In-Reply-To: Your message of Mon, 28 Aug 95 11:54:15 -0400. <199508281630.AA80704@interlock.ans.net> Date: Mon, 28 Aug 95 14:05:25 -0400 From: Steve Kent Steve, Routers have been called upon to add IPSO options for hosts that are unable to generate them, or to delete IPSO for hosts that do not tolerate receipt of these options. Such hosts do not seem likely candidates to be updated to generate AH headers, i.e., they are old IP implementations that were not compliant with option processing in general and/or were unable to generate IPSO. So, I agree with Ran that this is not a big deal. Steve