From majordom@p-o.ans.net Mon Jan 1 07:21:25 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA10708 (5.65c/IDA-1.4.4 for ); Mon, 1 Jan 1996 18:27:32 -0500 Received: by p-o.ans.net id AA15962 (5.65c/IDA-1.4.4 for ipsec-outgoing); Mon, 1 Jan 1996 23:20:55 GMT Date: Mon, 1 Jan 96 15:21:25 PST From: rja@rja-ss20.cisco.com (Randall Atkinson) Message-Id: <9601012321.AA10597@rja-ss20.cisco.com.noname> To: ipsec@ans.net Subject: Re: AH/ESP & Replay Protection In-Reply-To: <199512292126.QAA07123@hiway1.exit109.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net The difference between (a key belonging to the S->D Sec Assoc certified the S->D packet as authentic and the packet being authentically from S->D) is, IMHO, not meaningful to an application or to the policy engine. The trust IS bound in the key already, but the key is part of mechanism not part of policy and the key isn't visible to or particularly relevant to the application, whilst the source address is already both visible and relevant to the application. I think you're splitting too fine a hair here. Ran rja@cisco.com From majordom@p-o.ans.net Mon Jan 1 07:26:09 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14809 (5.65c/IDA-1.4.4 for ); Mon, 1 Jan 1996 18:28:48 -0500 Received: by p-o.ans.net id AA17002 (5.65c/IDA-1.4.4 for ipsec-outgoing); Mon, 1 Jan 1996 23:25:37 GMT Date: Mon, 1 Jan 96 15:26:09 PST From: rja@rja-ss20.cisco.com (Randall Atkinson) Message-Id: <9601012326.AA10622@rja-ss20.cisco.com.noname> To: ipsec@ans.net Subject: Re: ICMP Security Failures Newsgroups: cisco.external.ietf.ipsec In-Reply-To: <199512291507.QAA17151@cops.cert.dfn.de> Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net In article <199512291507.QAA17151@cops.cert.dfn.de>, Ellerman@cert.dfn.de wrote: > With IP-AH-AH-ULP the sending host could generate one AH with the key > shared with the router and the other AH with a key shared with the > other host. IMHO, the intermediate router problem you outline is best solved by using IP-AH-IP-AH-ULP which is a VERY different beast from IP-AH-AH-ULP. It still isn't sure what value the receiver gets from such an arrangement versus the simpler IP-AH-ULP. Routing is dynamic in The Internet, so knowledge that the packet passed through some particular router with AH tunnelling setup isn't normally of use. Ran rja@cisco.com From majordom@p-o.ans.net Mon Jan 1 07:34:13 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14321 (5.65c/IDA-1.4.4 for ); Mon, 1 Jan 1996 18:38:15 -0500 Received: by p-o.ans.net id AA17066 (5.65c/IDA-1.4.4 for ipsec-outgoing); Mon, 1 Jan 1996 23:33:42 GMT Date: Mon, 1 Jan 96 15:34:13 PST From: rja@rja-ss20.cisco.com (Randall Atkinson) Message-Id: <9601012334.AA10647@rja-ss20.cisco.com.noname> To: ipsec@ans.net Subject: Re: ESP and AH combinations Newsgroups: cisco.external.ietf.ipsec In-Reply-To: <199512292126.QAA07109@hiway1.exit109.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net In article <199512292126.QAA07109@hiway1.exit109.com>, daw@cs.berkeley.edu wrote: >Today's AH doesn't provide authentication of the IP src address either! Nonsense. Consider that there is a Security Association from S->D using AH, Keyed MD5, and some secret key known only to S and D. D receives a packet claiming to be from S, containing an Authentication Header with an SPI refering to the above Sec Assoc. The AH checks on the receive side pass. D now knows authentically that S sent the packet in question. >(You can easily see the difference when several IP hosts use the same >signing key K; then any one of those could impersonate any of the others, >so upon receiving a packet signed by K, you can only conclude that it >came from key K, i.e. from one of those IP hosts.) A degenerate case. The text for the spec specifically notes this issue and discourages having many senders share the same Security Association (its discussed in the context of multicast, which is the only case I've found so far where such a Sec Assoc makes any sense). Perhaps you would prefer that such cases be outlawed ?? Ran rja@cisco.com From majordom@p-o.ans.net Tue Jan 2 05:41:57 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA10676 (5.65c/IDA-1.4.4 for ); Tue, 2 Jan 1996 00:44:49 -0500 Received: by p-o.ans.net id AA30753 (5.65c/IDA-1.4.4 for ipsec-outgoing); Tue, 2 Jan 1996 05:42:08 GMT Date: Tue, 2 Jan 1996 00:41:57 -0500 Message-Id: <199601020541.AAA20350@hiway1.exit109.com> X-Sender: mpwagner@hiway1.exit109.com X-Mailer: Windows Eudora Version 1.4.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipsec@ans.net From: daw@cs.berkeley.edu (David Wagner) Subject: Re: ESP and AH combinations Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net >>Today's AH doesn't provide authentication of the IP src address either! > >Nonsense. [... in the common case of one sender, AH authenticates ip_src ...] >>(You can easily see the difference when several IP hosts use the same >>signing key K; [...]) > >A degenerate case. [...] Perhaps you would prefer that >such cases be outlawed ?? I agree with your first claim. Yet I think it's interesting to remember the context here -- I made my original statement in response to your claim that the AH MAC must cover ip_src if it is to be secure. Note that, when there's just one sender, it doesn't matter whether the AH MAC covers the ip_src. (E.g. the receiver never examines the ip_src field that came in over the wire, and always uses the known-correct sender field associated with the appropriate SPI.) Therefore if you outlaw the "degenerate" case of multiple senders (and I have no opinion on this subject), it certainly won't matter whether the AH MAC covers the ip_src field or not. But in the interests of speedy progress, I won't complain about the AH design choice to cover the IP header anymore. I'm sure you're all tired of my silly grumblings by now. :-) On the other hand, I do hope this design decision will be documented in the spec, and I wish the spec would be clearer on these issues. (e.g. document which AH combinations are allowed, please!) -- Dave Wagner, certain that he will regret getting sucked into this debate once more.... From majordom@p-o.ans.net Tue Jan 2 12:48:27 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA11889 (5.65c/IDA-1.4.4 for ); Tue, 2 Jan 1996 08:06:50 -0500 Received: by p-o.ans.net id AA38401 (5.65c/IDA-1.4.4 for ipsec-outgoing); Tue, 2 Jan 1996 13:00:31 GMT X-Mailer: exmh version 1.6.5 12/11/95 To: ipsec@ans.net Subject: Re: AH/ESP & Replay Protection In-Reply-To: Your message of "Sat, 30 Dec 1995 14:25:40 GMT." <4689.bsimpson@morningstar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Jan 1996 07:48:27 -0500 From: Craig Metz Message-Id: <9601020749.aa13970@cs.nrl.navy.mil> Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net In message <4689.bsimpson@morningstar.com>, "William Allen Simpson" writes: >> From: daw@cs.berkeley.edu (David Wagner) >> My current view is that a nice way to pass the information to the >> policy engine is using "key K says data D" notation, instead of >> "ip->ip_src says data D". >> >Yes, this is what Karn's code does, too. He passes the SPI up the >stack, and since the SPI is uniquely maintained by the Destination, >it makes a convenient tag for the policy engine to determine the >validity of the data. No Source involved at all! Color me crazy, but shouldn't one of the first checks done when input processing AH or ESP be to make sure that the src/dst pair on the IP header and the security association line up? (If they don't match, then the packet is bogus, if they do match, which one you check later is a moot point) Otherwise, you're begging for replay problems... From majordom@p-o.ans.net Tue Jan 2 15:14:13 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA13420 (5.65c/IDA-1.4.4 for ); Tue, 2 Jan 1996 10:20:54 -0500 Received: by p-o.ans.net id AA13904 (5.65c/IDA-1.4.4 for ipsec-outgoing); Tue, 2 Jan 1996 15:14:47 GMT From: Uwe Ellermann Date: Tue, 2 Jan 1996 16:14:13 +0100 Message-Id: <199601021514.QAA01330@cops.cert.dfn.de> To: ipsec@ans.net Subject: Re: ICMP Security Failures X-Sun-Charset: US-ASCII Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net > From: rja@rja-ss20.cisco.com (Randall Atkinson) > > > With IP-AH-AH-ULP the sending host could generate one AH with the key > > shared with the router and the other AH with a key shared with the > > other host. > > IMHO, the intermediate router problem you outline is best solved by using > IP-AH-IP-AH-ULP which is a VERY different beast from IP-AH-AH-ULP. > Agreed it's very different. > It still isn't sure what value the receiver gets from such an arrangement > versus the simpler IP-AH-ULP. Routing is dynamic in The Internet, so > knowledge that the packet passed through some particular router with > AH tunnelling setup isn't normally of use. > It's not what the *receiver* get from such an arrangement, the problem is, that there seems to be no practical way for an intermediate router to verify an AH. There are at least two relevant cases where an intermediate router might want to check an AH: firewalls and to provide QOS protection -- both mentioned in rfc1825. The tunnelling approach doesn't look like a very promising solution (IP-AH-IP-AH-IP-AH-IP-AH-IP-AH-ULP ?) Did anyone look into public key mechanisms for AH? (especially into performance issues) Considering this, I think IP-AH-AH-ULP doesn't look too bad. Greetings, Uwe From majordom@p-o.ans.net Tue Jan 2 06:22:43 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA11057 (5.65c/IDA-1.4.4 for ); Tue, 2 Jan 1996 11:25:22 -0500 Received: by p-o.ans.net id AA30945 (5.65c/IDA-1.4.4 for ipsec-outgoing); Tue, 2 Jan 1996 16:23:11 GMT Message-Id: <199601021623.AA22168@interlock.ans.net> Date: Tue, 2 Jan 96 11:22:43 EST From: hugo@watson.ibm.com To: ho@cs.arizona.edu Cc: ipsec@ans.net Subject: I-D ACTION:draft-krawczyk-keyed-md5-01.txt Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Ref: Your note of Fri, 29 Dec 1995 18:11:48 -0700 (attached) Hilarie, > > Two minor comments. What is the reason for suggesting 1Gbyte as the > data volume limit? Do you mean to imply that if one were hashing a > 2Gbyte file, one should use two keys, or is the recommendation loosely > related to the time period of use or number of uses? This was a more-than-pesimistic bound that I made up to give a concrete number (from my experience people like to see concrete advise). Given than MD5 is not that fast, I believe that one can change keys after 1GByte (especially thinking of the AH scenario). In the case of a single file that is larger than 1Gbyte one may want to use only one key, and then the given bound may be unnecessarily restrictive. In the above number I wanted to take into account potential (yet unknown) weaknesses of MD5. For example, attakcs that would allow for easier collision finding than the "brute force" birthday attack. The latter is the best we know today against MD5 and it tells us that the probability to find collisions after processing q 512-bit blocks of data is about q^2/2^128. This means that after 1GByte of data (i.e., 2^24 blocks of 512 bits each) the known probability to break the function (via collisions) is 2^48/2^128 which gives an absolutely negligible probability of 2^{-80}. Even if you go to 2^49 bits of information, you get a probability of 2^{-48} to break the MAC. Another aspect to consider is that the proposed function is based on the assumption that the compression function of MD5 is a good MAC (i.e., a full output is unpredictable if you do not know the secret IV). Even if MD5 is far weaker in this respect than it is known today and one can predict the full output of the compression function with secret IV with, say, 2^-64 probability , still the probability to forge a MAC on a 1GByte file would be less than 2^{-30}. To summarize 1GByte is there for the sake of illustration, not as a firm upper bound on what one should hash with the same key. Possibly, today, hashing the whole Web with the same key would be still secure, but cryptographers got to be careful... > > Just for clarification, is it not possible that other modes of use > could provide equivalent security? You are simply saying that you have > proofs for your proposed scheme and not for others? > Yes, it is possible. There is no proof that the security of this function is the best possible achievable. WHat it is true (and claimed in the draft) is that it is backed by a significantly better analysis relative to other proposals. We do have analysis of other variants as well. For example, for a variant of RFC1828. However, the analysis is based on having two different keys there (the RFC uses the same key for prepend and append), it uses a stronger assumption on MD5 (being a strong pseudorandom function), and it does not preserve the quantitative security of the compression function as well as the new proposal does. (See [BCK1] for the analysis of the rfc1828-like function). My personal belief is that it will be extremely hard to give a construction that will rely on weaker assumptions than the one proposed in the new draft (though this is a "meta-claim" not a mathematical claim). Further comments, suggestions, and inter-operability tests are welcome. Hugo From majordom@p-o.ans.net Tue Jan 2 12:57:05 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14304 (5.65c/IDA-1.4.4 for ); Tue, 2 Jan 1996 12:57:05 -0500 Received: by p-o.ans.net id AA38821 (5.65c/IDA-1.4.4 for ipsec-outgoing); Tue, 2 Jan 1996 17:54:11 GMT Date: Tue, 02 Jan 96 09:33:33 From: "Housley, Russ" Encoding: 434 Text Message-Id: <9600028206.AA820604013@spysouth.spyrus.com> To: ipsec@ans.net Subject: draft-ietf-ipsec-skip-x509-00 Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net SKIP Authors: I encourage you to adopt the Version 3 X.509 certificate syntax. The PKIX working group is developing a profile for many Internet applications that uses this format. Also, if there are no certificate extensions used, the formats are almost identical. In fact, if none of the optional fields are present, the only difference is the version number. I encourage you to align with the PKIX effort. Russ From majordom@p-o.ans.net Tue Jan 2 12:59:11 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA12005 (5.65c/IDA-1.4.4 for ); Tue, 2 Jan 1996 12:59:11 -0500 Received: by p-o.ans.net id AA17095 (5.65c/IDA-1.4.4 for ipsec-outgoing); Tue, 2 Jan 1996 17:58:42 GMT Date: Tue, 02 Jan 96 09:33:38 From: "Housley, Russ" Encoding: 1315 Text Message-Id: <9600028206.AA820604018@spysouth.spyrus.com> To: ipsec@ans.net Subject: Re: AH and ESP Combinations Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Bill: >> Similarly, the combination of IP-ESP-AH-ULP or IP-AH-ESP-ULP isn't very >> sensible. Both of those should use IP-ESP-ULP with an ESP transform >> combining confidentiality with strong integrity. >> > I firmly disagree. > > Indeed, the whole point of separating AH from ESP was that the > authentication function should be separate and orthogonal to the > encryption function. I doubt that the WG would have ever gotten done > otherwise. > > Even when ESP provides integrity (and we do not have any such encryption > technique specified), there will still be a need for authentication > which is separate from the encryption. Your memory of the rationale does not track with mine. Several proposals were made that supported confidentiality and integrity with a single syntax, and much of the group was happy with this direction. The observation that these syntaxes we unfriendly to firewalls lead to the creation of AH. The firewall can easily locate the next protocol information in the AH syntax. When confidentiality is absent, in the ESP syntax, the firewall must know some details of the integrity algorithm to locate the next protocol information. In my opinion, without this firewall requirement, a single protocol (not two) would have emerged. Russ From majordom@p-o.ans.net Tue Jan 2 18:16:05 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14120 (5.65c/IDA-1.4.4 for ); Tue, 2 Jan 1996 13:19:06 -0500 Received: by p-o.ans.net id AA37735 (5.65c/IDA-1.4.4 for ipsec-outgoing); Tue, 2 Jan 1996 18:16:16 GMT Message-Id: <199601021816.NAA21359@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: ipsec@ans.net Subject: Re: AH and ESP Combinations In-Reply-To: Your message of "Tue, 02 Jan 1996 09:33:38." <9600028206.AA820604018@spysouth.spyrus.com> X-Reposting-Policy: redistribute only with permission Date: Tue, 02 Jan 1996 13:16:05 -0500 From: "Perry E. Metzger" Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net "Housley, Russ" writes: > Your memory of the rationale does not track with mine. Several proposals > were made that supported confidentiality and integrity with a single > syntax, and much of the group was happy with this direction. The > observation that these syntaxes we unfriendly to firewalls lead to the > creation of AH. Russ; ESP is not incapable of handling confidentiality with integrity in a combined transform. We specifically built it that way. AH is around only so that an integrity only transform remains viable in an environment where things need to peek into the headers, as you noted. > In my opinion, without this firewall requirement, a single protocol (not > two) would have emerged. I seriously doubt it. Firewalls aren't the only reason to retain flexibility the way we did. But in any case this is all long gone... Perry From majordom@p-o.ans.net Tue Jan 2 20:47:12 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA11114 (5.65c/IDA-1.4.4 for ); Tue, 2 Jan 1996 15:50:15 -0500 Received: by p-o.ans.net id AA22747 (5.65c/IDA-1.4.4 for ipsec-outgoing); Tue, 2 Jan 1996 20:47:47 GMT Message-Id: <199601022047.AA061335634@relay.hp.com> X-Mailer: exmh version 1.6.2 7/18/95 To: ipsec@ans.net Subject: Nesting AH/ESP/IP (was: ICMP Security Failures) In-Reply-To: rja's message of Mon, 01 Jan 1996 15:26:09 -0800. <9601012326.AA10622@rja-ss20.cisco.com.noname> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 02 Jan 1996 15:47:12 -0500 From: Bill Sommerfeld Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii In article <199512291507.QAA17151@cops.cert.dfn.de>, Ellerman@cert.dfn.de wrote: > With IP-AH-AH-ULP the sending host could generate one AH with the key > shared with the router and the other AH with a key shared with the > other host. IMHO, the intermediate router problem you outline is best solved by using IP-AH-IP-AH-ULP which is a VERY different beast from IP-AH-AH-ULP. It still isn't sure what value the receiver gets from such an arrangement versus the simpler IP-AH-ULP. Routing is dynamic in The Internet, so knowledge that the packet passed through some particular router with AH tunnelling setup isn't normally of use. I'm not sure whether your second paragraph here is referring to IP-AH-AH-ULP or IP-AH-IP-AH-ULP. If the latter: I see IP-AH-IP-AH-ULP being used in the "laptop-to-firewall" tunnelling scenario once IPSP begins to be deployed to hosts inside the firewall -- you'll have a mixture of hosts inside, some of which support IPSP, some of which don't, and for the latter, you want real end-to-end security if you can get it. As for what each receiver gets out of it: In such a situation, you're tunnelling all your traffic to your home net(s) through the firewall, and you probably want the laptop to administratively require that all traffic *from* your home net (which may or may not also have end-to-end authentication) is authenticated as coming via an authorized firewall. - Bill -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCUAwUBMOmZwlpj/0M1dMJ/AQF09QP4mI0cet0kbM8TBlIM3JjEDpHcwEJvspyG DvgZ0cplqjqF7IoX5ljeX8Rb9PFxplWEif+twF1k6mWdh/h+J/Q4wF/u923FYilo u5N0E+rIDGtqugGH6FjMVWe6Qv7U+8H8/910QQTHTn0MPZZtf5F6T9CHGOjevZWu MUgF0aMNNw== =AVUa -----END PGP SIGNATURE----- From majordom@p-o.ans.net Tue Jan 2 23:51:15 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA13530 (5.65c/IDA-1.4.4 for ); Tue, 2 Jan 1996 18:54:40 -0500 Received: by p-o.ans.net id AA17118 (5.65c/IDA-1.4.4 for ipsec-outgoing); Tue, 2 Jan 1996 23:51:31 GMT Date: Tue, 2 Jan 1996 15:51:15 -0800 From: Ran Atkinson Message-Id: <199601022351.PAA14331@puli.cisco.com> To: ipsec@ans.net Subject: Re: ESP and AH combinations Newsgroups: cisco.external.ietf.ipsec In-Reply-To: <199601020541.AAA20350@hiway1.exit109.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net In article <199601020541.AAA20350@hiway1.exit109.com>, David Wagner wrote: >Note that, when there's just one sender, it doesn't matter whether >the AH MAC covers the ip_src. (E.g. the receiver never examines >the ip_src field that came in over the wire, and always uses the >known-correct sender field associated with the appropriate SPI.) I'm not sure I'm following you here. Let me detail a scenario of what I think you are talking about before I comment... Consider that B is a receiver implementing IPsec. A and I are senders, each with its own Sec Assoc for AH having a destination of B. I transmits a packet to B with a forged Source Address of A, but using the SPI belonging to the I->A Security Association and a correctly calculated AH. I does this in order to attack B who trusts A more than B for some reason or to hijack a connection from A to B or some such reason. B receives this packet. If the receiving code checks the source address against the source address of the Security Association for the received SPI value (as I'd argue that it should and as the NRL implementation does; also see Craig Metz's note on this), then the packet gets discarded and the appropriate "received bogus packet" counter get incremented. There is no impersonation risk and attempts at forgery are detected and prevented. Are you suggesting that the receiver should instead accept the packet but change the source address to be I instead of A ?? If so, why is this preferable to the way the NRL implementation handles this ? If not, what were you suggesting for the desired behaviour ? >Therefore if you outlaw the "degenerate" case of multiple senders >(and I have no opinion on this subject), it certainly won't matter >whether the AH MAC covers the ip_src field or not. If the AH MAC doesn't cover the ip_src field, then I think that attempts at impersonation that are currently detected would not be detected. Or did I misunderstand you ? IMHO, it _is_ useful to know that impersonation is being attempted. Regards, Ran rja@cisco.com From majordom@p-o.ans.net Wed Jan 3 00:24:33 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA11054 (5.65c/IDA-1.4.4 for ); Tue, 2 Jan 1996 19:26:37 -0500 Received: by p-o.ans.net id AA06267 (5.65c/IDA-1.4.4 for ipsec-outgoing); Wed, 3 Jan 1996 00:24:46 GMT Date: Tue, 2 Jan 1996 17:24:33 -0700 From: Hilarie Orman Message-Id: <9601030024.AA20101@uncial.CS.Arizona.EDU> To: Ellermann@cert.dfn.de Cc: ipsec@ans.net In-Reply-To: Yourmessage <199601021514.QAA01330@cops.cert.dfn.de> Subject: Re: ICMP Security Failures Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net > Did anyone look into public key mechanisms for AH? (especially into > performance issues) You'd have to spend around 100 usec per packet (assuming a fast machine). It might be worthwhile for some configurations. I think a reserved SPI was suggested at one point. The SPI would have to indicate a transform defining all the mechanisms and formats for authenticating wrt to the sender. From majordom@p-o.ans.net Wed Jan 3 01:12:59 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA12706 (5.65c/IDA-1.4.4 for ); Tue, 2 Jan 1996 20:14:19 -0500 Received: by p-o.ans.net id AA17035 (5.65c/IDA-1.4.4 for ipsec-outgoing); Wed, 3 Jan 1996 01:13:08 GMT Date: Tue, 2 Jan 1996 17:12:59 -0800 From: Ran Atkinson Message-Id: <199601030112.RAA18304@puli.cisco.com> To: ipsec@ans.net Subject: Re: ICMP Security Failures Newsgroups: cisco.external.ietf.ipsec In-Reply-To: <9601030024.AA20101@uncial.CS.Arizona.EDU> References: <199601021514.QAA01330@cops.cert.dfn.de> Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net In a past article, Ellerman@cert.dfn.de wrote: >> Did anyone look into public key mechanisms for AH? (especially into >> performance issues) In article <9601030024.AA20101@uncial.CS.Arizona.EDU>, Hilarie Orman wrote: >You'd have to spend around 100 usec per packet (assuming a fast machine). >It might be worthwhile for some configurations. I think a reserved SPI >was suggested at one point. The SPI would have to indicate a transform >defining all the mechanisms and formats for authenticating wrt to the >sender. It was always intended that AH would work with asymmetric techniques by using a predefined SPI value that would indicate to the receiver(s) the asymmetric algorithm/AH transform in use. That AH transform would need to be defined in an RFC and the RFC would need to make clear where and how the appropriate Public Key certificate could be obtained. Purely as an example, one could define a transform for RSA using certificates obtained from the DNS via the methods defined in the DNSsec Internet Drafts. I did not spend any time on performance analysis myself, so it is interesting and useful to hear Hilarie's estimate on that. I can believe that such a transform might be useful in some environments, but I think most users would be reluctant to pay the performance penalty of an asymmetric algorithm given a choice. Ran rja@cisco.com From majordom@p-o.ans.net Wed Jan 3 06:49:55 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA11047 (5.65c/IDA-1.4.4 for ); Wed, 3 Jan 1996 01:54:01 -0500 Received: by p-o.ans.net id AA06245 (5.65c/IDA-1.4.4 for ipsec-outgoing); Wed, 3 Jan 1996 06:50:09 GMT Date: Wed, 3 Jan 1996 01:49:55 -0500 Message-Id: <199601030649.BAA01686@hiway1.exit109.com> X-Sender: mpwagner@hiway1.exit109.com X-Mailer: Windows Eudora Version 1.4.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipsec@ans.net From: daw@cs.berkeley.edu (David Wagner) Subject: Re: ESP and AH combinations Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net >B receives this packet. If the receiving code checks the source address >against the source address of the Security Association for the received SPI >value (as I'd argue that it should and as the NRL implementation does; also >see Craig Metz's note on this), then the packet gets discarded and the >appropriate "received bogus packet" counter get incremented. There is >no impersonation risk and attempts at forgery are detected and prevented. > >Are you suggesting that the receiver should instead accept the packet >but change the source address to be I instead of A ?? The implementation could do this; or it could check the ip_src field in the received packet against the expected value for that SPI. The implementation will be secure against impersonation either way. And it doesn't matter whether the AH MAC covers the ip_src field: the implementation can still provide secure source authentication in this scenario. (all in the one-sender case, of course) (Depending on your implementation's policy, it may consider a received packet with a ip_src field different from that expected as a security-critical impersonation attempt, or may simply ignore the incorrect ip_src field and use the known good src field for that SPI. It may consider a security-critical impersonation attempt as grounds to drop the packet, or it may simply fix up the ip_src field. This is true whether the AH MAC covers the ip_src field or not.) >If so, why >is this preferable to the way the NRL implementation handles this ? >If not, what were you suggesting for the desired behaviour ? It's not preferable. I was just trying to show that you can still build a secure implementation even if the AH MAC doesn't cover the ip_src field. (to be precise, in the one-sender case, since that's what you consider important) The preferable would come in if the AH MAC didn't cover the IP header, since then IP-AH-AH and IP-ESP-AH become feasible. But nevermind. >If the AH MAC doesn't cover the ip_src field, then I think that attempts at >impersonation that are currently detected would not be detected. Or did I >misunderstand you ? I believe they would still be detected; the result might simply be a mismatched ip_src field instead of a failed MAC verification. I think my old email is probably not worth a whole lot more time arguing over -- I hope I've explained it, even if I'm not gonna vehemently defend it anymore. I was trying to argue that the AH MAC didn't need to cover the ip_src field to be secure, but I guess I was being counter-productive and wasting people's time with a petty debate; for that I apologize. Let me cut your losses :-); let's move on & I'll accept the result either way without wasting more time on arguing. Maybe it'd be wiser to look at the broader issues Steve Bellovin raised in his last email to the list... (No, the only complaint I have now is ambiguity in the AH spec: I'd like to see a statement which says ``An AH header is only valid immediately following an IP header. Multiple AH transforms may be used only in tunnel mode. An IP-ESP-AH or IP-AH-AH packet is invalid; use IP-ESP-IP-AH or IP-AH-IP-AH instead.'' -- since that seems to be the direction the issue is going -- or a statement to the contrary, if the working group decides the other way. Just document the design decision in the spec, please.) P.S. My Obligatory Attempt at a Minimal Technical Contribution: Perhaps this will help clear up what I was trying to say about source addresses. The way I look at it, I see two logical source addresses: the "reply-to" address (which comes in off the wire as ip->ip_src), and the "authenticated-from" address (which comes from the local entry for the packet's SPI, assuming the AH MAC checks out ok). The "reply-to" & "authenticated-from" addresses don't necessarily have to always be the same in every implementation; in fact, there's no need for the "authenticated-from" address to be a true IP address! (thus my tentative proposal for using keys as "authenticated-from" values instead of IP addresses, for instance; other approaches may be far superior, especially when you take Steve Kent's comments into consideration) For security, we just need to ensure that all security-critical decisions use the "authenticated-from" address, and that the "authenticated-from" address is in fact cryptographically verified. One can still use the "reply-to" address to improve performance and/or route replies. In these terms, I was complaining (long ago) that the algorithm verify MAC on packet set "authenticated-from" = "reply-to" did not in fact provide the per-sender-granularity source-authentication you might expect when there are multiple senders, even if the ip->ip_src ("reply-to") field is covered by the AH MAC. But nevermind. Anyhow, if this "2-source-addr" point of view doesn't help you, ignore it. From majordom@p-o.ans.net Wed Jan 3 07:07:00 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA13456 (5.65c/IDA-1.4.4 for ); Wed, 3 Jan 1996 02:39:30 -0500 Received: by p-o.ans.net id AA19044 (5.65c/IDA-1.4.4 for ipsec-outgoing); Wed, 3 Jan 1996 07:34:57 GMT Date: Tue, 2 Jan 1996 23:07:00 -0800 (PST) From: Phil Karn Message-Id: <199601030707.XAA09478@servo.qualcomm.com> To: ipsec@ans.net In-Reply-To: <4689.bsimpson@morningstar.com> Subject: Re: AH/ESP & Replay Protection Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net >If the SPI uniquely determines the policy (as I've long advocated), >there would be no need to authenticate the CIPSO labels, either. I can conceive of attacks if the CIPSO labels aren't authenticated. Somebody could downgrade the CIPSO levels on legitimate packets (or strip them off entirely) on their way to a security gateway. Depending on its routing tables, said gateway might then decrypt the packet and send it in the clear over an insecure link where it would be subject to eavesdropping. Protecting the CIPSO label would ensure that the router understands the sensitivity of the packet so (assuming it is properly configured) it wouldn't go over an insecure link. Now I happen to think CIPSO is pretty much useless, as I could implicitly encode the security level in the SPI. But as long as *somebody* (anybody?) actually uses CIPSO, it should probably be protected. All this becomes moot in the ideal world where all IPSEC is done end-to-end. But since one of the major interim applications for IPSEC is in security gateways we might as well do it right. As for the other IP header fields, I've long felt that there's no point in authenticating them as I don't see any useful attacks that could come from changing invariant IP header fields other than CIPSO. But we've got a working method, and we should probably stick to it. Perhaps we need language in the AH spec that say you must update the IP header "on the fly" (particularly the length and protocol fields) when you build or disassemble a packet so that AH calculations at some intermediate stage are always done with the correct header. Phil From majordom@p-o.ans.net Wed Jan 3 07:40:32 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA12697 (5.65c/IDA-1.4.4 for ); Wed, 3 Jan 1996 02:41:00 -0500 Received: by p-o.ans.net id AA41605 (5.65c/IDA-1.4.4 for ipsec-outgoing); Wed, 3 Jan 1996 07:40:41 GMT Date: Tue, 2 Jan 1996 23:40:32 -0800 (PST) From: Phil Karn Message-Id: <199601030740.XAA09556@servo.qualcomm.com> To: rja@cisco.com Cc: ipsec@ans.net In-Reply-To: <199512291709.JAA07195@puli.cisco.com> (message from Ran Atkinson on Fri, 29 Dec 1995 09:09:06 -0800) Subject: Re: AH/ESP & Replay Protection Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net >One of the problems is figuring out what the effective protections were >on the data, passing that information to the policy engine, and informing >the application of what protections it got. Also, there is kernel bloat I don't really care whether incoming data was encrypted once I've decrypted it. That was the sender's decision. I *do* care if it was authenticated. That's why in my stack I pass up the SPI from AH but not from ESP (though I could do so if we add authentication to an ESP mode). AH and ESP are independent in this sense. >A conforming implementation doesn't have to support all of those modes. >There is a minimum set that is mandatory. Implementing more than that >is essentially a decision to add features. By contrast, my concern has >to do with items that are mandatory to implement. I guess I should have said I was more concerned about how to *name* all those modes in the key management protocol (consider Bill's already very long list of attributes in the Photuris spec) than by all the switch statements required in the ESP code itself to implement the various modes. Come up with a simple and orthogonal way to name the various orthogonal attributes of an ESP and I'll be happy. Perhaps the first few bits of the transform mode can be the IV length (0/32/64), the next few can define the authentication mode (MD5,MD5H [for Hugo], SHA-1, etc) , and the lion's share could be the encryption algorithm (DES,3DES,IDEA,SAFER,etc). Easy to allocate and easy to parse. Sound reasonable? Phil From majordom@p-o.ans.net Wed Jan 3 10:02:12 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14540 (5.65c/IDA-1.4.4 for ); Wed, 3 Jan 1996 05:04:13 -0500 Received: by p-o.ans.net id AA37812 (5.65c/IDA-1.4.4 for ipsec-outgoing); Wed, 3 Jan 1996 10:02:20 GMT Date: Wed, 3 Jan 1996 02:02:12 -0800 (PST) From: Phil Karn Message-Id: <199601031002.CAA09974@servo.qualcomm.com> To: ipsec@ans.net In-Reply-To: <9601012334.AA10647@rja-ss20.cisco.com.noname> Subject: Re: ESP and AH combinations Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net >Consider that there is a Security Association from S->D using AH, Keyed >MD5, and some secret key known only to S and D. D receives a packet >claiming to be from S, containing an Authentication Header with an >SPI refering to the above Sec Assoc. The AH checks on the receive >side pass. D now knows authentically that S sent the packet in >question. Unless S has given its key to somebody else who then uses S's address. You can certainly establish a policy against this but you have no way to enforce it. All you can really say when you get such a packet and the authentication checks is that whoever originally sent it knows the key. You don't know for sure it's S even if the source address is included in the authentication. A subtle difference perhaps, but occasionally an important one. Phil From majordom@p-o.ans.net Wed Jan 3 14:11:55 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA10508 (5.65c/IDA-1.4.4 for ); Wed, 3 Jan 1996 09:29:26 -0500 Received: by p-o.ans.net id AA22556 (5.65c/IDA-1.4.4 for ipsec-outgoing); Wed, 3 Jan 1996 14:23:13 GMT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@CNRI.Reston.VA.US Cc: ipsec@ans.net Subject: I-D ACTION:draft-simpson-esp-des1md5-00.txt Date: Wed, 03 Jan 96 09:11:55 -0500 Message-Id: <9601030911.aa10810@IETF.CNRI.Reston.VA.US> Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The ESP DES-CBC plus MD5 Transform Author(s) : P. Karn, P. Metzger, W. Simpson Filename : draft-simpson-esp-des1md5-00.txt Pages : 12 Date : 01/02/1996 This document describes use of DES-CBC for privacy, plus MD5 for integrity, in the IP Encapsulating Security Payload (ESP). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-simpson-esp-des1md5-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-simpson-esp-des1md5-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-simpson-esp-des1md5-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960102153209.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-simpson-esp-des1md5-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-simpson-esp-des1md5-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960102153209.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From majordom@p-o.ans.net Wed Jan 3 17:14:28 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA13691 (5.65c/IDA-1.4.4 for ); Wed, 3 Jan 1996 12:31:03 -0500 Received: by p-o.ans.net id AA13876 (5.65c/IDA-1.4.4 for ipsec-outgoing); Wed, 3 Jan 1996 17:26:46 GMT From: Lewis McCarthy Message-Id: <199601031714.MAA11822@gilling.cs.cornell.edu> Subject: Re: SPIs Passed to Apps (Was: Re: AH/ESP & Replay Protection) To: ipsec@ans.net Date: Wed, 3 Jan 1996 12:14:28 -0500 (EST) In-Reply-To: <199601030740.XAA09556@servo.qualcomm.com> from "Phil Karn" at Jan 2, 96 11:40:32 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1526 Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Ran Atkinson writes: # One of the problems is figuring out what the effective protections were # on the data, passing that information to the policy engine, and informing # the application of what protections it got. Phil Karn writes: > I don't really care whether incoming data was encrypted once I've > decrypted it. That was the sender's decision. In some cases, I think the receiver _will_ care whether or not the data was encrypted. Generally it is useful to know whether intermediaries in the route could have seen the information. That knowledge may affect how you choose to act upon the received data. (More precisely, I think it can be interesting to know that something was sent _unencrypted_, although it is probably not interesting to know that something was sent _encrypted_.) For example, if stranger Stacy sends me something purportedly very sensitive, but it arrives in the clear (possibly by design), then my suspicions are raised about the actual sensitivity of the data. Or suppose friend Fred asks me to do something that likely contravenes the ethics or laws of some of the ruling entities on my end of the wire. If I observe that his request was (accidentally ?) sent as plaintext, I have a chance to fire off a phony righteous rejection to him as a cover. > I *do* care if it was > authenticated. That's why in my stack I pass up the SPI from AH but > not from ESP (though I could do so if we add authentication to an ESP > mode). Perhaps passing the ESP SPI too is a good idea. -Lewis From majordom@p-o.ans.net Thu Jan 4 01:31:22 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA11916 (5.65c/IDA-1.4.4 for ); Wed, 3 Jan 1996 20:35:52 -0500 Received: by p-o.ans.net id AA41655 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 4 Jan 1996 01:31:31 GMT Date: Wed, 3 Jan 1996 17:31:22 -0800 (PST) From: Phil Karn Message-Id: <199601040131.RAA18361@servo.qualcomm.com> To: ipsec@ans.net In-Reply-To: <9601020749.aa13970@cs.nrl.navy.mil> (message from Craig Metz on Tue, 02 Jan 1996 07:48:27 -0500) Subject: Re: AH/ESP & Replay Protection Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net > Color me crazy, but shouldn't one of the first checks done when >input processing AH or ESP be to make sure that the src/dst pair on the >IP header and the security association line up? (If they don't match, then >the packet is bogus, if they do match, which one you check later is a moot >point) Otherwise, you're begging for replay problems... Nope. There's no IP address info at all in my security associations. Phil From majordom@p-o.ans.net Thu Jan 4 01:51:21 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA13483 (5.65c/IDA-1.4.4 for ); Wed, 3 Jan 1996 20:53:47 -0500 Received: by p-o.ans.net id AA06170 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 4 Jan 1996 01:51:30 GMT Date: Wed, 3 Jan 1996 17:51:21 -0800 From: Ran Atkinson Message-Id: <199601040151.RAA23650@puli.cisco.com> To: ipsec@ans.net Subject: Re: AH/ESP & Replay Protection In-Reply-To: <199601040131.RAA18361@servo.qualcomm.com> References: <9601020749.aa13970@cs.nrl.navy.mil> Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net In the past, Craig Metz wrote: % Color me crazy, but shouldn't one of the first checks done when % input processing AH or ESP be to make sure that the src/dst pair on the % IP header and the security association line up? (If they don't match, then % the packet is bogus, if they do match, which one you check later is a moot % point) Otherwise, you're begging for replay problems... In article <199601040131.RAA18361@servo.qualcomm.com> Phil Karn wrote: >Nope. There's no IP address info at all in my security associations. > >Phil Phil, It sounds like your implementation would be vulnerable to the attack I described earlier using A, B, and I. However, I suspect you might just have had a different approach to that problem. Would you care to comment on how your implementation would deal with that kind of attack if it doesn't keep track of which source addresses belong to which Security Associations ?? Ran rja@cisco.com From majordom@p-o.ans.net Thu Jan 4 02:27:11 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA13319 (5.65c/IDA-1.4.4 for ); Wed, 3 Jan 1996 21:33:15 -0500 Received: by p-o.ans.net id AA13891 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 4 Jan 1996 02:27:24 GMT Date: Wed, 3 Jan 1996 19:27:11 -0700 From: Hilarie Orman Message-Id: <9601040227.AA00190@uncial.CS.Arizona.EDU> To: rja@cisco.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <199601040151.RAA23650@puli.cisco.com> Subject: Re: AH/ESP & Replay Protection Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net > In the past, Craig Metz wrote: > % Color me crazy, but shouldn't one of the first checks done when > % input processing AH or ESP be to make sure that the src/dst pair on the > % IP header and the security association line up? (If they don't match, then > % the packet is bogus, if they do match, which one you check later is a moot > % point) Otherwise, you're begging for replay problems... > In article <199601040131.RAA18361@servo.qualcomm.com> Phil Karn wrote: > >Nope. There's no IP address info at all in my security associations. > > > >Phil > Phil, > It sounds like your implementation would be vulnerable to the > attack I described earlier using A, B, and I. However, I suspect you might > just have had a different approach to that problem. Would you care to > comment on how your implementation would deal with that kind of attack > if it doesn't keep track of which source addresses belong to which > Security Associations ?? Any message that is authenticated has some meaning; I'd thought that deciding whether or not that meaning is acceptable would be decided in the local policy, but I admit to puzzlement. The A, B, I attack is interesting, but it seems equally legitimate for A to say "I is sending me a message pretending to be B, what a discreet fellow he is" (sender anonymity). This interpretation seems a matter of local policy, albeit a rather complicated one. Another confusing point arises from the expanded notion of identity that the key exchange protocols present (beyond mere IP addresses). If you believe that the key speaks for "Bob", then it may not matter at all what source address it comes from --- the application receiving it may be happy enough to know that it is "Bob" and accept whatever source address he's using at the moment ("if it's good enough for Bob it's good enough for me"). Isn't this also a matter of local policy? From majordom@p-o.ans.net Wed Jan 3 16:32:28 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA11811 (5.65c/IDA-1.4.4 for ); Wed, 3 Jan 1996 21:47:43 -0500 Received: by p-o.ans.net id AA06273 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 4 Jan 1996 02:37:31 GMT Message-Id: <199601040237.AA06684@interlock.ans.net> From: smb@research.att.com To: Ran Atkinson Subject: Re: AH/ESP & Replay Protection Cc: ipsec@ans.net Date: Wed, 03 Jan 96 21:32:28 EST Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net > It sounds like your implementation would be vulnerable to the attack I > described earlier using A, B, and I. However, I suspect you might just > have had a different approach to that problem. Would you care to > comment on how your implementation would deal with that kind of attack > if it doesn't keep track of which source addresses belong to which > Security Associations ?? That's the whole point -- it doesn't matter. Trust is being granted on the basis of who knows the key, not which IP address it's coming from at the moment. This approach works, so long as you don't mix paradigms. That is, you can't accept rlogin, validated by a .rhosts file, unless you verify that all packets from that address are cryptographically protected. But a modified rlogind could check the key owner -- that is, the name in the certificate -- rather than the IP address, and decide that that machine was trusted to vouch for user names. From majordom@p-o.ans.net Thu Jan 4 04:24:56 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA10732 (5.65c/IDA-1.4.4 for ); Wed, 3 Jan 1996 23:26:41 -0500 Received: by p-o.ans.net id AA19190 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 4 Jan 1996 04:25:20 GMT Date: Wed, 3 Jan 1996 22:24:56 -0600 (CST) From: Todd Graham Lewis To: ipsec@ans.net Cc: smb@research.att.com Subject: Re: AH/ESP & Replay Protection In-Reply-To: <199601040237.AA06684@interlock.ans.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net On Wed, 3 Jan 1996 smb@research.att.com wrote: > > It sounds like your implementation would be vulnerable to the attack I > > described earlier using A, B, and I. However, I suspect you might just > > have had a different approach to that problem. Would you care to > > comment on how your implementation would deal with that kind of attack > > if it doesn't keep track of which source addresses belong to which > > Security Associations ?? > > That's the whole point -- it doesn't matter. Trust is being granted on > the basis of who knows the key, not which IP address it's coming from > at the moment. I would think this to be the more rational approach in general. If dependency on the originating address for security purposes is removed, then the de facto prohibition on source-routing would be eliminated, giving more flexibility in general IP structuring. > This approach works, so long as you don't mix > paradigms. Here's the rub. Perhaps this should be cleared up, for I was under the impression that identification of Security Associations was dependent upon the origin/destination|address/port dual-pair. > That is, you can't accept rlogin, validated by a .rhosts > file, unless you verify that all packets from that address are > cryptographically protected. But a modified rlogind could check the > key owner -- that is, the name in the certificate -- rather than the > IP address, and decide that that machine was trusted to vouch for > user names. > As I recall, a big bruhaha was had over the matter of cryptographic ID being done at the user-level, and not the host-level. If this is the plan, then key-knowledge alone should suffice for verification of ID; if it is not secure, what's the point? As smb said, put all your eggs in one basket and watch that basket. 8-) Plus, removing as many external dependencies as possible (e.g., telling implementors we _must_ be sure of the integrity of the originating IP#, so refuse source-routed frames) is a definite plus just as a matter of principle. Right? Todd Lewis todd@wooster.org From majordom@p-o.ans.net Thu Jan 4 05:33:53 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA13448 (5.65c/IDA-1.4.4 for ); Thu, 4 Jan 1996 00:35:15 -0500 Received: by p-o.ans.net id AA22597 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 4 Jan 1996 05:34:02 GMT Date: Wed, 3 Jan 1996 21:33:53 -0800 (PST) From: Phil Karn Message-Id: <199601040533.VAA18990@servo.qualcomm.com> To: rja@cisco.com Cc: ipsec@ans.net In-Reply-To: <199601040151.RAA23650@puli.cisco.com> (message from Ran Atkinson on Wed, 3 Jan 1996 17:51:21 -0800) Subject: Re: AH/ESP & Replay Protection Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net > It sounds like your implementation would be vulnerable to the >attack I described earlier using A, B, and I. However, I suspect you might >just have had a different approach to that problem. Would you care to >comment on how your implementation would deal with that kind of attack >if it doesn't keep track of which source addresses belong to which >Security Associations ?? What meaningful attack can be made against my implementation (once I actually implement application code that actually looks at the SPIs I so carefully pass upstairs, that is)? My application (which could include the IP routing code in the case of an authenticating firewall) won't act on an incoming packet, regardless of its source address, unless it is authenticated with a key that I trust. In fact, the only use I make of an incoming source address is as a destination for any packets I send in response. So the only thing you'd accomplish by modifying incoming source addresses is to steer my replies somewhere else. This is a denial of service attack, and there are many easier ways to accomplish the same thing. Phil From majordom@p-o.ans.net Thu Jan 4 05:39:41 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA11163 (5.65c/IDA-1.4.4 for ); Thu, 4 Jan 1996 00:40:13 -0500 Received: by p-o.ans.net id AA13924 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 4 Jan 1996 05:39:53 GMT Date: Wed, 3 Jan 1996 21:39:41 -0800 (PST) From: Phil Karn Message-Id: <199601040539.VAA18997@servo.qualcomm.com> To: ho@cs.arizona.edu Cc: rja@cisco.com, ipsec@ans.net In-Reply-To: <9601040227.AA00190@uncial.CS.Arizona.EDU> (message from Hilarie Orman on Wed, 3 Jan 1996 19:27:11 -0700) Subject: Re: AH/ESP & Replay Protection Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net >The A, B, I attack is interesting, but it seems equally legitimate for >A to say "I is sending me a message pretending to be B, what a >discreet fellow he is" (sender anonymity). This interpretation seems >a matter of local policy, albeit a rather complicated one. ooooh. I've been thinking for some time how I might build a network of anonymous "packet remailers" analogous to the existing network of anonymous remailers. This helps. Thanks! >If you believe that the key speaks for "Bob", then it may not matter >at all what source address it comes from --- the application receiving >it may be happy enough to know that it is "Bob" and accept whatever >source address he's using at the moment ("if it's good enough for Bob >it's good enough for me"). Isn't this also a matter of local policy? Exactly. Phil From majordom@p-o.ans.net Thu Jan 4 15:45:14 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA13701 (5.65c/IDA-1.4.4 for ); Thu, 4 Jan 1996 10:49:08 -0500 Received: by p-o.ans.net id AA06292 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 4 Jan 1996 15:44:53 GMT X-Sender: kent@eudora.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 4 Jan 1996 10:45:14 -0500 To: ipsec@ans.net From: Stephen Kent Subject: Re: AH/ESP & Replay Protection Cc: rja@cisco.com, ipsec@ans.net Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Hilarie, I don't believe that the issue of source address binding to an SA ought to be as open to local interpretation as you seem to suggest. Certainly, when using tunnel mode at a router, I think there is a serious security problem if one fails to bind and verify the source address with the SA. The receiving router may have made an appropriate access control decision when the SA was created, but there is no specified means ot passing the results of this decision back to hosts on a CAN behind the router, nor is there a means of maintaing the SA identification (e.g., via the SPI) on packets passed back to these hosts. Thus it is reasonable to assume that these hosts will continue to rely on the accuracy of purported IP source addresses (perhaps mapped to DNS names) to make local access control decisions. Under this assumption, which I believe is a representative one, we really need to have the encrypting router establish a binding of IP source address to an SA (or a set of SAs) when the SA is established, and to check the source address on each received packet. The situation is potentially different for hosts, because there can be tigher coupling between the authenticated identity info received as part of SA establishment and local access control policy, but even there it would seem that not imposing the same sort of binding is likely to result in vulnerabilities resulting from security management errors. I've seen this sort of problem arise before, in systems designed a decade ago, and I'd like to avoid it this time around. Steve From ipsec-owner@p-o.ans.net Thu Jan 4 16:24:15 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA11230 (5.65c/IDA-1.4.4 for ); Thu, 4 Jan 1996 11:26:27 -0500 Received: by p-o.ans.net id AA12464 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 4 Jan 1996 16:24:05 GMT X-Sender: kent@eudora.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 4 Jan 1996 11:24:15 -0500 To: ipsec@ans.net From: Stephen Kent Subject: Re: AH/ESP & Replay Protection Cc: rja@cisco.com, ipsec@ans.net Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Phil, I don't believe that your model for using "a key that I trust" really works well in an encrypting firewall context, for the reasons I cited in my most recent message. Even in the host context, the model you cite requires that the SPI be passed up to an application that must be coded to know what to do with it. One can get a lot of mileage out of an approach that merely lends crypographic strength to the paradigm that is commonly used today, i.e., access control decisions based on IP addresses or, preferably, based on DNS names that are mapped into addresses. (With the advent of DNS security, this latter approach would be fairly secure because of higher confidence in the binding between name and address.) If people are anxious to make use of IPSEC, it would seem that an approach which is more compatible with existing application code and access contorl paradigms would be preferable. Steve From ipsec-owner@p-o.ans.net Thu Jan 4 16:31:58 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA12009 (5.65c/IDA-1.4.4 for ); Thu, 4 Jan 1996 11:32:36 -0500 Received: by p-o.ans.net id AA22748 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 4 Jan 1996 16:32:08 GMT Date: Thu, 4 Jan 1996 08:31:58 -0800 From: Ran Atkinson Message-Id: <199601041631.IAA26934@puli.cisco.com> To: smb@research.att.com Subject: Re: AH/ESP & Replay Protection Cc: ipsec@ans.net Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Steve Bellovin, It sounds as if you think the definition of an IPsec Security Association should be modified/expanded to include the additional data needed to make such a decision. The current definition of an SA doesn't include enough data to work in the way you (and perhaps Hilarie ?) describe. This is something that can be fixed in the 1825-revision. I'd welcome a contribution of specific text for the 1825-revision to support the style of operation that you describe. Ran rja@cisco.com From ipsec-owner@p-o.ans.net Thu Jan 4 16:36:45 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA12577 (5.65c/IDA-1.4.4 for ); Thu, 4 Jan 1996 11:51:32 -0500 Received: by p-o.ans.net id AA12293 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 4 Jan 1996 16:38:10 GMT Date: Thu, 4 Jan 1996 08:36:45 -0800 From: Ran Atkinson Message-Id: <199601041636.IAA27074@puli.cisco.com> To: karn@qualcomm.com Subject: Re: AH/ESP & Replay Protection Cc: ipsec@ans.net Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Phil, If you checked the source address and sent replys back to the source address that does belong to that key then that particular denial of service attack is precluded with little implementation cost. Also, that attack would permit user 1 (who you normally trust enough to have a key on your system) to attack user 2 (who you also normally trust enough to have a key on your system) if you had a multi-user system. That the system separately trusts users 1 and 2 to use the system does NOT imply that user 1 and user 2 are not mutually antagonistic. Most routers are multi-user systems (for example, ciscos without TACACS are 2-user systems). Ran rja@cisco.com From ipsec-owner@p-o.ans.net Thu Jan 4 16:40:57 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA11046 (5.65c/IDA-1.4.4 for ); Thu, 4 Jan 1996 11:52:41 -0500 Received: by p-o.ans.net id AA19742 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 4 Jan 1996 16:41:00 GMT Date: Thu, 4 Jan 1996 11:40:57 -0500 Message-Id: <9601041640.AA01170@MAILSERV-H.FTP.COM> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipsec@ans.net From: naganand@ftp.com (Naganand Doraswamy) Subject: Re: AH/ESP & Replay Protection Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net >> Color me crazy, but shouldn't one of the first checks done when >>input processing AH or ESP be to make sure that the src/dst pair on the >>IP header and the security association line up? (If they don't match, then >>the packet is bogus, if they do match, which one you check later is a moot >>point) Otherwise, you're begging for replay problems... > >Nope. There's no IP address info at all in my security associations. > >Phil > > How would you figure out which SA or key to use on the sending side? Dont we have to search for SA based on the tuple? Thanks, --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)659-6743 (O) From ipsec-owner@p-o.ans.net Thu Jan 4 18:19:30 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA12779 (5.65c/IDA-1.4.4 for ); Thu, 4 Jan 1996 13:22:29 -0500 Received: by p-o.ans.net id AA40148 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 4 Jan 1996 18:19:45 GMT Date: Thu, 4 Jan 1996 10:19:30 -0800 From: Ran Atkinson Message-Id: <199601041819.KAA01168@puli.cisco.com> To: karn@qualcomm.com Subject: Re: AH/ESP & Replay Protection Cc: ipsec@ans.net Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net % >One of the problems is figuring out what the effective protections were % >on the data, passing that information to the policy engine, and informing % >the application of what protections it got. Also, there is kernel bloat % % I don't really care whether incoming data was encrypted once I've % decrypted it. That was the sender's decision. I *do* care if it was % authenticated. That's why in my stack I pass up the SPI from AH but % not from ESP (though I could do so if we add authentication to an ESP % mode). AH and ESP are independent in this sense. Phil, I understand that you personally don't care. I also understand that you believe that encryption is always a sender-only policy, however I disagree with that notion about or restriction on policy. There are cases where the receiver insists that the sender use encryption and this is practical to implement (NRL's code is an existence proof). In short, I as a user often do care about whether the sender is using encryption and I'm not alone. One of the features of the NRL implementation is that an application can require bidirectional encryption for a session. In the common case of a telnet/ftp session, I might want encryption even if I'm the person requesting the data from the other side (e.g. I might not want other folks to know what data I'm getting from an otherwise public ftp server). With the NRL implementation, the TCP connection won't get established if the other side doesn't use encryption in sending to me and if the other side suddenly stops using encryption, my end will drop the TCP session as a direct result. This is a feature, IMHO. Ran rja@cisco.com From ipsec-owner@p-o.ans.net Thu Jan 4 18:44:11 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA11025 (5.65c/IDA-1.4.4 for ); Thu, 4 Jan 1996 13:46:50 -0500 Received: by p-o.ans.net id AA27327 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 4 Jan 1996 18:44:22 GMT Date: Thu, 4 Jan 1996 10:44:11 -0800 From: Ran Atkinson Message-Id: <199601041844.KAA02463@puli.cisco.com> To: ipsec@ans.net Subject: ADMIN: Straw Poll on Key Mgmt Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net All, During the Dallas IETF meeting, Jeff Schiller (Security AD) posed several questions that the IPsec WG needed to reach consensus on. Consensus on these issues is not entirely clear to the WG co-chairs, so we are holding a straw poll on them to try to clarify the consensus. This isn't a formal vote so we're looking for consensus rather than counting votes. We are measuring the consensus of the active part of the WG, which is approximately the set of folks who contribute to the list or attend WG meetings. It is not the intent of this poll that people engage in argument or flame wars on the list over these issues. We're just trying to figure out whether there is WG consensus at present on these issues. 1) Can the IPsec WG produce multiple standards-track protocols for key management ? 2) If yes to the above, then can a protocol not conforming to the WG requirements for a key management protocol be on the IETF standards-track ? 3) If yes to both of the above, should the WG chairs write up a formal applicability statement to be accompany each standards-track key management protocol so that the intended use of that protocol is made clear? (This last is similar to the way routing protocols always have an applicability statement published.) Your views, preferably as short answers to the above questions, should be sent to both of the co-chairs via email. Yours, Paul Lambert Randall Atkinson From ipsec-owner@p-o.ans.net Thu Jan 4 19:07:40 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA10585 (5.65c/IDA-1.4.4 for ); Thu, 4 Jan 1996 14:08:23 -0500 Received: by p-o.ans.net id AA16963 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 4 Jan 1996 19:07:05 GMT Date: Thu, 4 Jan 1996 14:07:40 -0500 From: pau@watson.ibm.com Message-Id: <9601041907.AA13334@secpwr.watson.ibm.com> To: ipsec@ans.net Subject: Re: AH/ESP & Replay Protection Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: i8TDKXd4VkSNir4l9ZMoRg== Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net As a person who has done an IPSEC implementation, I certainly agree with Ran. One more header, coupled with the use of either transport or tunnel mode encapsulation, is going to make the code rather complex and ugly and hard to test and debug. Pau-Chen > Date: Tue, 26 Dec 1995 10:08:21 -0800 > From: Ran Atkinson > To: ipsec@ans.net > Subject: Re: AH/ESP & Replay Protection > Content-Length: 638 > Status: RO > > [Personal opinion] > > All, > > I am concerned about the potentially exponential increase in header > combinations that would be encouraged by having a separate replay > protection header. > > I'd MUCH rather see a trend towards ESP transforms that provide more > capabilities (such as the combined transform that provides both > integrity and confidentiality) than towards more headers. > > Ignoring other concerns for the moment, implementation complexity increases > a lot when there are multiple headers that are interacting. The greater > the implementation complexity, the higher the probability of interoperability > problems. > > Regards, > > Ran > rja@cisco.com From ipsec-owner@p-o.ans.net Thu Jan 4 19:16:35 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA12647 (5.65c/IDA-1.4.4 for ); Thu, 4 Jan 1996 14:16:46 -0500 Received: by p-o.ans.net id AA21380 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 4 Jan 1996 19:16:21 GMT Date: Thu, 4 Jan 1996 14:16:35 -0500 From: pau@watson.ibm.com Message-Id: <9601041916.AA12834@secpwr.watson.ibm.com> To: ipsec@ans.net Subject: Re: ICMP Security Failures Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: MdG3v5PvFI/MfQpiXZXeug== Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net > Date: Wed, 27 Dec 1995 16:23:36 -0500 > From: Craig Metz > Message-Id: <9512271623.aa07357@cs.nrl.navy.mil> > Sender: ipsec-owner@ans.net > Precedence: bulk > Reply-To: ipsec@ans.net > Content-Length: 481 > Status: RO > > In message <9512271952.AA19612@uncial.CS.Arizona.EDU>, Hilarie Orman writes: > >Some combinations may not be possible, due to ambiguities in > >processing order. For example, IP-AH-AH or IP-ESP-AH. > > I think IP-AH-AH is valid, though maybe not very useful. You > would process those in order, i.e., the first AH would cover the payload, > and the second AH would cover the first AH and the payload. > > I don't think IP-ESP-AH is valid -- it would have to be IP-ESP-IP-AH. > > -Craig I think IP-ESP-AH-IP is valid. We did it all the time in our lab. We also do IP-AH-ESP and other combinations, of course. I suspect this is more an implementation issue as how many different combinations an implementation is able to handle. Regards, Pau-Chen From ipsec-owner@p-o.ans.net Thu Jan 4 14:32:37 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA11897 (5.65c/IDA-1.4.4 for ); Thu, 4 Jan 1996 14:32:37 -0500 Received: by p-o.ans.net id AA16125 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 4 Jan 1996 19:31:08 GMT Message-Id: Date: 4 Jan 1996 14:26:34 U From: "FreedmanJ" Subject: RE: ADMIN: Straw Poll on Key Mgmt To: ipsec@ans.net X-Mailer: Mail*Link SMTP-MS 3.0.2 Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Unknown Microsoft mail form. Approximate representation follows. To: ipsec@ans.net From: FreedmanJ on Thu, Jan 4, 1996 2:26 PM Subject: RE: ADMIN: Straw Poll on Key Mgmt RFC Header:Received: by mail.ndhm.gtegsc.com with SMTP;4 Jan 1996 14:23:19 U Received: from p-o.ans.net by delphi.ndhm.gtegsc.com with SMTP; Thu, 4 Jan 1996 14:22:06 -0500 (EST) Received: by p-o.ans.net id AA27327 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 4 Jan 1996 18:44:22 GMT Date: Thu, 4 Jan 1996 10:44:11 -0800 From: Ran Atkinson Message-Id: <199601041844.KAA02463@puli.cisco.com> To: ipsec@ans.net Subject: ADMIN: Straw Poll on Key Mgmt Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net 1) Can the IPsec WG produce multiple standards-track protocols for key management ? YES - There needn't be the ONE,TRUE,Standard 2) If yes to the above, then can a protocol not conforming to the WG requirements for a key management protocol be on the IETF standards-track ? YES - see above 3) If yes to both of the above, should the WG chairs write up a formal applicability statement to be accompany each standards-track key management protocol so that the intended use of that protocol is made clear? YES Jerry Freedman,Jr From ipsec-owner@p-o.ans.net Thu Jan 4 20:12:56 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA13800 (5.65c/IDA-1.4.4 for ); Thu, 4 Jan 1996 15:16:24 -0500 Received: by p-o.ans.net id AA06294 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 4 Jan 1996 20:13:08 GMT Date: Thu, 4 Jan 1996 13:12:56 -0700 From: Hilarie Orman Message-Id: <9601042012.AA32169@uncial.CS.Arizona.EDU> To: kent@BBN.COM Cc: ipsec@ans.net In-Reply-To: Yourmessage Subject: Re: AH/ESP & Replay Protection Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net With regard to a bogus source address, the tunneling router might be assigned the job of changing the source address to help out the hosts behind it, so there might well be legitimate uses even in that scenario. The heart of the second issue seems to be that the WG never agreed the meaning of the principals for IPSEC. There seems to be a strong sentiment for leaving the issue open and allowing "alice@anyhost", for example, to be the identity tied to a security association. There is an equally strong sentiment to the contrary, that IP addresses are the only allowable principals; a related faction thinks that "alice@192.59.13.2" is meaningful. I agree that all mistakes from 10 years ago should be avoided. There's certainly enough rope in the current architecture to allow us all to hang ourselves. I think a "standard modes of use" appendix would be helpful, but I'm not sure that inserting "non-acceptable modes of use" is the most useful step at this point. From ipsec-owner@p-o.ans.net Thu Jan 4 16:27:47 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA13735 (5.65c/IDA-1.4.4 for ); Thu, 4 Jan 1996 16:27:47 -0500 Received: by p-o.ans.net id AA22716 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 4 Jan 1996 21:25:17 GMT To: ipsec@ans.net From: cfm@columbia.sparta.com (carl f. muckenhirn) Subject: Re: ADMIN: Straw Poll on Key Mgmt Date: Thu, 4 Jan 1996 17:30:05 LOCAL Message-Id: Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net In article Ran Atkinson writes: >Date: Thu, 4 Jan 1996 10:44:11 -0800 >From: Ran Atkinson >To: ipsec@ans.net >Subject: ADMIN: Straw Poll on Key Mgmt >Reply-To: ipsec@ans.net > > 1) Can the IPsec WG produce multiple standards-track > protocols for key management ? > Certainly. > 2) If yes to the above, then can a protocol not conforming > to the WG requirements for a key management protocol > be on the IETF standards-track ? > I don't think so, if it doesn't meet the requirements for a Key Management Protocol (tm) then it isn't a key management protocol. Supporting, in as a standards track protocol, something which doesn't meet our self defined needs seems to me to lead to more confusion than good. This isn't to say that a protocol for managing "key-like entities" which doesn't do eveything in a Key Management Protocol (tm), is not useful for some purposes. Or alternatively, the current consensus definition of a Key Management Protocol (tm) could be changed to include (or exclude) the "non-conforming" aspects such a claimed protocol. > 3) If yes to both of the above, should the WG chairs write up a formal > applicability statement to be accompany each standards-track > key management protocol so that the intended use of that protocol > is made clear? I think that this is a good thing regardless of the answer to the above two questions. Key Management and security in general is quite confusing to many people, a statement of intended uses and applicability should be included in all standards. carl. From ipsec-owner@p-o.ans.net Fri Jan 5 00:12:25 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14153 (5.65c/IDA-1.4.4 for ); Thu, 4 Jan 1996 19:16:15 -0500 Received: by p-o.ans.net id AA15589 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 5 Jan 1996 00:12:48 GMT X-Sender: kent@eudora.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 4 Jan 1996 19:12:25 -0500 To: Hilarie Orman From: Stephen Kent Subject: authenticated source addresses Cc: ipsec@ans.net Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Hilarie, I took the liberty of changing the subject field in my response since we are not really talking about AH and ESP and replay protection! Let me try to state my concerns and views in a somewhat different perspective. I'll restrict my comments to one case, in which the endpoints of the SAs in question are encrypting routers, which are operating in tunneling mode. Pardon the extensive narrative, but I want to minimize the potential for confucion. Assume (wlog) that the encapsulation being used is IP-AH-ESP-IP-ULP. Let's call one router A, one router B, and one router C. Hosts served by each of these (encrypting) routers are identified by adding a number after the letter that identifies the router, e.g., A1 or C3. Now, assume that two SAs (SA1 and SA2) are established: the first between A and B and the second between B and C. When each SA is established, some identity information is exchanged between the two router in question, so that B, the common endpoint for these two SAs does know the identities of the corresponding routers. The security policy for B must view both A and C as legitimate sources of traffic to the net(s) behind B, otherwise the SAs would not have been established. Now, if the IPSEC implementation at B does not do any checking on the sources addresses for the encapsulated IP packets it receives (after verifying the AH and decrypting the ESP), the following scenario can arise. Host A1 can send traffic to host B1 via SA1. Host C1 can send traffic to B1 via SA2. Host B1 might accord the traffic from A1 and C1 different access permissions, e.g., grant access to some files to A1 and access to different files to C1. However, A1 also can send traffic that carries the IP address of C1 and when the traffic is recived via SA1 there would be no check to detect this and reject such traffic. Thus, it would be possible for A1 to send traffic to B1 that appears to be from C1 and thus to be granted access to files that A1 is not authorized to access (but which C1 is authorized to access). True, return traffic from B1 that is directed to C1 would not be delivered to A1, but Bellovin noted long ago how, even with a lack of the reverse traffic, A1 can successfully generate appropriate TCP ACKs to establish and maintain the connection. This would seem to be a very plausible scenario and if IPSEC does not include mandatory facilities in encryption routers to allow a site security manager to prevent such attacks, I think we will be viewed by the community as having failed to address a major set of common scenarios. The solution is simply to require that every SA has associated with it some source address checking mechanism, the granularity of which is a side effect of the SA establishment process. If packets are sourced by a router, the the checking might be against a mask for an IP address (or set of addresses), whereas for a host source the check should be against an indiviaul address. Finer granularity ID and access control is not going to be available at an encrypting router endpoint in a fashion that is meaningfully passed on to hosts served by the router, at least not based on current paradigms. If the scenario is changed to enbody only host endpoints, one can do lots of things, if applications are modified to deal with new ID and access control facilities and appropriate info is passed up from SA establishment and for each received packet. However, I expect significant use of these protocols in conjunction with routers and thus I think it critical to adopt a uniform capability for the sort of source address checking for tunnel mode as described above. Also, just for perspective, the pesudo-MIB I wrote and submitted to this list over a year ago, to stimumate discussion on what parameters needed to be associated with an SA, embodied precisely this facility. Steve From ipsec-owner@p-o.ans.net Fri Jan 5 02:56:53 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14242 (5.65c/IDA-1.4.4 for ); Thu, 4 Jan 1996 22:08:05 -0500 Received: by p-o.ans.net id AA14358 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 5 Jan 1996 02:54:51 GMT Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 04 Jan 1996 18:56:53 -0800 From: John Kennedy To: ipsec@ans.net Cc: rja@cisco.com, palambert@us.oracle.com Subject: ADMIN: Straw Poll on Key Mgmt -Reply Content-Length: 3129 Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Here are some not-to-short answers to the Straw Poll Questions. 1) Can the IPsec WG produce multiple standards-track protocols for key management ? With the never ending "religious wars" that seem to be raging, this would seem to be one way of letting the market choose the winner. Is their any precedent for doing this kind of thing? I'm also confused by the phrasing of the question, ie., did you mean SHOULD when you said CAN? 2) If yes to the above, then can a protocol not conforming to the WG requirements for a key management protocol be on the IETF standards-track? Let's take the example of, oh let's say..., SKIP and the issue of whether or not it meets the requirement of providing Perfect Forward Secrecy required by the WG requirements. If the requirement was re-phrased to say the the key management protocol must provide a mechanism for achieving PFS, but not necessarily impose the requirement in all instantiations of said protocol, that might make it easier it accept SKIP. Further, if a mechanism similar to the SKIP certificate discovery protocol was added that would OPTIONALLY allow the introduction of ephemeral data into the Diffie-Hellman calculation, then SKIP might then meet the requirements of the working group. It also leaves the issue of how much forward secrecy to provide to the implementor and the particular application. (I.e., if I don't want to pay for the computational overhead, etc., I don't have to. But if I do want PFS, I can easily get it) I guess I didn't exactly answer the question with a YES or NO, but rather was pointing a possible problem with the requirements. I could also get into a discussion on "What are the most-likely threat models", but let me just say that I'm not crazy about anyone dictating to me, through a key management protocol or otherwise, what my most-likely threat is. Give me a mechanism that can be configured to address various threats using OPTIONAL features and parameters, and I'll make my own educated decision based on application, business requirements, cost, level of paranoia, value of information, political climate, export rules, phase of the moon, etc. 3) If yes to both of the above, should the WG chairs write up a formal applicability statement to be accompany each standards-track key management protocol so that the intended use of that protocol is made clear? Again, I would point back to the WG requirements and see if perhaps they need to be re-stated. Adjectives like "perfect" and "absolute" do not realistically apply to real-world security problems or solutions. Nor do such requirements necessarily take into account real-world economics. For example, implementing a protocol that supposedly insures "Perfect Forward Secrecy" without also mandating the implementation of the proverbial "Perfect Random Number Source" is not realistic. (I used SKIP and PFS as an example here, but there are other aspects of the candidate protocols that might prove to be sticking points when it comes to WG requirements.) -John Kennedy, CYLINK Corporation jkennedy@cylink.com From ipsec-owner@p-o.ans.net Fri Jan 5 04:28:28 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14802 (5.65c/IDA-1.4.4 for ); Fri, 5 Jan 1996 00:21:39 -0500 Received: by p-o.ans.net id AA22664 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 5 Jan 1996 05:13:24 GMT Date: Fri, 5 Jan 96 04:28:28 GMT From: "William Allen Simpson" Message-Id: <4705.bsimpson@morningstar.com> To: ipsec@ans.net Subject: Re: authenticated source addresses Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net > From: Stephen Kent > I took the liberty of changing the subject field in my response > since we are not really talking about AH and ESP and replay protection! > THANK YOU! > When each SA is established, some identity > information is exchanged between the two router in question, so that B, the > common endpoint for these two SAs does know the identities of the > corresponding routers. The security policy for B must view both A and C as > legitimate sources of traffic to the net(s) behind B, otherwise the SAs > would not have been established. > So far, so good. You have established an assumption that the only control that B asserts is "access" to the net(s). > Host B1 might accord the traffic from A1 and C1 different > access permissions, e.g., grant access to some files to A1 and access to > different files to C1. However, A1 also can send traffic that carries the > IP address of C1 and when the traffic is recived via SA1 there would be no > check to detect this and reject such traffic. But, by your assumption, the SA1 is not designed to restrict access to some files and not to others. That is a different policy, the responsibility of B1. The policies are orthogonal. > Thus, it would be possible > for A1 to send traffic to B1 that appears to be from C1 and thus to be > granted access to files that A1 is not authorized to access (but which C1 > is authorized to access). How is this different from the network without the firewall? Although the analysis appears to be thorough, it does not take into account that B1 is not asking (or even aware of) the firewall. It therefore cannot depend on firewall policy to protect it from spoofing. There is no communication of policy between B and B1. The firewall policy is not designed to protect against spoofing. It has established a level of trust for A and C, and only as to "access" to members of B for members of A and C. This would be even more clear for A1 spoofing A2. Since A1 and A2 both use the same SA1 (in your example), there would be no method to detect that the sources did not match. If B1 requires protection from spoofing, it should incorporate IPSEC itself. IP addresses are an inadequeate form of authentication. That is one of the reasons that Photuris does not rely on IP addresses [page 1]: Internet Security does not place any significance on easily forged IP Source addresses. It relies instead on proof of possession of secret knowledge: that is, a cryptographic key. 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-owner@p-o.ans.net Fri Jan 5 06:04:42 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA11581 (5.65c/IDA-1.4.4 for ); Fri, 5 Jan 1996 01:11:24 -0500 Received: by p-o.ans.net id AA21319 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 5 Jan 1996 06:04:51 GMT Date: Thu, 4 Jan 1996 22:04:42 -0800 (PST) From: Phil Karn Message-Id: <199601050604.WAA29329@servo.qualcomm.com> To: rja@cisco.com Cc: ipsec@ans.net In-Reply-To: <199601041819.KAA01168@puli.cisco.com> (message from Ran Atkinson on Thu, 4 Jan 1996 10:19:30 -0800) Subject: Re: AH/ESP & Replay Protection Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Ran, I fully understand that you may want the other end to use encryption to talk to you. I want that myself. The answer to this is to ensure that whatever key management protocol you use (including manual key establishment) allows you to request encryption by the remote node. But it isn't particularly helpful to implement a local mechanism to reject unencrypted packets. Whatever damage that resulted from the packet having been sent in the clear is not undone by rejecting it at the receiver. The damage has already been done. It admit it *would* be useful to report to your local application and/or user that cleartext packets are arriving against your wishes so you can decide to abort the session to avoid requesting the further damaging transmission of cleartext information, at least until you can fix the problem. But this is still an orthogonal issue to ensuring that you don't accept unauthenticated information from unknown hosts. Phil From ipsec-owner@p-o.ans.net Fri Jan 5 06:59:40 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA11950 (5.65c/IDA-1.4.4 for ); Fri, 5 Jan 1996 02:07:53 -0500 Received: by p-o.ans.net id AB16963 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 5 Jan 1996 06:59:49 GMT Date: Thu, 4 Jan 1996 22:59:40 -0800 (PST) From: Phil Karn Message-Id: <199601050659.WAA29458@servo.qualcomm.com> To: rja@cisco.com Cc: ipsec@ans.net In-Reply-To: <199601041636.IAA27074@puli.cisco.com> (message from Ran Atkinson on Thu, 4 Jan 1996 08:36:45 -0800) Subject: Re: AH/ESP & Replay Protection Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net > If you checked the source address and sent replys back to >the source address that does belong to that key then that particular >denial of service attack is precluded with little implementation cost. Here I thought you were one of the people clamoring loudly for user-oriented keying! I want to travel with my laptop and be able to access my home network transparently wherever I go, using whatever local IP address I happen to get. As long as I have the correct AH key to get through my security gateway this should be allowed. I.e., the AH key is assigned to the user (me), not to my IP address. Phil From ipsec-owner@p-o.ans.net Fri Jan 5 07:09:20 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14780 (5.65c/IDA-1.4.4 for ); Fri, 5 Jan 1996 02:15:43 -0500 Received: by p-o.ans.net id AA21653 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 5 Jan 1996 07:09:37 GMT Date: Thu, 4 Jan 1996 23:09:20 -0800 (PST) From: Phil Karn Message-Id: <199601050709.XAA29490@servo.qualcomm.com> To: kent@bbn.com Cc: ipsec@ans.net, rja@cisco.com In-Reply-To: (message from Stephen Kent on Thu, 4 Jan 1996 11:24:15 -0500) Subject: Re: AH/ESP & Replay Protection Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Steve, I think I understand what you're saying. But it goes against the model I and many others have had from the beginning of IPSEC, which is to grant access permissions to the bearer of a key (e.g., a person), not to IP addresses. I touched on this point in the message I just sent in which I talked about traveling with a notebook computer that may use many different IP addresses. It would be most inconvenient to have to make special arrangements for each new IP address as I move. Consider an Annex terminal server that gives me a dynamically allocated IP address every time I call in to my local service provider. So I really want a mechanism that lets me in regardless of my source IP address as long as I have the proper AH key. Phil From ipsec-owner@p-o.ans.net Fri Jan 5 07:17:24 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA11717 (5.65c/IDA-1.4.4 for ); Fri, 5 Jan 1996 02:21:44 -0500 Received: by p-o.ans.net id AA19141 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 5 Jan 1996 07:17:36 GMT Date: Thu, 4 Jan 1996 23:17:24 -0800 (PST) From: Phil Karn Message-Id: <199601050717.XAA29504@servo.qualcomm.com> To: naganand@ftp.com Cc: ipsec@ans.net In-Reply-To: <9601041640.AA01170@MAILSERV-H.FTP.COM> (naganand@ftp.com) Subject: Re: AH/ESP & Replay Protection Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net >How would you figure out which SA or key to use on the sending side? Dont we >have to search for SA based on the tuple? That's a local implementation issue. Here's how I do it in KA9Q: Just before IP fragmentation in the IP output routine I insert a call to a routine that searches the local security association table for the given destination IP address. If I don't find an entry, nothing unusual happens; the packet goes out normally. If I do find an entry I insert ESP and/or AH depending on which modes are set for the security association. (If both modes are set, AH is "outside" ESP). Then the packet continues on its way. The search stops at the first security association found for the specific IP destination. That is, there can be only one active security association for any IP destination at any one time. Then again, my stack is a simple one designed for single-user environments or standalone router/tunnel applications. It's not UNIX. If it were, I'd provide means to tie different security associations for the same destination to different processes. Phil From ipsec-owner@p-o.ans.net Fri Jan 5 07:47:35 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA12014 (5.65c/IDA-1.4.4 for ); Fri, 5 Jan 1996 02:54:53 -0500 Received: by p-o.ans.net id AA15479 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 5 Jan 1996 07:47:45 GMT Date: Thu, 4 Jan 1996 23:47:35 -0800 (PST) From: Phil Karn Message-Id: <199601050747.XAA29589@servo.qualcomm.com> To: ipsec@ans.net Cc: ho@cs.arizona.edu, ipsec@ans.net In-Reply-To: (message from Stephen Kent on Thu, 4 Jan 1996 19:12:25 -0500) Subject: Re: authenticated source addresses Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Steve, I think you're stretching the functionality of IPSEC on a router beyond what it's intended to do. You say almost as much in your message. I see IPSEC in a firewall router as an expedient way to separate "us" (my internal corporate network) from "them" (the rest of the Internet) while still having the option to extend membership in my corporate network to certain authorized people who happen to be connected to the outside network. If they have the right keys, they're authorized; I don't care what IP addresses they use, especially since they may change rapidly at the whim of their local provider. It am not nearly as concerned about internal firewalling, though perhaps I should be. If I were, I would be pushing harder to get this stuff into all my hosts; it's simply not an appropriate thing to put into a firewall. But your comments do point out the responsibility that an IPSEC tunneling gateway assumes whenever it encapsulates an "ordinary" packet from some non-IPSEC host. In my own code I already pass an interface label tag up with the packet that I will eventually use in making routing decisions. I may designate certain interfaces as "red", meaning I'll accept (and encapsulate) any traffic from that interface without prior authentication. Packets arriving on "black" (external) interfaces would be unprivileged by default, and would have to carry a valid AH header to gain any privileges. I understand the attraction some feel for going one step further and enforcing correct source addresses on the packets received on the "red" interfaces. But I've already made the assumption that hosts on these interfaces can be trusted at least somewhat; if I can't then I have bigger problems. Ultimately these can be solved only by implementing IPSEC on all the hosts, which is where it does belong in the long run. Phil From ipsec-owner@p-o.ans.net Fri Jan 5 12:36:32 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA13370 (5.65c/IDA-1.4.4 for ); Fri, 5 Jan 1996 09:14:13 -0500 Received: by p-o.ans.net id AA21310 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 5 Jan 1996 13:36:49 GMT Message-Id: <9601051336.AA17422@cichlid.raleigh.ibm.com> To: ipsec@ans.net Subject: Re: AH/ESP & Replay Protection In-Reply-To: Your message of "Wed, 03 Jan 1996 17:31:22 PST." <199601040131.RAA18361@servo.qualcomm.com> Date: Fri, 05 Jan 1996 08:36:32 -0400 From: "Thomas Narten" Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net >> Color me crazy, but shouldn't one of the first checks done when >>input processing AH or ESP be to make sure that the src/dst pair on the >>IP header and the security association line up? (If they don't match, then >>the packet is bogus, if they do match, which one you check later is a moot >>point) Otherwise, you're begging for replay problems... >Nope. There's no IP address info at all in my security associations. To further muddy things a bit: What if we're talking about multicast destinations rather than unicast? In general, the members of a group won't know who all the other members are, and conseqently won't know the unicast (source) addresses of all members (not to mention that the actual number of members could be HUGE). A new member joining a group could obtain the group's SPI info from any other member of the group (or a designated group member) without coordinating with all group members as a whole. Or is multicast going to be a special case exempt from a source address check? Thomas From ipsec-owner@p-o.ans.net Fri Jan 5 14:31:48 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA12725 (5.65c/IDA-1.4.4 for ); Fri, 5 Jan 1996 10:20:50 -0500 Received: by p-o.ans.net id AA39982 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 5 Jan 1996 14:48:35 GMT Date: Fri, 5 Jan 96 14:31:48 GMT From: "William Allen Simpson" Message-Id: <4707.bsimpson@morningstar.com> To: ipsec@ans.net Subject: Re: ADMIN: Straw Poll on Key Mgmt Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net > From: Ran Atkinson > 1) Can the IPsec WG produce multiple standards-track > protocols for key management ? > Certainly. But only to Proposed Standard. So, you have to bite the bullet and make a decision sometime. > 2) If yes to the above, then can a protocol not conforming > to the WG requirements for a key management protocol > be on the IETF standards-track ? > Absolutely not! > 3) If yes to both of the above, should the WG chairs write up a formal > applicability statement to be accompany each standards-track > key management protocol so that the intended use of that protocol > is made clear? > Even though I didn't say yes to both of the above, the WG chairs can write whatever they want, just like any other WG member. That doesn't mean that it gets published. Meanwhile, I will include an applicability statement in the next Photuris draft. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-owner@p-o.ans.net Fri Jan 5 15:23:24 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA10686 (5.65c/IDA-1.4.4 for ); Fri, 5 Jan 1996 10:28:31 -0500 Received: by p-o.ans.net id AA21488 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 5 Jan 1996 15:23:44 GMT Date: Fri, 5 Jan 1996 09:23:24 -0600 (CST) From: Todd Graham Lewis To: ipsec@ans.net Cc: rja@cisco.com, ipsec@ans.net Subject: Re: AH/ESP & Replay Protection In-Reply-To: <199601050604.WAA29329@servo.qualcomm.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net On Thu, 4 Jan 1996, Phil Karn wrote: > Ran, > > But it isn't particularly helpful to implement a local mechanism to > reject unencrypted packets. Whatever damage that resulted from the > packet having been sent in the clear is not undone by rejecting it at > the receiver. The damage has already been done. -----------------^ I disagree with this. If, for example, I establish both channels in a telnet session and my machine dumps the packets on the return channel because they are not encrypted, then I am not going to get far enough to check my e-mail over a non-encrypted link. This is a simple example, but I think that dumping non-encrypted packets is definitely a reasonable option. Of course, this need not simply be "silent" discarding -- the information could be passed up the stack and I could be notified of the reason that I am not seeing any info on my screen, but I think the decision is a potentially valid one nonetheless. > It admit it *would* be useful to report to your local application > and/or user that cleartext packets are arriving against your wishes so > you can decide to abort the session to avoid requesting the further > damaging transmission of cleartext information, at least until you can > fix the problem. There are still situations, such as e.g. the automated telnet applications for router configuration and reporting included in UMich's MRT package, where one would have a need for non-encrypted traffic to be dumped because simple notification will not do. This is a reasonable decision for a host administrator to make on a host-wide basis -- we will not pass to applications cleartext information. Todd Lewis todd@wooster.org From ipsec-owner@p-o.ans.net Fri Jan 5 06:17:45 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA13372 (5.65c/IDA-1.4.4 for ); Fri, 5 Jan 1996 11:23:06 -0500 Received: by p-o.ans.net id AA15421 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 5 Jan 1996 16:17:56 GMT Date: Fri, 5 Jan 96 11:17:45 EST From: cmadson@baynetworks.com (Cheryl Madson) Message-Id: <9601051617.AA13559@pobox.BayNetworks.com> To: ipsec@ans.net Subject: Re: AH/ESP & Replay Protection Cc: cmadson@baynetworks.com, narten@VNET.IBM.COM Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net > Or is multicast going to be a special case exempt from a source address check? I think this is going to have to be the case. This is an example where possession of a group key infers "validity of membership" only, without any assumptions made to the sender's identity. Some (TBD) mechanism will need to make the decision of who is allowed to get this key, along with how. [I've been more-or-less mulling over this issue for some time now, but I haven't had the cycles to seriously work on it (just enough to make noises periodically ;-). But incorporating group ACLs really need to be a part of this, IMO.] As a side note: I would think an authentication transform which incoporated both "proving identity of sender" along with "proving possion of group key" would be desirable (I guess it would be a keyed MD5 using the group key, the result of which would be signed by the sender's private key). This could reduce the source address spoofing risk here, where valid member A masqueredes as valid member B. If one or more receivers didn't care about who sent the packet, the MD5 with the group key would be enough. If one of the receivers *did* care, it could also check the signature. [I guess the group creator could say that this transform was "desirable", but I don't think the creator can force both levels of checking on all receivers.] - C From ipsec-owner@p-o.ans.net Fri Jan 5 16:21:58 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14657 (5.65c/IDA-1.4.4 for ); Fri, 5 Jan 1996 11:23:29 -0500 Received: by p-o.ans.net id AA13147 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 5 Jan 1996 16:21:39 GMT X-Sender: kent@eudora.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 5 Jan 1996 11:21:58 -0500 To: ipsec@ans.net From: Stephen Kent Subject: Re: authenticated source addresses Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Bill, When an SA terminates at a router, we are limited in what the router can do in terms of security policy enforcement. It does not make sense to talk about a security policy for the SA relative to file access on hosts, because file access is mediated by hosts at the application layer. At best, the router can support the host file access control mechanisms by ensuring certain properties of the traffic that passes through the router. The most obvious such property is the accuracy of IP source addresses. However, as you noted, there are limits to the granularity of address accuracy that the router can ensure. If other SA endpoint is an individual host, then key management can ensure the accuracy of the source ID at the granularity of a single host. (This is where the indivdiual user vs. host keying argument arises. For a single user host, the two levels of ID are effectively the same, although there can be important differences depending on the type of addressing used with mobility. For a multi-user host, the situation is analogous to that of a router as an SA endpoint.) If the other SA endpoint is another router, then the other router capable of emitting traffic with any of a range of addresses for the hosts served by that router. (Hence, traffic from A1 and A2 cannot be distinguished at B based on SA controls.) This is the price we pay for multiplexing at this layer. I disagree with some of the assertions in your message: >Although the analysis appears to be thorough, it does not take into >account that B1 is not asking (or even aware of) the firewall. It >therefore cannot depend on firewall policy to protect it from spoofing. >There is no communication of policy between B and B1. >The firewall policy is not designed to protect against spoofing. It has >established a level of trust for A and C, and only as to "access" to >members of B for members of A and C. B1 can aware of the encrypting router, even though there is no explicit communication between B and B1. There is a difference between those two assertions. As part of my local security policy, I can rely on source addresses to be accurate (at some granularity) even if there is no explicit communication between the router and the hosts. Clearly, this requires some care in configuration management ate the router, especially if non-authenticated traffic is allowed through the router. Existing products have addresses this by configuring address tables to reject any non-authenticated traffic with certain addresses (address ranges) because any traffic from those addresses must, by local policy, be authenticated. Yes, the ideal approach would be for hosts servied by B to implement IPSEC and thus verify data origin authentication at B1, B2, etc. However, this implies nesting of IPSEC headers (thus adding a further bandwith penalty) and performing multiple transformations (e.g., two passes with a hash function on two slightly different packets). It also adds complexity to IPSEC implementations, especially in routers, to know when additional layers of encapsulation are required for outbound traffic and when to stop processing headers on inbound traffic. (Considering the possible choices for hosts and routers implementing IPSEC or not, at both source and destination, and eliminating combinations that offer no security, there are 9 possible combinations, each of which requires slightly different processing.) Finally, yes, one can take a minimalist view of the security policy being enforced by the router and say that evey entity authorized to connect via AH/ESP is authorized to send traffic with any source address. However, I think that explicitly encouring such a policy, by not requiring support for more secure policies, would be a disservice to the community. IP addresses are easily spoofed in the existing Internet, but one of the goals of IPSEC work is to improve on this situation. While IP addresses may not be the ideal forms of ID for bind time authentication, they do represent the only form of ID that is passed to hosts when an SA terminates at a router, and thus they are reasonable candidates for continuous authentication under such circumstances. Steve From ipsec-owner@p-o.ans.net Fri Jan 5 16:32:42 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA11946 (5.65c/IDA-1.4.4 for ); Fri, 5 Jan 1996 12:05:08 -0500 Received: by p-o.ans.net id AA16026 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 5 Jan 1996 16:33:03 GMT Date: Fri, 5 Jan 1996 08:32:42 -0800 From: Ran Atkinson Message-Id: <199601051632.IAA26934@puli.cisco.com> To: karn@qualcomm.com Subject: Re: AH/ESP & Replay Protection Cc: ipsec@ans.net Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net % I fully understand that you may want the other end to use encryption % to talk to you. I want that myself. The answer to this is to ensure % that whatever key management protocol you use (including manual key % establishment) allows you to request encryption by the remote node. % % But it isn't particularly helpful to implement a local mechanism to % reject unencrypted packets. Whatever damage that resulted from the % packet having been sent in the clear is not undone by rejecting it at % the receiver. The damage has already been done. Phil, The local mechanism I described _prevents_ an unencrypted TCP connection from ever becoming established when the connection originator has set the policy to "MUST encrypt both ways". That means the "damage" has NOT been done because the TCP connection isn't UP. So it IS a very practical method of applying that policy from the receiver of the data. % It admit it *would* be useful to report to your local application % and/or user that cleartext packets are arriving against your wishes so % you can decide to abort the session to avoid requesting the further % damaging transmission of cleartext information, at least until you can % fix the problem. The application tells the kernel that it "MUST have bidirectional encryption" and the kernel enforces it below TCP, so the session never gets established. This is important. If the TCP session _were_ to get established then the problem you pose might occur, but it cannot occur in the NRL implementation because the kernel enforces the policy requested by the application below TCP and the TCP connection never gets into the established state. % But this is still an orthogonal issue to ensuring that you don't % accept unauthenticated information from unknown hosts. A similar mechanism exists. The NRL implementation permits an application to insist that only authenticated packets be accepted for that application. Again, enforcement of this policy occurs within IP and so if that policy has been requested by the application via a Sockets call, then the TCP connection cannot ever get into the established state. Another nice feature of the NRL implementation is that the system admin can also set a minimum system security level that will be enforced by the kernel. If the application-requested security level is different from the system security level, the most paranoid configuration wins. (Those working with MLS systems can hook Multi-level encryption policy into the system security level code without too much trouble; we thought about that also even though our code is in no way MLS and doesn't implement CIPSO). Ran rja@cisco.com From ipsec-owner@p-o.ans.net Fri Jan 5 16:35:14 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA11715 (5.65c/IDA-1.4.4 for ); Fri, 5 Jan 1996 12:11:19 -0500 Received: by p-o.ans.net id AA13261 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 5 Jan 1996 16:40:58 GMT Date: Fri, 5 Jan 1996 08:35:14 -0800 From: Ran Atkinson Message-Id: <199601051635.IAA26985@puli.cisco.com> To: karn@qualcomm.com Subject: Re: AH/ESP & Replay Protection Cc: ipsec@ans.net Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net % > If you checked the source address and sent replys back to % >the source address that does belong to that key then that particular % >denial of service attack is precluded with little implementation cost. % % Here I thought you were one of the people clamoring loudly for % user-oriented keying! Absolutely I am. The check above is not expensive to make and reduces risk. I don't claim it eliminates denial of service attacks, just closes the door somewhat at little cost. % I want to travel with my laptop and be able to access my home network % transparently wherever I go, using whatever local IP address I happen % to get. As long as I have the correct AH key to get through my % security gateway this should be allowed. I.e., the AH key is assigned % to the user (me), not to my IP address. I believe you can do this using Mobile IPv4 whilst still checking IP source address validity by tunnelling the packets while mobile. Its possible they broke the Mobile IP spec additionally since I last read it, but this definitely used to work. Ran rja@cisco.com From ipsec-owner@p-o.ans.net Fri Jan 5 16:04:46 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA11774 (5.65c/IDA-1.4.4 for ); Fri, 5 Jan 1996 12:54:11 -0500 Received: by p-o.ans.net id AA43255 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 5 Jan 1996 17:20:05 GMT Date: Fri, 5 Jan 96 16:04:46 GMT From: "William Allen Simpson" Message-Id: <4711.bsimpson@morningstar.com> To: ipsec@ans.net Subject: Re: AH/ESP & Replay Protection Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net I agree with Phil, and I don't understand your model: > From: Todd Graham Lewis > On Thu, 4 Jan 1996, Phil Karn wrote: > > But it isn't particularly helpful to implement a local mechanism to > > reject unencrypted packets. Whatever damage that resulted from the > > packet having been sent in the clear is not undone by rejecting it at > > the receiver. The damage has already been done. > > I disagree with this. If, for example, I establish both channels in a > telnet session and my machine dumps the packets on the return channel > because they are not encrypted, Both channels in a telnet session? Are there more than one? I usually think of the TCP stream as a single bi-directional session. Maybe you mean security associations in both directions, since they are uni-directional (destination based)? > then I am not going to get far enough to > check my e-mail over a non-encrypted link. This is a simple example, but > I think that dumping non-encrypted packets is definitely a reasonable option. > This is somewhat strange to me. You have telnet'd in to check your email. You have established an incoming security association. The host you are accessing decides that the traffic (the fact that you have 3 messages) is not protected information, and sends it in the clear. Your stack throws aways the TCP packet, because it was not encrypted. Instead, you get a message on your screen saying "unencrypted traffic tossed". At this point, you don't know you have 3 messages, but everyone else on the net does. What have you gained? Now, this is extremely theoretical. It is unlikely that the policy engine is that subtle, to distinguish from context whether to encrypt some bytes and not others. So, I don't see what this tossing could _ever_ buy you.... > There are still situations, such as e.g. the automated telnet applications > for router configuration and reporting included in UMich's MRT package, > where one would have a need for non-encrypted traffic to be dumped > because simple notification will not do. This is a reasonable decision > for a host administrator to make on a host-wide basis -- we will not pass > to applications cleartext information. > I suppose it depends on your practical desire. Is it to get the reporting information (which is probably not worth encrypting), or is it to toss data on the floor? As Phil noted, the damage has already been done. Put me in the "getting the data" camp. Notification will at least tell you that there is a configuration problem. And you have the added bonus that your net application won't fail in the middle of router configuration. 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-owner@p-o.ans.net Fri Jan 5 18:02:15 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA10585 (5.65c/IDA-1.4.4 for ); Fri, 5 Jan 1996 13:31:20 -0500 Received: by p-o.ans.net id AA14566 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 5 Jan 1996 18:19:03 GMT X-Sender: kent@eudora.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 5 Jan 1996 13:02:15 -0500 To: Phil Karn From: Stephen Kent Subject: Re: AH/ESP & Replay Protection Cc: ipsec@ans.net, rja@cisco.com Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Phil, I appreciate your point with regard to mobility, and I expect to be an IPSEC user from a laptop, so I am personally interested in the functionality. However, I hate to see us loose an important security facility for non-mobile use of IPSEC because of this problem. I think we need to put some more effort into figuring out how to accommodate both sets of users without degrading security services, e.g., being able to distinguish between fixed and mobile users and dealing with source address screening accordingly. Steve From ipsec-owner@p-o.ans.net Fri Jan 5 19:13:55 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA11719 (5.65c/IDA-1.4.4 for ); Fri, 5 Jan 1996 14:27:06 -0500 Received: by p-o.ans.net id AA14422 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 5 Jan 1996 19:14:08 GMT Date: Fri, 5 Jan 1996 11:13:55 -0800 From: Ran Atkinson Message-Id: <199601051913.LAA05788@puli.cisco.com> To: ipsec@ans.net Subject: Re: AH/ESP & Replay Protection Newsgroups: cisco.external.ietf.ipsec In-Reply-To: <4711.bsimpson@morningstar.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net In article <4711.bsimpson@morningstar.com> you write: >I agree with Phil, and I don't understand your model: > >> From: Todd Graham Lewis >> On Thu, 4 Jan 1996, Phil Karn wrote: >> > But it isn't particularly helpful to implement a local mechanism to >> > reject unencrypted packets. Whatever damage that resulted from the >> > packet having been sent in the clear is not undone by rejecting it at >> > the receiver. The damage has already been done. >> >> I disagree with this. If, for example, I establish both channels in a >> telnet session and my machine dumps the packets on the return channel >> because they are not encrypted, > >Both channels in a telnet session? Are there more than one? I usually >think of the TCP stream as a single bi-directional session. > >Maybe you mean security associations in both directions, since they are >uni-directional (destination based)? > > >> then I am not going to get far enough to >> check my e-mail over a non-encrypted link. This is a simple example, but >> I think that dumping non-encrypted packets is definitely a reasonable option. >> >This is somewhat strange to me. You have telnet'd in to check your >email. You have established an incoming security association. The host >you are accessing decides that the traffic (the fact that you have 3 >messages) is not protected information, and sends it in the clear. > >Your stack throws aways the TCP packet, because it was not encrypted. >Instead, you get a message on your screen saying "unencrypted traffic >tossed". No. Let me try to restate. Such a telnet connection NEVER becomes "established" because the system that you are telnet'ing into is not sending you encrypted packets and your originating telnet application has told the kernel via BSD Sockets (or similar API) that this session "MUST have bidirectional encryption". Hence, the login never occurs and the email is never sent over the wire at all, so there is no data sent cleartext. >At this point, you don't know you have 3 messages, but everyone else on >the net does. What have you gained? >Now, this is extremely theoretical. It is unlikely that the policy >engine is that subtle, to distinguish from context whether to encrypt >some bytes and not others. So, I don't see what this tossing could >_ever_ buy you.... It buys a lot: The originator of the session sets the policy. The tossing ensures that the security level requested by the session originator is enforced and the session never happens if the remote system is uncooperative and doesn't provide at least the needed security. Note that the responder of the session can require a more restrictive policy. If the responder requires more than the originator provides, the session aqain never gets established because the responder will drop the originators packets for that session. This method ensures that no data will be moved unless it is at least as protected as the more paranoid of the originator's requirement and the responder's requirement. This has been implemented and tested in the NRL implementation already available for anonymous ftp. It works fine. >> There are still situations, such as e.g. the automated telnet applications >> for router configuration and reporting included in UMich's MRT package, >> where one would have a need for non-encrypted traffic to be dumped >> because simple notification will not do. This is a reasonable decision >> for a host administrator to make on a host-wide basis -- we will not pass >> to applications cleartext information. >> >I suppose it depends on your practical desire. Is it to get the >reporting information (which is probably not worth encrypting), or is it >to toss data on the floor? As Phil noted, the damage has already been >done. No, the damage has NOT been done because if the router weren't encrypting its TCP packets back to the originator, the TCP session would never get into the ESTABLISHED state. Hence, no sensitive user data could leak. Ran rja@cisco.com From ipsec-owner@p-o.ans.net Fri Jan 5 20:12:11 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14138 (5.65c/IDA-1.4.4 for ); Fri, 5 Jan 1996 15:15:52 -0500 Received: by p-o.ans.net id AA04794 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 5 Jan 1996 20:13:01 GMT From: hsw@columbia.sparta.com (Howard Weiss) Message-Id: <9601052012.AA00935@katahdin.columbia.sparta.com> Subject: Re: authenticated source addresses To: ipsec@ans.net Date: Fri, 5 Jan 1996 15:12:11 -0500 (EST) In-Reply-To: from "Stephen Kent" at Jan 4, 96 07:12:25 pm Organization: SPARTA Inc. (Secure Systems Engineering Division) Usmail: 9861 Broken Land Parkway, Suite 300, Columbia MD 21046 Phone: (410) 381-9400 x201 Fax: (410) 381-5559 X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3121 Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Steve Kent wrote: > > ... stuff removed for brevity ... > > Now, if the IPSEC implementation at B does not do any checking on the > sources addresses for the encapsulated IP packets it receives (after > verifying the AH and decrypting the ESP), the following scenario can arise. > Host A1 can send traffic to host B1 via SA1. Host C1 can send traffic to > B1 via SA2. Host B1 might accord the traffic from A1 and C1 different > access permissions, e.g., grant access to some files to A1 and access to > different files to C1. However, A1 also can send traffic that carries the > IP address of C1 and when the traffic is recived via SA1 there would be no > check to detect this and reject such traffic. Thus, it would be possible > for A1 to send traffic to B1 that appears to be from C1 and thus to be > granted access to files that A1 is not authorized to access (but which C1 > is authorized to access). True, return traffic from B1 that is directed to > C1 would not be delivered to A1, but Bellovin noted long ago how, even with > a lack of the reverse traffic, A1 can successfully generate appropriate TCP > ACKs to establish and maintain the connection. But isn't it actually the source router's responsibility to ensure that the "correct" IP address (e.g. an IP address of a host served by it and no others) is placed into the upper-most IP src address field? In this paradigm, Router A would not allow host A1 to place address C1 into an IP header which is then encrypted and authenticated by Router A. The way the check is made up front - the packet recipient knows that when AH and ESP are scrapped off that an authentic packet has been received - at least from a host served by Router A. There is still the problem of some host masquerading as another one within the set of hosts served by Router A (e.g., host A1 masquerading as host A5), but one might assume that there is some trust within an enclave of machines. What we are getting back to, through this discussion, is the age-old network security question of identifying the end-points of a connection and how to enforce a security policy based on those end-points. If the end-points are at encrypting routers (as in Steve's scenario), then the routers are acting as glorified link encryptors protecting the data on the "virtual" wire between them. The hosts behind such routers can only be assured that the payload data has not been tampered with or compromised on the virtual wire, and nothing more! One cannot be assured that one of the "good" hosts behind the router has not become one of the "bad" hosts. Howie ________________________________________________________________________ | | | Howard Weiss phone (410) 381-9400 x201 | | SPARTA, Inc. (301) 621-8145 x201 (DC)| | 9861 Broken Land Parkway, suite 300 fax: (410) 381-5559 | | Columbia, MD 21046 email: hsw@columbia.sparta.com| |________________________________________________________________________| From ipsec-owner@p-o.ans.net Fri Jan 5 15:16:13 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA11839 (5.65c/IDA-1.4.4 for ); Fri, 5 Jan 1996 15:16:13 -0500 Received: by p-o.ans.net id AA43216 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 5 Jan 1996 20:15:48 GMT Date: Fri, 05 Jan 96 11:56:57 From: "Housley, Russ" Encoding: 945 Text Message-Id: <9600058208.AA820871817@spysouth.spyrus.com> To: ipsec@ans.net Subject: Re: ADMIN: Straw Poll on Key Mgmt Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Here are my opinions. 1) Can the IPsec WG produce multiple standards-track protocols for key management ? Yes. There are several approaches, and each of them has merit. 2) If yes to the above, then can a protocol not conforming to the WG requirements for a key management protocol be on the IETF standards-track ? I think that each solution has merit, and that the documents should state clearly what security services are provided. This may be difficult with approaches that can use more than one algorithm since each algorithm may offer slightly different capabilities. 3) If yes to both of the above, should the WG chairs write up a formal applicability statement to be accompany each standards-track key management protocol so that the intended use of that protocol is made clear? Yes. I think that is basically what I sai in response to #2 above. --Russ From ipsec-owner@p-o.ans.net Fri Jan 5 20:17:51 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14660 (5.65c/IDA-1.4.4 for ); Fri, 5 Jan 1996 15:18:51 -0500 Received: by p-o.ans.net id AA19186 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 5 Jan 1996 20:18:18 GMT From: hsw@columbia.sparta.com (Howard Weiss) Message-Id: <9601052017.AA00958@katahdin.columbia.sparta.com> Subject: Re: ADMIN: Straw Poll on Key Mgmt To: ipsec@ans.net Date: Fri, 5 Jan 1996 15:17:51 -0500 (EST) In-Reply-To: <199601041844.KAA02463@puli.cisco.com> from "Ran Atkinson" at Jan 4, 96 10:44:11 am Organization: SPARTA Inc. (Secure Systems Engineering Division) Usmail: 9861 Broken Land Parkway, Suite 300, Columbia MD 21046 Phone: (410) 381-9400 x201 Fax: (410) 381-5559 X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1324 Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net > 1) Can the IPsec WG produce multiple standards-track > protocols for key management ? Yes > 2) If yes to the above, then can a protocol not conforming > to the WG requirements for a key management protocol > be on the IETF standards-track ? No - if it doesn't meet the WG requirements it should not go forward. There are two "quick" fixes - either the protocol is changed to meet the requirements, or the requirements are changed. > 3) If yes to both of the above, should the WG chairs write up a formal > applicability statement to be accompany each standards-track > key management protocol so that the intended use of that protocol > is made clear? I guess I don't get to answer this one since I didn't vote yes for both of the above. Howard Weiss ________________________________________________________________________ | | | Howard Weiss phone (410) 381-9400 x201 | | SPARTA, Inc. (301) 621-8145 x201 (DC)| | 9861 Broken Land Parkway, suite 300 fax: (410) 381-5559 | | Columbia, MD 21046 email: hsw@columbia.sparta.com| |________________________________________________________________________| From ipsec-owner@p-o.ans.net Fri Jan 5 23:52:35 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA11803 (5.65c/IDA-1.4.4 for ); Fri, 5 Jan 1996 18:59:38 -0500 Received: by p-o.ans.net id AA04671 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 5 Jan 1996 23:51:55 GMT X-Sender: kent@eudora.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 5 Jan 1996 18:52:35 -0500 To: ipsec@ans.net From: Stephen Kent Subject: Re: authenticated source addresses Cc: ipsec@ans.net Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Howie, The source routers in my examples (A and C) are not prssumed to be within the administrative purview of B, so relying on them to screen addresses is not a good security assumption. As Bill pointed out, we have to rely on them to correctly identify hosts that each of them serves, but we ought not have to rely on them to not emit packets from other addresses. While I agree with Phil and Bill that having the SAs terminate at hosts provides the preferred solution and gives one greater options in terms of the form of ID used for A/C decisions, I hesitate to expect/require that solution in many instances, especially when one factors in the additional performance and complexity issues I cited. Still, Phil is right that simple, uniform address screening at the router causes problems for mobile users and we need to be able to accommodate such users. Steve From ipsec-owner@p-o.ans.net Sat Jan 6 14:23:07 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14703 (5.65c/IDA-1.4.4 for ); Sat, 6 Jan 1996 10:02:43 -0500 Received: by p-o.ans.net id AA14583 (5.65c/IDA-1.4.4 for ipsec-outgoing); Sat, 6 Jan 1996 14:59:53 GMT Date: Sat, 6 Jan 96 14:23:07 GMT From: "William Allen Simpson" Message-Id: <4717.bsimpson@morningstar.com> To: ipsec@ans.net Subject: privacy policy example Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Here's an example that might better illustrate why a datagram model is better than a session model: I start a telnet session. My host has no particular policy set for this destination. It starts the TCP handshake without any authentication or encryption. I get to the password prompt. My application policy engine recognizes that the data I am about to type needs to be secret. It requests privacy, but without the "high-assurance" cpu-intensive priority flag. The transport engine initiates a Photuris exchange, and requests an ESP-DES SPI. It then sends the protected data. I see the number of messages that I have outstanding. The telnet server does not have policy that this is private, and sends it in the clear, despite the fact that we have a "serendipitous" return SPI established (Photuris gives an initial SPI in each direction, even though you only request it in one direction). I then read a message. It turns out to be a "PGP -steam" message, which is eyes-only. The pgp application requests high-assurance privacy, and the transport engine requests an ESP-3DES SPI from my system. It then sends the data back to me. Conclusion: Orthogonality of policy determination gives us flexibility and elegance. Without the terrible WWW burden of dozens of separate TCP "mice" sessions for simple data transfers. 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-owner@p-o.ans.net Sat Jan 6 13:31:22 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14189 (5.65c/IDA-1.4.4 for ); Sat, 6 Jan 1996 10:02:43 -0500 Received: by p-o.ans.net id AA19958 (5.65c/IDA-1.4.4 for ipsec-outgoing); Sat, 6 Jan 1996 14:59:50 GMT Date: Sat, 6 Jan 96 13:31:22 GMT From: "William Allen Simpson" Message-Id: <4716.bsimpson@morningstar.com> To: ipsec@ans.net Subject: Re: AH/ESP & Replay Protection Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net > From: Ran Atkinson > In article <4711.bsimpson@morningstar.com> you write: > >This is somewhat strange to me. You have telnet'd in to check your > >email. You have established an incoming security association. The host > >you are accessing decides that the traffic (the fact that you have 3 > >messages) is not protected information, and sends it in the clear. > > > >Your stack throws aways the TCP packet, because it was not encrypted. > >Instead, you get a message on your screen saying "unencrypted traffic > >tossed". > > Such a telnet connection NEVER becomes "established" because the system > that you are telnet'ing into is not sending you encrypted packets and > your originating telnet application has told the kernel via BSD Sockets > (or similar API) that this session "MUST have bidirectional encryption". > > Hence, the login never occurs and the email is never sent over the > wire at all, so there is no data sent cleartext. > Ahh, you missed the not-so-subtle point, that the TCP session _WAS_ encrypted during the SYN-ACK, but not during the transfer of some data. As explicitly noted later: "... distinguish from context whether to encrypt some bytes and not others". IP uses a datagram model. This is IP security. Furthermore, "MUST have bidirectional encryption" is not an encryption policy (which is data dependent), it is an _AUTHORIZATION_ policy. Authorization is better carried out with mechanisms suited to the use: that is, AH. Simplification through orthogonality. > >At this point, you don't know you have 3 messages, but everyone else on > >the net does. What have you gained? > > It buys a lot: > > The originator of the session sets the policy. The tossing ensures > that the security level requested by the session originator is enforced and > the session never happens if the remote system is uncooperative and doesn't > provide at least the needed security. > But encryption for privacy is related to the security level of the data, not the security level of the TCP "session". Certainly, if this were labelling, you would be arguing the other side. Much of the RFC-1108 text deals with exchange of differently labelled datagrams. Moreover, data on TCP is bi-directional (another not-so-subtle point in the earlier message). The originator (SYN sender) will not necessarily have any "a priori" clue about the sensitivity of the data it is about to send or receive. In short, your model is inconsistent in the general case. And it does violence to the fundamental maxim: be conservative in what you send, and liberal in what you receive [RFC-791]. "... That is, it must be careful to send well-formed datagrams, but must accept any datagram that it can interpret (e.g., not object to technical errors where the meaning is still clear)." > This has been implemented and tested in the NRL implementation > already available for anonymous ftp. It works fine. > The other (datagram) approach has been implemented and tested in the KA9Q implementation. It works fine. It also works with other IP protocol/payloads. Let me whisper some acronyms in your ear: U-D-P, I-C-M-P. Also, as clearly specified in the design, Photuris depends on a consistent model: authenticity (and authorization and integrity) is determined by the receiver _after_ receipt, privacy (and labelling and other such attributes) is determined by the sender _before_ sending. This nice, consistent, orthogonal model is part of the mechanism of Photuris, and changing it would introduce ambiguity in the automaton decisions for initiating a Photuris exchange. 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-owner@p-o.ans.net Sun Jan 7 00:30:33 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14837 (5.65c/IDA-1.4.4 for ); Sat, 6 Jan 1996 19:27:40 -0500 Received: by p-o.ans.net id AA04674 (5.65c/IDA-1.4.4 for ipsec-outgoing); Sun, 7 Jan 1996 00:26:02 GMT Message-Id: <2.2.32.19960107003033.006ba660@ktik0.ethz.ch> X-Sender: caronni@ktik0.ethz.ch X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 07 Jan 1996 01:30:33 +0100 To: ipsec@ans.net, palamber@us.oracle.com, rja@cisco.com From: Germano Caronni Subject: Re: ADMIN: Straw Poll on Key Mgmt Cc: skip-info@tik.ee.ethz.ch, plattner@tik.ee.ethz.ch Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Let me give you the short answer you requested first: 1) YES 2) NO, but is it an issue here? 3) YES, always. Now, I _do_ have certain opinions on these points which have been boiling inside me for the last 6 weeks, and thus wrote somewhat longer (and flame-able) responses too. Do not proceed to read them if your ignition- point is below 451 Fahrenheit .-} > 1) Can the IPsec WG produce multiple standards-track > protocols for key management ? It certainly can ;-) I believe this should be done. Producing multiple and alternative solutions is better than producing none at all, especially in the IPSEC context where quite urgent needs exist in the broader community. As long as the decision does not lead to mutiple _mandatory_ protocols, I prefer variety and temporary deployment in the field to collect 'real' data, instead of an arbitrating decision process, which selects one of several possibilities 'at will'. > 2) If yes to the above, then can a protocol not conforming > to the WG requirements for a key management protocol > be on the IETF standards-track? No. Either the protocol or the requirements need to change. _But_ ;-) please bear with me, if I go and mention some protocol names and my opinions. The poll at IETF Dallas showed that a large part of the people present there want 'PFS'. This indicates that the requirements should not be changed, but SKIP should learn to do PFS instead. I am quite sure that it was not clear to everybody what _perfect_ forward secrecy means. Most probably nobody will provide it in a practical and largely deployed system in a scalable manner as long as mattter-transmitters do not exist. Shipping one-time-pads is currently not IN, a certain (sizeable) granularity in keying material is present everywhere. And no, the Red Phone is not a practical system ;-) Now, I want forward secrecy too, but usually (e.g. normal mail traffic, routing data, NTP, my average telnet session) I am happy with very coarse systems, assuming that break of system integrity or physical intrusion are not likely to happen due to these activities, and loss of confidentality after one year or two is acceptable. Some time I even do not care about confidentiality, authenticity is the main goal. PFS is no issue for authentication at all, as the authentication 'key' _must_ (?) be long-lived and may be stolen and abused at any point in time. On the other hand I might have some business where I want practical forward secrecy, as it is provided by Photuris if I turn the knob way down. Naturally I will not even mention what kind of business this could be ;-) To get to the bottom line, Ashar Aziz has elaborated on one way how a pretty good form of forward secrecy can be done in SKIP (having a bunch of short-lived public values certified at the same time), and a second way, involving ephemeral master keys could be easily imagined. Such a scheme employing ephemeral master keys MUST be optional as it destroys one of the principal properties of SKIP, but could (and should) eventually be integrated into the SKIP proposal, IMHO. So, evaluating the meaning of forward secrecy in context of IPSEC, and assuming the acceptability of the first of these two solutions (am I getting daring here?) one could even argue that SKIP currently fulfills WG requirements, and the whole discussion we have lead about this in the last month is perhaps at least partially the result of less-than-technical issues. (sigh) > 3) If yes to both of the above, should the WG chairs write up a formal > applicability statement to be accompany each standards-track > key management protocol so that the intended use of that protocol > is made clear? If and when multiple protocols providing IP security proceed on the standards track, they should be well differentiated, and a ratio should be given to the world as to why different approaches are pursued in parallel. I was evaluating if it would be wiser to let the parties proposing the respective solutions write up the differentiating aspects, but you are right, most probably it is best if the WG chairs as an unpartial entity write such a ratio. Friendly greetings, Germano Caronni P.S. If you now feel the irresistible urgency to flame me, please change the subject, or, even better, write me personal mail. Thank you. From ipsec-owner@p-o.ans.net Sun Jan 7 21:15:21 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA13321 (5.65c/IDA-1.4.4 for ); Sun, 7 Jan 1996 16:18:37 -0500 Received: by p-o.ans.net id AA21495 (5.65c/IDA-1.4.4 for ipsec-outgoing); Sun, 7 Jan 1996 21:15:30 GMT Date: Sun, 7 Jan 1996 13:15:21 -0800 From: Ran Atkinson Message-Id: <199601072115.NAA11312@puli.cisco.com> To: ipsec@ans.net Subject: An observation or two Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Germano, I feel no need to flame on my part. I will offer just a technical observation or two speaking only for myself. ANY hybrid Diffie-Hellman scheme can provide Perfect Forward Secrecy. Your mention of one-time pads was entirely extraneous. Moreover, there is a lot of experience with deployed systems indicating the Hybrid Diffie-Hellman is not too expensive computationally or otherwise impractical. Second, as near as I can tell, none of the current drafts meet _all_ of the WG requirements. Hence, your misunderstanding that this is about SKIP (hint: the questions are NOT specific to SKIP) is not well founded. Ran rja@cisco.com From ipsec-owner@p-o.ans.net Mon Jan 8 07:04:20 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA11731 (5.65c/IDA-1.4.4 for ); Mon, 8 Jan 1996 02:06:13 -0500 Received: by p-o.ans.net id AA40189 (5.65c/IDA-1.4.4 for ipsec-outgoing); Mon, 8 Jan 1996 07:03:50 GMT From: markson@osmosys.incog.com (Tom Markson) Message-Id: <9601080704.AA05360@monster.incog.com> Subject: SKIP drafts To: ipsec@ans.net Date: Sun, 7 Jan 1996 23:04:20 -0800 (PST) X-Mailer: ELM [version 2.4 PL24 PGP5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Hi, This is just to let you all know that the SKIP draft (05) has been split into several documents, as requested by the working group. The draft has been split into the following documents: 1. SKIP (ietf-ipsec-skip-06.txt) 2. SKIP Algorithm Discovery (ietf-ipsec-skip-adp-00.txt) 3. X509 Encoding of Diffie-Hellman Certificates (ietf-ipsec-skip-x509-00.txt) 4. Encoding of Unsigned DH public values (ietf-ipsec-skip-udh-00.txt) 5. SKIP extensions for Multicast (ietf-ipsec-skip-mc-00.txt) 6. Certificate discovery protocol. (ietf-ipsec-cdp-00.txt). Comments which were received by the editors for (05) have been integrated into the various documents. The documents were announced a couple of weeks ago, but with the holidays, we didn't have a chance to tell everyone in the WG what's going on. Also, there are now three editors of these documents, if you send private mail regarding these documents, please send it to all three: ashar@incog.com hemma@incog.com markson@incog.com --tom From ipsec-owner@p-o.ans.net Mon Jan 8 09:54:27 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14638 (5.65c/IDA-1.4.4 for ); Mon, 8 Jan 1996 05:03:55 -0500 Received: by p-o.ans.net id AA15935 (5.65c/IDA-1.4.4 for ipsec-outgoing); Mon, 8 Jan 1996 09:54:09 GMT Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 8 Jan 1996 04:54:27 -0500 To: ipsec@ans.net From: crocker@cybercash.com (Steve Crocker) Subject: Re: authenticated source addresses Cc: Hilarie Orman , ipsec@ans.net Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Steve, As you point out, if security checking is done by an encrypting router on the periphery of the internal network, there's a potential for the identity of the source host to be lost or misrepresented. I think there are two important subcases. In a great many cases, B1's correspondents are all equally trusted and there is no reason to impose greater controls on them than they would currently have if they were all sharing the same network within an protected environment. In the more complex case in which different authorizations are given to different correspondents, I agree it's essential that the receiving router pass along information from the security association. Whether this is the source address or something else is a subordinate matter. My intuition is that B1 should be using the SA to determine what access to give A1 versus C1. This means B1 has to implement ipsec, and that router B cannot do all of the work on behalf of host B1. B will have to pass along the security information associated with the incoming traffic, and it might as well use AH to do so, either by sharing the SA or by establishing a separate SA between itself and B1. Does this obviate the utility of having B implement ipsec? No, because only AH is needed, and assuming the path from B to B1 is trusted, no cryptography is needed. Steve At 7:12 PM 1/4/96, Stephen Kent wrote: >Hilarie, > > I took the liberty of changing the subject field in my response >since we are not really talking about AH and ESP and replay protection! > > Let me try to state my concerns and views in a somewhat different >perspective. I'll restrict my comments to one case, in which the endpoints >of the SAs in question are encrypting routers, which are operating in >tunneling mode. Pardon the extensive narrative, but I want to minimize the >potential for confucion. Assume (wlog) that the encapsulation being used >is IP-AH-ESP-IP-ULP. > >Let's call one router A, one router B, and one router C. Hosts served by >each of these (encrypting) routers are identified by adding a number after >the letter that identifies the router, e.g., A1 or C3. Now, assume that >two SAs (SA1 and SA2) are established: the first between A and B and the >second between B and C. When each SA is established, some identity >information is exchanged between the two router in question, so that B, the >common endpoint for these two SAs does know the identities of the >corresponding routers. The security policy for B must view both A and C as >legitimate sources of traffic to the net(s) behind B, otherwise the SAs >would not have been established. > >Now, if the IPSEC implementation at B does not do any checking on the >sources addresses for the encapsulated IP packets it receives (after >verifying the AH and decrypting the ESP), the following scenario can arise. >Host A1 can send traffic to host B1 via SA1. Host C1 can send traffic to >B1 via SA2. Host B1 might accord the traffic from A1 and C1 different >access permissions, e.g., grant access to some files to A1 and access to >different files to C1. However, A1 also can send traffic that carries the >IP address of C1 and when the traffic is recived via SA1 there would be no >check to detect this and reject such traffic. Thus, it would be possible >for A1 to send traffic to B1 that appears to be from C1 and thus to be >granted access to files that A1 is not authorized to access (but which C1 >is authorized to access). True, return traffic from B1 that is directed to >C1 would not be delivered to A1, but Bellovin noted long ago how, even with >a lack of the reverse traffic, A1 can successfully generate appropriate TCP >ACKs to establish and maintain the connection. > >This would seem to be a very plausible scenario and if IPSEC does not >include mandatory facilities in encryption routers to allow a site security >manager to prevent such attacks, I think we will be viewed by the community >as having failed to address a major set of common scenarios. The solution >is simply to require that every SA has associated with it some source >address checking mechanism, the granularity of which is a side effect of >the SA establishment process. If packets are sourced by a router, the the >checking might be against a mask for an IP address (or set of addresses), >whereas for a host source the check should be against an indiviaul address. > >Finer granularity ID and access control is not going to be available at an >encrypting router endpoint in a fashion that is meaningfully passed on to >hosts served by the router, at least not based on current paradigms. If >the scenario is changed to enbody only host endpoints, one can do lots of >things, if applications are modified to deal with new ID and access control >facilities and appropriate info is passed up from SA establishment and for >each received packet. However, I expect significant use of these protocols >in conjunction with routers and thus I think it critical to adopt a uniform >capability for the sort of source address checking for tunnel mode as >described above. Also, just for perspective, the pesudo-MIB I wrote and >submitted to this list over a year ago, to stimumate discussion on what >parameters needed to be associated with an SA, embodied precisely this >facility. > >Steve -------------------- Steve Crocker Main: +1 703 620 4200 CyberCash, Inc., Suite 430 Desk: +1 703 716 5214 2100 Reston Parkway Fax: +1 703 620 4215 Reston, VA 22091 crocker@cybercash.com From ipsec-owner@p-o.ans.net Mon Jan 8 12:29:50 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA11664 (5.65c/IDA-1.4.4 for ); Mon, 8 Jan 1996 07:56:26 -0500 Received: by p-o.ans.net id AA15903 (5.65c/IDA-1.4.4 for ipsec-outgoing); Mon, 8 Jan 1996 12:30:00 GMT Date: Mon, 8 Jan 1996 04:29:50 -0800 (PST) From: Phil Karn Message-Id: <199601081229.EAA27808@servo.qualcomm.com> To: rja@cisco.com Cc: ipsec@ans.net In-Reply-To: <199601051632.IAA26934@puli.cisco.com> (message from Ran Atkinson on Fri, 5 Jan 1996 08:32:42 -0800) Subject: Re: AH/ESP & Replay Protection Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Ran, I concede that your policy is useful. Implementing it on one host would indeed block another host from sending it unencrypted data in the event of an implementation error on that other host. (Since I've assumed that key management provides a way to request a remote system to use encryption, the use of cleartext in violation of this request certainly implies an implementation error.) But I still feel uneasy about this, and I'll have to think about it some more. The question is, is this the best way to protect against implementation errors, or is some other mechanism better suited? A policy to refuse unencrypted traffic might protect me in the immediate case, but what about somebody else who talks to the same host who doesn't impose the same policy? If the remote host is that buggy, then I'm not sure I want to trust it with my sensitive data that must be encrypted in the first place. That strongly implies that there's no real substitute for fixing the remote system in the first place. I know I'm not being entirely clear about this. That's why I said I'll have to think about it some more... Phil From ipsec-owner@p-o.ans.net Mon Jan 8 12:00:36 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA13465 (5.65c/IDA-1.4.4 for ); Mon, 8 Jan 1996 07:57:02 -0500 Received: by p-o.ans.net id AA12470 (5.65c/IDA-1.4.4 for ipsec-outgoing); Mon, 8 Jan 1996 12:00:52 GMT Date: Mon, 8 Jan 1996 04:00:36 -0800 (PST) From: Phil Karn Message-Id: <199601081200.EAA27785@servo.qualcomm.com> To: kent@BBN.COM Cc: ipsec@ans.net In-Reply-To: (message from Stephen Kent on Fri, 5 Jan 1996 13:02:15 -0500) Subject: Re: AH/ESP & Replay Protection Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net >functionality. However, I hate to see us loose an important security >facility for non-mobile use of IPSEC because of this problem. I think we Steve, I oppose source address filtering for two main reasons: it breaks mobile IP, and it doesn't really provide any real additional security (as opposed to the illusion of same). There are already many hosts around that support IP-in-IP tunneling without regard to filtering. KA9Q NOS is one such implementation. Anyone who wants to circumvent IP address spoofing can just find one of those hosts and tunnel through it. A third objection is that it makes alternate routing even more difficult in multi-provider situations. When things get really cutthroat in the ISP business I could easily see a large service provider institute source address filtering and cite "security" when his real motivation is to screw his smaller competitors. Phil From ipsec-owner@p-o.ans.net Mon Jan 8 21:45:56 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14828 (5.65c/IDA-1.4.4 for ); Mon, 8 Jan 1996 16:51:05 -0500 Received: by p-o.ans.net id AA27158 (5.65c/IDA-1.4.4 for ipsec-outgoing); Mon, 8 Jan 1996 21:47:22 GMT Date: Mon, 8 Jan 1996 13:45:56 -0800 From: hemma@osmosys.incog.com (Hemma Prafullchandra) Message-Id: <199601082145.NAA03563@eponine.incog.com> To: ipsec@ans.net, housley@spyrus.com Subject: Re: draft-ietf-ipsec-skip-x509-00 Cc: ietf-pkix@tandem.com, markson@osmosys.incog.com, ashar@osmosys.incog.com X-Sun-Charset: US-ASCII Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net --> SKIP Authors: --> --> I encourage you to adopt the Version 3 X.509 certificate syntax. The PKIX --> working group is developing a profile for many Internet applications that --> uses this format. Also, if there are no certificate extensions used, the --> formats are almost identical. In fact, if none of the optional fields are --> present, the only difference is the version number. --> --> I encourage you to align with the PKIX effort. --> --> Russ --> Thanks Russ, will do. All: Also described in the draft are the encodings for Diffie-Hellman public value and IP address. The first is as defined in PKCS #3 and latter as described in the draft. Do you think that the encoding defined for ipAddress will be useful to others ? Currently, we've used the Sun OID space, but if it is of general use then it would be better if it was officially defined and assigned an OID. If yes, is there an "IETF OID space" or what should be done ? I think it would be useful if there was one document that listed all the commonly used OIDs (in say, the security area). In my search for an encoding for an IP address I searched through the PKCSs, NIST OIW stable agreements, X.500, X.509, IETF rfcs (including experimental/informational), ANSI X9.42 and contacted individuals who may have more clues .... Of course, I did not find what I was looking for but I did find some ambiguities in some of the encodings in these documents. What do others think, would an informational rfc listing the "definitive" OIDs/encodings be of use ? Thanks, Hemma From ipsec-owner@p-o.ans.net Mon Jan 8 22:29:09 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14153 (5.65c/IDA-1.4.4 for ); Mon, 8 Jan 1996 17:35:14 -0500 Received: by p-o.ans.net id AA15581 (5.65c/IDA-1.4.4 for ipsec-outgoing); Mon, 8 Jan 1996 22:29:24 GMT From: David A Wagner Message-Id: <199601082229.OAA21442@bamako.CS.Berkeley.EDU> Subject: Re: authenticated source addresses To: ipsec@ans.net Date: Mon, 8 Jan 1996 14:29:09 -0800 (PST) In-Reply-To: from "Stephen Kent" at Jan 4, 96 07:12:25 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 2353 Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Steve Kent writes: > > Now, if the IPSEC implementation at B does not do any checking on the > sources addresses for the encapsulated IP packets it receives (after > verifying the AH and decrypting the ESP), the following scenario can arise. > Host A1 can send traffic to host B1 via SA1. Host C1 can send traffic to > B1 via SA2. Host B1 might accord the traffic from A1 and C1 different > access permissions, e.g., grant access to some files to A1 and access to > different files to C1. However, A1 also can send traffic that carries the > IP address of C1 and when the traffic is recived via SA1 there would be no > check to detect this and reject such traffic. Thus, it would be possible > for A1 to send traffic to B1 that appears to be from C1 and thus to be > granted access to files that A1 is not authorized to access (but which C1 > is authorized to access). > Tunneling mode & routers makes things more complex. There are two issues here which we shouldn't confuse. One issue is whether router B should check the ip_src field in the *outer* IP header. The other issue is whether router B should check the ip_src field in the *inner* IP header. [Recall that we're using tunneling mode here, i.e. IP-AH-ESP-IP-ULP, so there are two IP headers & two ip_src fields.] Your attack shows that router B should check the inner ip_src field against the SPI before accepting the tunneled packet as valid and re-injecting it to the B-net. (This should not be surprising, if you think about the security policy -- B doesn't necessarily trust C to speak for the WHOLE Internet.) However, your example doesn't speak to the issue of whether B needs to check the ip_src field in the outer IP header. (That's not a criticism; I'm just trying to head off confusion.) > The solution > is simply to require that every SA has associated with it some source > address checking mechanism, the granularity of which is a side effect of > the SA establishment process. Yeah, the router is trusted to translate key-based authentication into IP-src-based authentication; therefore, the router must have some concept of a mapping between the two to validate the inner ip_src field. Again, though, there is a difference between checking the inner source address and the outer source address. From ipsec-owner@p-o.ans.net Mon Jan 8 23:10:00 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA15022 (5.65c/IDA-1.4.4 for ); Mon, 8 Jan 1996 18:15:31 -0500 Received: by p-o.ans.net id AA27309 (5.65c/IDA-1.4.4 for ipsec-outgoing); Mon, 8 Jan 1996 23:10:11 GMT From: David A Wagner Message-Id: <199601082310.PAA21469@bamako.CS.Berkeley.EDU> Subject: Re: authenticated source addresses To: ipsec@ans.net Date: Mon, 8 Jan 1996 15:10:00 -0800 (PST) In-Reply-To: <9601052012.AA00935@katahdin.columbia.sparta.com> from "Howard Weiss" at Jan 5, 96 03:12:11 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1099 Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net > Steve Kent wrote: > > [...] > > But isn't it actually the source router's responsibility to ensure > that the "correct" IP address (e.g. an IP address of a host served by > it and no others) is placed into the upper-most IP src address field? > In this paradigm, Router A would not allow host A1 to place address C1 > into an IP header which is then encrypted and authenticated by Router > A. That's one security policy. In this security policy, (1) router B trusts router A to speak for the entire Internet and (2) host B1 trusts router B to speak for the entire Internet. Then I agree that router B shouldn't need to validate the ip_src field in the inner-most (upper-most?) IP header. I guess the security policy which I had in mind when reading Steve Kent's posting was (1') router B trusts router A to speak for the A? hosts and (2') host B1 trusts router B to speak for the entire Internet. In this security policy, router B must enforce (1') by checking the inner-most ip_src value. Pick whichever security policy you prefer, and then decide what mechanisms you need to support it. From ipsec-owner@p-o.ans.net Tue Jan 9 15:38:00 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA10665 (5.65c/IDA-1.4.4 for ); Tue, 9 Jan 1996 10:50:13 -0500 Received: by p-o.ans.net id AA27336 (5.65c/IDA-1.4.4 for ipsec-outgoing); Tue, 9 Jan 1996 15:42:36 GMT X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 9 Jan 1996 10:40:17 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 9 Jan 1996 10:39:10 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 9 Jan 1996 10:38:00 -0500 Date: Tue, 9 Jan 1996 10:38:00 -0500 X400-Originator: /dd.id=1618054/g=warwick/i=ws/s=ford/@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars520.b.664:09.00.96.15.39.10] X400-Content-Type: P2-1984 (2) Content-Identifier: re:draft-ietf... From: "warwick (w.s.) ford" Message-Id: <"17690 Tue Jan 9 10:39:24 1996"@bnr.ca> To: housley@spyrus.com, ashar.aziz@eng.sun.com, markson@incog.com, hemma@eng.sun.com Cc: ipsec@ans.net, ietf-pkix@tandem.com Subject: re:draft-ietf-ipsec-skip-X509-00.txt Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net I agree with Russ that the pkix project should aim to support skip, and invite Ashar et al to work with us towards that end. There seem to be two main options for encoding IP address in the certificate - (a) put it in the DN somehow, or (b) use subject altnames fields for one or more IP addresses (with either a null or a meaningful DN in subject name). A possible advantage of (a) over (b) is that the name(s) is/are right up front therefore possibly easier to find. With (b), you have to parse further into the ASN.1 to find the name(s), but it is not obvious to me that this is a real concern - I suspect most X.509 implementations would parse the whole certificate anyway, just to get the DN. I would appreciate the view of ipsec people on this. The most serious problem with the current skip proposal is that it breaks the semantics of DN, by the way it uses the different RDN components. The intended semantics are that the full sequence of RDN components gives the unique name - it does not give a set of equivalent names. I think this will mean that many standard X.500 or even X.509 systems might have difficulty dealing with such certificates - for example, the matching rule for equality no longer works. I would strongly recommend that skip change this - i.e., don't try to use one DN to represent more than one equivalent names. To fix the above, the only way I can see is to start using subject altnames for IP addresses after the first, even if the first is still encoded in subject name. I see no fundamental problem in encoding one IP address as the subject name. However, if this is followed, I think it advisable to still make the certificates compatible with X.500 systems. This would mean it should be possible to precede the IP RDN with a sequence of RDNs of other types. For example, a useful DN might be: C=Canada, O=BNR, OU=IPSecurity, IP=47.1.2.3. This would allow us (BNR) to administer our IP security through our regular X.500/X.509-based certificate management system, and our certificates would be fully compatible with skip. From the X.509 and pkix perspective we need to deal with the issue of having a name type component for IP address in GeneralName. We can do that immediately by assigning an OID and using an instance of OTHER NAME. Alternatively, if this looks like an option that will receive widespread use, I believe we could easily get a bit assigned in the GeneralName CHOICE in both the ISO/IEC and X9 standards (both of which are currently out for ballot). Is everyone happy with the use of PrintableString as the type for this option? Warwick In message "draft-ietf-ipsec-skip-X509-00.txt", housley@spyrus.com writes: >Please look at draft-ietf-ipsec-skip-X509-00.txt. This document suggests >that the IP address is part of the distinguished name (in printable string >form). I would like SKIP to be one of the user's of PKIX. > >Russ > ************************************************************************ Warwick Ford, Bell-Northern Research E-mail: wford@bnr.ca PO Box 3511, Station C Tel: (613) 765-4924 Ottawa ON K1Y4H7 Canada Fax: (613) 765-3520 ************************************************************************ From ipsec-owner@p-o.ans.net Tue Jan 9 16:37:15 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14838 (5.65c/IDA-1.4.4 for ); Tue, 9 Jan 1996 13:38:28 -0500 Received: by p-o.ans.net id AA04679 (5.65c/IDA-1.4.4 for ipsec-outgoing); Tue, 9 Jan 1996 18:24:38 GMT Date: Tue, 9 Jan 96 16:37:15 GMT From: "William Allen Simpson" Message-Id: <4723.bsimpson@morningstar.com> To: ipsec@ans.net Subject: Re: authenticated source addresses Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net > From: David A Wagner > I guess the security policy which I had in mind when reading Steve > Kent's posting was > (1') router B trusts router A to speak for the A? hosts > and > (2') host B1 trusts router B to speak for the entire Internet. > In this security policy, router B must enforce (1') by checking > the inner-most ip_src value. > As I read this, I see two fallacies: (1") What if a C1 host is mobile on the A net? Isn't a better description that B trusts A to have validated C1? Isn't that what trust is all about? In which case, there is no need or utility to have an source check (inner or outer), since B trusts A to have done it, and only A can have tunneled the datagram. Furthermore, there is no practical way to check the source in this case. (2") In both (2) and (2'), you have this statement. But, if B1 has any knowledge (trust) of B, then B1 is implementing some form of IP Security. Otherwise, it has no proof that traffic is from B. If B1 has implemented IP Security, then there is no need for B to handle security on B1's behalf. They can setup SAs directly between hosts. > Pick whichever security policy you prefer, and then decide what > mechanisms you need to support it. > Arrgh! I really think this will lead to endless ratholes! What we need is a few, clear, simple policies, with even fewer simple mechanisms. Otherwise, it is impossible to train, difficult to document, and interoperably and operationally infeasable. 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-owner@p-o.ans.net Tue Jan 9 19:20:05 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA13651 (5.65c/IDA-1.4.4 for ); Tue, 9 Jan 1996 14:24:56 -0500 Received: by p-o.ans.net id AA43055 (5.65c/IDA-1.4.4 for ipsec-outgoing); Tue, 9 Jan 1996 19:19:39 GMT X-Sender: kent@eudora.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 9 Jan 1996 14:20:05 -0500 To: ipsec@ans.net From: Stephen Kent Subject: Re: authenticated source addresses Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net David, I didn't state a need for B to check the outer IP header source address because that address is not passed on to the hosts and thus cannot undermine any host A/C decisions. Steve From ipsec-owner@p-o.ans.net Tue Jan 9 19:20:28 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA10588 (5.65c/IDA-1.4.4 for ); Tue, 9 Jan 1996 14:26:16 -0500 Received: by p-o.ans.net id AA11083 (5.65c/IDA-1.4.4 for ipsec-outgoing); Tue, 9 Jan 1996 19:22:09 GMT X-Sender: kent@eudora.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 9 Jan 1996 14:20:28 -0500 To: ipsec@ans.net From: Stephen Kent Subject: Re: authenticated source addresses Cc: ipsec@ans.net, Hilarie Orman Mmdf-Warning: Unable to confirm address in preceding line at LABS-N.BBN.COM Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Steve, In IPSEC scenarios I envision as commonplace, trust is very squishy. An organization will likely add IPSEC capability to their firewall. They want to make use of this facility whenever possible because it provides "better security." Thus the other endpoints with whom IPSEC-protected communication takes place may quickly grow to encompass a wide range of individuals and/or organizations. There need not be a uniform level of "trust" in these other IPSEC endpoints. It is hard to establish and enforce, at an encrypting router, precise security policies However, in general (mobile IP not included), it is reasonable to enforce a policy of the form "packets coming from this verified IPSEC endpoint may only assert the following range of IP source addresses in whatever IP header is delivered across this crypto router interface." Ran's suggestion about having a mobile IP subscriber assert a fixed inner address in tunnel mode, while using whatever address is assigned by the server in the outer IP header does sound like a possible fix to the problem. However, I have not thought about it in detail, and it does have the bandwidth disadvantages that I alluded to earlier. Moreover, in the mobile environment, bandwidth is scarce, so it's a pity to impose this added overhead in exactly this situation. Steve From ipsec-owner@p-o.ans.net Tue Jan 9 19:41:10 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA13445 (5.65c/IDA-1.4.4 for ); Tue, 9 Jan 1996 14:46:59 -0500 Received: by p-o.ans.net id AA15389 (5.65c/IDA-1.4.4 for ipsec-outgoing); Tue, 9 Jan 1996 19:41:22 GMT Message-Id: <199601091941.AA100806471@relay.hp.com> X-Mailer: exmh version 1.6.2 7/18/95 To: ipsec@ans.net Subject: Re: authenticated source addresses In-Reply-To: bsimpson's message of Tue, 09 Jan 1996 16:37:15 +0000. <4723.bsimpson@morningstar.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 09 Jan 1996 14:41:10 -0500 From: Bill Sommerfeld Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii (2") In both (2) and (2'), you have this statement. But, if B1 has any knowledge (trust) of B, then B1 is implementing some form of IP Security. Otherwise, it has no proof that traffic is from B. In the presence of a firewall and an internal network, where "B" is the only router connected to the outside world, and you trust all of B2..BN to not impersonate B (because you control all the hosts in B), this is definitely not true! Folks use IP-source-address based access control on hosts and routers all the time. No, it's not really secure, but for many people it's all they've got. If you want people to transition from using IP-address-based access control to using cryptographic security, the intermediate steps (partial IPSEC deployment) must not make it too easy to subvert ip-address-based access controls. - Bill -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMPLEyFpj/0M1dMJ/AQFH5wP8DbSVdzai3buge9NP2L78iCzwfKChbNbf dgzkR875ESKaxwFilSehEx6uSrYcBeSasDO9lqgGPw2qHAd5rHgNfcZMWPKBj3ow HPVeI4Uvkhg5l98speue6dMSvjGxxUaiYFzTj5mDTzQIc2rxTPlOLM0D75oyTfS/ cUhZnnxClHg= =yg6B -----END PGP SIGNATURE----- From ipsec-owner@p-o.ans.net Wed Jan 10 09:11:29 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA13393 (5.65c/IDA-1.4.4 for ); Wed, 10 Jan 1996 04:20:40 -0500 Received: by p-o.ans.net id AA38581 (5.65c/IDA-1.4.4 for ipsec-outgoing); Wed, 10 Jan 1996 09:11:43 GMT Date: Wed, 10 Jan 1996 01:11:29 -0800 (PST) From: Phil Karn Message-Id: <199601100911.BAA20174@servo.qualcomm.com> To: rja@cisco.com Cc: ipsec@ans.net In-Reply-To: <199601051913.LAA05788@puli.cisco.com> (message from Ran Atkinson on Fri, 5 Jan 1996 11:13:55 -0800) Subject: Re: AH/ESP & Replay Protection Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net >No, the damage has NOT been done because if the router weren't encrypting >its TCP packets back to the originator, the TCP session would never get >into the ESTABLISHED state. Hence, no sensitive user data could leak. You're assuming TCP. What about UDP-based applications, e.g., NFS? With your mechanism in place I send a NFS read request to a remote server. It erroneously responds with the data in the clear. My machine throws it away. I don't have the data, but the eavesdropper does. Sure, it eventually gets my attention because things stop working. But until then, quite a few file blocks may have been sent in the clear. There's just no alternative to fixing the underlying problem with the remote server not doing what you told it to do. Phil From ipsec-owner@p-o.ans.net Wed Jan 10 11:56:23 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14721 (5.65c/IDA-1.4.4 for ); Wed, 10 Jan 1996 07:04:15 -0500 Received: by p-o.ans.net id AA03766 (5.65c/IDA-1.4.4 for ipsec-outgoing); Wed, 10 Jan 1996 11:57:02 GMT Message-Id: <2.2.32.19960110115623.0032f068@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 10 Jan 1996 06:56:23 -0500 To: ipsec@ans.net, ipsec@ans.net From: Robert Moskowitz Subject: Re: ADMIN: Straw Poll on Key Mgmt Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net At 10:44 AM 1/4/96 -0800, Ran Atkinson wrote: Here I sit at Logan airport trying to get to DC. A chance to answer this :) > 1) Can the IPsec WG produce multiple standards-track > protocols for key management ? Yes But. There has been a lot of discussion about 'standards' in many forms. IMHBO (B == Bias), the WG should only produce one standard. It would be a good thing if that standard is easily extensible to many other security needs. Afterall, here is where a lot of this work has been done, and other areas should benefit from this work. Alternatively, this group could produce an IPSP specific standard and recommend out of itself a general standard. > 2) If yes to the above, then can a protocol not conforming > to the WG requirements for a key management protocol > be on the IETF standards-track ? No by definition. Either change the spec to meet the requirements, or admit that the req were not obtainable (for technical reasons) and the new req is... Or redefine what a standard is. > 3) If yes to both of the above, should the WG chairs write up a formal > applicability statement to be accompany each standards-track > key management protocol so that the intended use of that protocol > is made clear? No but contrapositively, the WG could promote a given protocol for another use. > (This last is similar to the way routing protocols always have an > applicability statement published.) But many of the routing protocols are non-overlaping, like BGP-4 and OSPF... Robert Moskowitz Chrysler Corporation (810) 758-8212 From ipsec-owner@p-o.ans.net Wed Jan 10 18:09:14 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA10673 (5.65c/IDA-1.4.4 for ); Wed, 10 Jan 1996 13:31:30 -0500 Received: by p-o.ans.net id AA13906 (5.65c/IDA-1.4.4 for ipsec-outgoing); Wed, 10 Jan 1996 18:09:36 GMT Message-Id: <199601101809.AA285607356@ns.hp.com> X-Mailer: exmh version 1.6.2 7/18/95 To: ipsec@ans.net Cc: rja@cisco.com Subject: Re: AH/ESP & Replay Protection In-Reply-To: karn's message of Wed, 10 Jan 1996 01:11:29 -0800. <199601100911.BAA20174@servo.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 10 Jan 1996 13:09:14 -0500 From: Bill Sommerfeld Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii You're assuming TCP. What about UDP-based applications, e.g., NFS? With your mechanism in place I send a NFS read request to a remote server. It erroneously responds with the data in the clear. My machine throws it away. I don't have the data, but the eavesdropper does. Sure, it eventually gets my attention because things stop working. But until then, quite a few file blocks may have been sent in the clear. Phil, I don't think it's quite as bad as you make out. Realistically, most UDP-based application protocols also have to go through a packet exchange or two before any "real" data gets sent from the server to the client. NFS typically requires a couple of round trips (the mount request & subsequent directory lookups) before it's got enough state built up on the client to let it do a `read'. An eavesdropper might get a file name or file handle, but not actual file contents. I guess I see the danger that the user *won't know* the data is going in the clear as significantly greater than the risk that an eavesdropper will get the first packet or two. Of course, the user's stack should probably scream bloody murder on the console or whatever if it drops an unprotected packet when it was expecting a protected packet, but that's another matter.. - Bill -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMPQAvVpj/0M1dMJ/AQF6fQP9HpWsCn+45JYE7Xvio+B3vw5jHDK4vXCw oddNgxdBiDyWrPl5xKGQEP4hMUmQltLflr5wlA7ByoEvVfrMLpYSIqk1rfruo2Ci eOIwskarxWHxOnRurX8wCLGhcLhIBoknWoytUm+iHFshdhahbhMhhJcmTtkRdpjq M+HAzrThv1A= =VDd4 -----END PGP SIGNATURE----- From ipsec-owner@p-o.ans.net Wed Jan 10 15:25:45 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA13462 (5.65c/IDA-1.4.4 for ); Wed, 10 Jan 1996 15:25:45 -0500 Received: by p-o.ans.net id AA04716 (5.65c/IDA-1.4.4 for ipsec-outgoing); Wed, 10 Jan 1996 20:04:24 GMT Date: Wed, 10 Jan 96 11:35:09 From: "Housley, Russ" Encoding: 1155 Text Message-Id: <9600108213.AA821302509@spysouth.spyrus.com> To: ipsec@ans.net Cc: ietf-pkix@tandem.com, markson@osmosys.incog.com, ashar@osmosys.incog.com, wford@bnr.ca Subject: Re: draft-ietf-ipsec-skip-x509-00 Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Hemma: 1. I think that there should be one method for encoding Diffie-Hellman public values in the Internet, and the method descrived in PKCS#3 is fine by me. 2. I agree with Warwick Ford's response regarding ipAddress. I prefer the use of the alternate name extension rather than defining a new Attribute Value Assertion (AVA) component that can be used in Distinguished Names. In my experience with the Defense Message System (DMS), adding AVA that can appear in Distinguished Names has ripple effects in many system components, including directories and client certificate path valaidation software. The use of the extension significantly reduces the ripple effect. 3. Compiling an OID list would be a big task. The fact that OIDs can be assigned without coordination is a technical benifit of OIDs, but it makes it nearly impossible to compile a "definitive" list. Perhaps advertising a registry would work. People who assign OIDs could place an entry in the registery if they think that someone else would benifit from the same OID assignment. This voluntary sharing would be a very useful service. Russ From ipsec-owner@p-o.ans.net Thu Jan 11 16:06:30 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA11834 (5.65c/IDA-1.4.4 for ); Thu, 11 Jan 1996 12:26:45 -0500 Received: by p-o.ans.net id AA21664 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 11 Jan 1996 16:09:14 GMT Message-Id: <9601111606.AA23935@tis.com> To: ipsec@ans.net Subject: Program Announcement - ISOC 1996 Symp. Netw. & Distr. Sys. Security Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <23923.821376388.1@tis.com> Date: Thu, 11 Jan 1996 11:06:30 -0500 From: "David M. Balenson" Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net ------------------------------------------------------------------------------ THE INTERNET SOCIETY 1996 SYMPOSIUM ON NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS '96) 22-23 FEBRUARY 1996 SAN DIEGO PRINCESS RESORT, SAN DIEGO, CALIFORNIA The symposium will bring together people who are building software and/or hardware to provide network and distributed system security services. The symposium is intended for those interested in the more practical aspects of network and distributed system security, focusing on actual system design and implementation, rather than in theory. We hope to foster the exchange of technical information that will encourage and enable the Internet community to apply, deploy and advance the state of the available security technology. ------------------------------------------------------------------------------ P R E L I M I N A R Y P R O G R A M WEDNESDAY, FEBRUARY 21 6:00 P.M. - 8:00 P.M. RECEPTION - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - THURSDAY, FEBRUARY 22 7:30 A.M. CONTINENTAL BREAKFAST 8:30 A.M. OPENING REMARKS 9:00 A.M. SESSION 1: ELECTRONIC MAIL SECURITY Chair: Stephen T. Kent (BBN Corporation, USA) Mixing E-mail with BABEL, Gene Tsudik and Ceki Gulcu (IBM Research Division, Zurich Research Laboratory, SWITZERLAND) An Integration of PGP and MIME, Kazuhiko Yamamoto (Nara Institute of Science and Technology, JAPAN) 10:00 A.M. BREAK 10:30 A.M. SESSION 2: DISTRIBUTED OBJECT SYSTEMS Chair: Dan Nessett (Sun Microsystems, USA) A Security Framework Supporting Domain Based Access Control in Distributed Systems, Nicholas Yialelis and Morris Sloman (Imperial College, London, UNITED KINGDOM) PANEL: Scalability of Security in Distributed Object Systems Chair: Dan Nessett (Sun Microsystems, USA) Panelists: Dan Nessett (Sun Microsystems, USA), Nicholas Yialelis (Imperial College, London, UNITED KINGDOM), and Bret Hartman (Odyssey Research Associates, USA) 12:00 NOON LUNCH 1:30 P.M. SESSION 3: DISTRIBUTED SYSTEM SECURITY Chair: Michael Roe (University of Cambridge, UNITED KINGDOM) A Flexible Distributed Authorization Protocol, Jonathan Trostle (CyberSAFE, USA) and B. Clifford Neuman (Information Sciences Institute, University of Southern California, USA) Preserving Integrity in Remote File Location and Retrieval, Trent Jaeger (University of Michigan, USA) and Aviel D. Rubin (Bellcore, USA) C-HTTP - The Development of a Secure, Closed HTTP-Based Network on the Internet, Takahiro Kiuchi (University of Tokyo, JAPAN) and Shigekoto Kaihara (University of Tokyo Hospital, JAPAN) 3:00 P.M. BREAK 3:30 P.M. SESSION 4: PANEL: INTELLECTUAL PROPERTY PROTECTION Chair: Peter Neumann (SRI International, USA) Panelists: David Bernstein (Electronic Publishing Resources, USA), Russ Housley (Spyrus, USA), and Dan Boneh (Princeton University, USA) 7:00 P.M. DINNER BANQUET - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - FRIDAY, FEBRUARY 23 7:30 A.M. CONTINENTAL BREAKFAST 8:30 A.M. SESSION 5: NETWORK SECURITY Chair: Matt Bishop (University of California at Davis, USA) Designing an Academic Firewall: Policy, Practice and Experience with SURF, Michael B. Greenwald, Sandeep K. Singhal, Jonathan R. Stone, and David R. Cheriton (Stanford University, USA) Digital Signature Protection of the OSPF Routing Protocol, Sandra Murphy and Madelyn Badger (Trusted Information Systems, USA) A Case Study of Secure ATM Switch Booting, Shaw-Cheng Chuang and Michael Roe (University of Cambridge, UNITED KINGDOM) 10:00 A.M. BREAK 10:30 A.M. SESSION 6: KEY MANAGEMENT Chair: Burt Kaliski (RSA Laboratories, USA) SKEME: A Versatile Secure Key Exchange Mechanism for Internet, Hugo Krawczyk (IBM T.J. Watson Research Center, USA) IDUP and SPKM: Developing Public-Key-Based APIs and Mechanisms for Communication Security Services, Carlisle Adams (Bell-Northern Research, CANADA) 11:30 A.M. LUNCH 1:00 P.M. SESSION 7: ENCRYPTION Chair: Paul Lambert (Oracle, USA) An Empirical Study of Secure MPEG Video Transmissions, Iskender Agi and Li Gong (SRI International, USA) Parallelized Network Security Protocols, Erich Nahum and David J. Yates (University of Massachusetts, USA), Sean O'Malley, Hilarie Orman and Richard Schroeppel (University of Arizona, USA) A "Bump in the Stack" Encryptor for MS-DOS Systems, David A. Wagner (University of California at Berkeley, USA) and Steven M. Bellovin (AT&T Bell Laboratories, USA) 2:30 P.M. BREAK 3:00 P.M. SESSION 8: PANEL: PUBLIC-KEY INFRASTRUCTURE Chair: Warwick Ford (Bell Northern Research, CANADA) Panelists: John Wankmueller (MasterCard International, USA), Taher ElGamal (Netscape Communications, USA), and Michael Baum (VeriSign, USA). ------------------------------------------------------------------------------ GENERAL CHAIR: Jim Ellis, CERT Coordination Center PROGRAM CHAIRS: David Balenson, Trusted Information Systems B. Clifford Neuman, USC Information Sciences Institute PROGRAM COMMITTEE: Tom Berson, Anagram Laboratories Matt Bishop, University of California at Davis Doug Engert, Argonne National Laboratory Warwick Ford, Bell Northern Research (Canada) Burt Kaliski, RSA Laboratories Steve Kent, BBN Corporation Paul Lambert, Oracle John Linn, OpenVision Technologies Teresa Lunt, Advanced Research Projects Agency Dan Nessett, Sun Microsystems Hilarie Orman, University of Arizona Michael Roe, Cambridge University (UK) Rob Rosenthal, U.S. National Institute of Standards and Technology Avi Rubin, Bellcore Jeff Schiller, Massachusetts Institute of Technology Rob Shirey, BBN Corporation Doug Tygar, Carnegie Mellon University Roberto Zamparo, Telia Research (Sweden) LOCAL ARRANGEMENTS CHAIR: Thomas Hutton, San Diego Supercomputer Center PUBLICATIONS CHAIR: Steve Welke, Institute for Defense Analyses REGISTRATIONS CHAIR: Donna Leggett, Internet Society STEERING GROUP Internet Research Task Force, Privacy and Security Research Group ------------------------------------------------------------------------------ BEAUTIFUL SAN DIEGO PRINCESS RESORT Location The Symposium venue is the San Diego Princess Resort, a tropical paradise on a forty-four acre island in Mission Bay, ten minutes from the international airport. Lush gardens landscaped with hundreds of species of tropical and subtropical plants are always ablaze with color and perfect for themed group events. Charming pathways wander among sparkling waterfalls, across quaint footbridges and sleepy lagoons filled with water lilies and waterfowl. A white sand beach curves around the island for over a mile, and the award-winning grounds encompass five swimming pools and six lighted tennis courts. Spouses and family members can catch a convenient Harbor Hopper for a quick trip to Sea World. After the Symposium, plan to spend the weekend visiting La Jolla, the world famous San Diego Zoo or Mexico, only 30 minutes by car or Trolley. Housing Information We have reserved a special block of sleeping rooms at the San Diego Princess Resort at the following rates: Lanai Patio & Garden View Rooms $ 81* Lanai Garden & Lagoon View Rooms $112 One Bedroom Suite $115 * This represents the Government Rate for San Diego. We have a limited number of rooms available at this rate. If you need a government rate, reserve your room early! You must present a valid government id upon check- in. Based on room type and space availability, these special group rates are applicable two days prior to and two days after the symposium. Current Room Tax is 10.5%. Check-in availability cannot be committed prior to 4:00 p.m. Check-out time is 12:00 noon. The San Diego Princess Resort will make every effort to accommodate any early arrivals, so make sure you give them your arrival time when you make your reservation. To make a reservation Contact the San Diego Princess Resort at 1-800-344-2626 (+1-619-274-4630 if outside the United States). To receive the special group rates, reservations must be made no later than January 20, 1996. CLIMATE February weather in San Diego is normally very pleasant. Early morning temperatures average 55 degrees while afternoon temperatures average 67 degrees. Generally, a light jacket or sweater is adequate during February; although, occasionally it rains. REGISTRATION FEES ISOC Non- Members Member Early registration (postmarked by Jan. 19) $295 $330 Late registration $365 $400 REGISTRATION INCLUDES - Attendance - Symposium Proceedings - Two luncheons - Reception - Banquet - Coffee Breaks FOR MORE INFORMATION on registration contact Donna Leggett by phone at 703-648-9888 or via e-mail to Ndss96reg@isoc.org. WEB PAGE - Additional information about the symposium and San Diego, as well as an on-line registration form, are available via the Web at: http://www.isoc.org/conferences/ndss96 ------------------------------------------------------------------------------ Internet Society Symposium on Network and Distributed System Security 22-23 February, 1996 San Diego, California, USA Registration Form --------------------------------------------------------------------------- Fill out this form and FAX it to NDSS'96 Registration (703) 648-9887, send it via electronic mail to Ndss96reg@isoc.org, or mail it to NDSS96, 12020 Sunrise Valley Drive, Suite 210, Reston, VA, 22091, USA --------------------------------------------------------------------------- Personal Information __Mr __Ms __Mrs __Dr __Prof __M __Prof Dr __Dip Ing __Ing __Miss __Mlle First Name: __________________________ Middle Name: _______________ Family Name: __________________________ __sr __jr __II __III __PhD Please enter your name as you would like it to appear on your conference name tag. Badge Name: _____________________________ Contact Information Your title: _____________________________ Your affiliation: _____________________________ Your address: _____________________________ _____________________________ City: _____________________________ State or Province: _____________________________ Postal Code: _____________ Country: _____________________________ Tel (work) Number: _____________________________ Tel (home) Number: _____________________________ Fax Number: _____________________________ EMail address: _____________________________ Special Needs? Do you have any special needs (vegetarian meals, wheelchair access, etc?): _________________________________________________________________________ _________________________________________________________________________ Appear on the Registrants List? ___ Please check here if you would NOT like your name included in the list of registrants. Payment Information All Payments must be in United States Dollars. Conference Charges If you are an Internet Society member, you are eligible for a reduced registration fee. Non-member symposium attendees will receive a one year Internet Society membership as part of the non-member registration fees. Check one: Before After January 19 January 19 ---------- ---------- ___Internet Society Member Conference Fee US$ 295.00 US$ 365.00 ___Non-Member Conference Fee US$ 330.00 US$ 400.00 Method of Payment 1. __ Check Make payable to the Internet Society. Checks must be postmarked before February 16, 1996 or you will not be registered. 2. __ Credit Card __ American Expres __ Mastercard __ Visa Name on Credit Card:__________________________ Credit Card Number:__________________________ Expiration Date:__________ 3. __ First Virtual First Virtual Account Number: _________________________ 4. __ Wire Transfer* Riggs Bank of Virginia Bank ABA number: 056001260 8315 Lee Highway Account number: Internet Society 148 387 10 Fairfax VA 22031 USA Wire Transfer Confirmation Number:____________________________ * Please process wire transfer before sending the registration form. 5. __ U.S. Government Purchase order* Please provide the P.O. Number: ___________________________ * Please fax or mail a copy of your purchase order along with your registration form. Cancellation Policy ------------------- Refunds will be issued for cancellations received before February 16, 1996. No refunds will be issued after February 16, 1996. --------------------------------------------------------------------------- From ipsec-owner@p-o.ans.net Fri Jan 12 17:17:45 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14683 (5.65c/IDA-1.4.4 for ); Fri, 12 Jan 1996 13:24:13 -0500 Received: by p-o.ans.net id AA13261 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 12 Jan 1996 17:16:05 GMT From: Germano Caronni Message-Id: <199601121717.SAA14971@ktik6> Subject: Tunneling / Cheating To: ipsec@ans.net Date: Fri, 12 Jan 1996 18:17:45 +0100 (MET) Cc: plattner@tik.ee.ethz.ch (Bernhard Plattner), markson@incog.com, aziz@incog.com X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Content-Length: 1162 Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Hi everybody, a short question relating to a kind of 'cheating' attack when using tunnelling mode. Assume you get an AH/ESP protected ip packet from source A. You check the authentication, and it is the correct authentication for an association you have with node A. Now you decode ESP, and see the payload is IP, thus you give it back to the IP handling part of your kernel. +-----------+-------+----+-----+-------------+------------- + outer IP + AUX + AH + ESP + inner IP + UDP payload + srcaddr = + + + + srcaddr = + + 1.2.3.4 + + + + 5.6.7.8 + +-----------+-------+----+-----+-------------+------------- This encapsulated IP packet claims to come from node B, and as part of an UDP data exchange will be passed up to the application. The application has been tricked in accepting the packet. Bad. Does this imply that for each socket/whatever you have to indicate for each received packet to which SPI it belongs, respectively have to do some filtering before passing up data? I would be very interested in knowing your views concerning this problem... Friendly greetings, Germano Caronni From ipsec-owner@p-o.ans.net Fri Jan 12 22:16:52 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA13024 (5.65c/IDA-1.4.4 for ); Fri, 12 Jan 1996 18:27:30 -0500 Received: by p-o.ans.net id AA44684 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 12 Jan 1996 22:23:35 GMT Date: Fri, 12 Jan 96 22:16:52 GMT From: "William Allen Simpson" Message-Id: <4730.bsimpson@morningstar.com> To: ipsec@ans.net Subject: Re: Tunneling / Cheating Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net > From: Germano Caronni > a short question relating to a kind of 'cheating' attack when using > tunnelling mode. > This is not "cheating", this is exactly what is supposed to happen! > Assume you get an AH/ESP protected ip packet from source A. You check the > authentication, and it is the correct authentication for an association > you have with node A. Now you decode ESP, and see the payload is IP, thus > you give it back to the IP handling part of your kernel. > > This encapsulated IP packet claims to come from node B, and as part of an > UDP data exchange will be passed up to the application. The application has > been tricked in accepting the packet. Bad. > No, Good! This is not a "trick"! This is as designed! The security association is with A. You trust A. If the packet from A is really from another incarnation of A called B, that's fine. Mobility. Internet Security does not place any significance on easily forged IP Source addresses. It relies instead on proof of possession of secret knowledge: that is, a cryptographic key. > Does this imply that for each socket/whatever you have to indicate for each > received packet to which SPI it belongs, respectively have to do some > filtering before passing up data? > Depends on your API. Some do, some don't. 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-owner@p-o.ans.net Fri Jan 12 23:42:58 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA13434 (5.65c/IDA-1.4.4 for ); Fri, 12 Jan 1996 19:50:24 -0500 Received: by p-o.ans.net id AA17067 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 12 Jan 1996 23:42:43 GMT X-Sender: kent@eudora.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 12 Jan 1996 18:42:58 -0500 To: ipsec@ans.net From: Stephen Kent Subject: Re: Tunneling / Cheating Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Germano, Bill provided you with one answer, based on the model he has documented in the Photuris spec. This general topic has been the focus of some discussion on this list for a couple of weeks. Some of us are concerned about the scenario you described, when it occurs in the context of a router vs. a host. One can argue that the host has access to identity info from the SA establishment procedure and can maintain a binding between that info and whatever packets arrive on the SA, thus avoiding security problems due the possible difference in IP-layer identities for inner and outer IP headers. However, this does not work well at a router (which is not the ultimate target of the tarffic) and we have no mechanism to pass back to the target whatever identity info we may have received during SA establishment. The fact that the IP address in the inner header is different from the outer header is not the problem, as Bill says, it's a feature. It's necessary, especially if the other end of the IPSEC SA is another router. The focus of the debate is whether there ought to be required controls as part of a tunneling IPSEC implementation (on a router) to constrain the range of addresses that may be expressed in the inner header. On that score, I don't think we yet have a concensus. Steve From ipsec-owner@p-o.ans.net Sat Jan 13 00:47:48 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA15850 (5.65c/IDA-1.4.4 for ); Fri, 12 Jan 1996 20:49:37 -0500 Received: by p-o.ans.net id AA27312 (5.65c/IDA-1.4.4 for ipsec-outgoing); Sat, 13 Jan 1996 00:48:02 GMT From: Germano Caronni Message-Id: <199601130047.BAA15831@ktik6> Subject: Re: Tunneling / Cheating To: ipsec@ans.net Date: Sat, 13 Jan 1996 01:47:48 +0100 (MET) In-Reply-To: <4730.bsimpson@morningstar.com> from "William Allen Simpson" at Jan 12, 96 10:16:52 pm X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Content-Length: 876 Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net William Allen Simpson wrote: > > Assume you get an AH/ESP protected ip packet from source A. You check the > > authentication, and it is the correct authentication for an association > > you have with node A. Now you decode ESP, and see the payload is IP, thus > > you give it back to the IP handling part of your kernel. > > > > This encapsulated IP packet claims to come from node B, and as part of an > > UDP data exchange will be passed up to the application. The application has > > been tricked in accepting the packet. Bad. > The security association is with A. You trust A. If the packet from A > is really from another incarnation of A called B, that's fine. Mobility. Well, yes, I trust A, but I sure would not like A to impersonate B. An SPI belonging to A is used to send me traffic for B. Just imagine A being my news-server, and B my NFS server... Germano From ipsec-owner@p-o.ans.net Sun Jan 14 14:52:13 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14835 (5.65c/IDA-1.4.4 for ); Sun, 14 Jan 1996 18:14:36 -0500 Received: by p-o.ans.net id AA17122 (5.65c/IDA-1.4.4 for ipsec-outgoing); Sun, 14 Jan 1996 23:09:57 GMT Date: Sun, 14 Jan 96 14:52:13 GMT From: "William Allen Simpson" Message-Id: <4731.bsimpson@morningstar.com> To: ipsec@ans.net Subject: Re: Tunneling / Cheating Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net > From: Germano Caronni > William Allen Simpson wrote: > > The security association is with A. You trust A. If the packet from A > > is really from another incarnation of A called B, that's fine. Mobility. > > Well, yes, I trust A, but I sure would not like A to impersonate B. > An SPI belonging to A is used to send me traffic for B. Just imagine A > being my news-server, and B my NFS server... > How is this a problem? You trust A as a news-server. You would never grant it permission to be your NFS-server, just because it has _any_ SPI that you recognize. If the SPI is associated exclusively with your news-server, that is a parameter in your SA. If, on the other hand, you gave the same SPI keys to more than one server, why then your policy must be that either can be the NSF-server. That policy is entirely up to you! This is what I understand to be "user-oriented" keying, and requires some significant changes in the transport and application API. Note how Karn described his stack earlier. His SPI really _IS_ an "index" (which is why I coined the name) used to find the SA parameters. It is passed up the stack. The application takes note of the SPI, not the IP Source. 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-owner@p-o.ans.net Mon Jan 15 18:52:18 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA12940 (5.65c/IDA-1.4.4 for ); Mon, 15 Jan 1996 13:56:10 -0500 Received: by p-o.ans.net id AA38622 (5.65c/IDA-1.4.4 for ipsec-outgoing); Mon, 15 Jan 1996 18:52:26 GMT Date: Mon, 15 Jan 1996 10:52:18 -0800 From: Ran Atkinson Message-Id: <199601151852.KAA21285@puli.cisco.com> To: ipsec@ans.net Subject: Re: Tunneling / Cheating & diverging assumptions In-Reply-To: <4731.bsimpson@morningstar.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Folks, [General note: Different folks are posting answers that might be valid under different implicit assumptions. It is important that folks' try to make very explicit what their assumptions are -- in particular it makes a HUGE difference whether host-oriented keying or user-oriented keying is being used for a packet. I've tried to make my own assumptions more clear, but if I've failed to be sufficiently clear please don't flame me, just enquire gently. Steve Kent has been consistently precise in his router scenario and could stand to be emulated by others in this regard. :-] >> Well, yes, I trust A, but I sure would not like A to impersonate B. >> An SPI belonging to A is used to send me traffic for B. Just imagine A >> being my news-server, and B my NFS server... In article <4731.bsimpson@morningstar.com> Bill Simpson wrote: >How is this a problem? Assume that host-oriented keying is in use (this IS explicitly permitted with IPsec). With that assumption (very likely to be true when one has a router encrypting packets originating at some other node), then the attack outlined at the top is a real threat and comparing inner/outer source IP addresses is a sufficient defence against that threat. For this reason, the NRL implementation includes that defence. Also, the NRL implementation of an SA has a field used to store the address of a "proxy" encryptor (e.g. an encrypting router that is explicitly trusted to protect some host that can't encrypt its own packets) so that in future (after we've solved the encrypting router issues that Steve Kent has carefully outlined) host-oriented keying can safely be used in this scenario. > You trust A as a news-server. You would never > grant it permission to be your NFS-server, just because it has _any_ SPI > that you recognize. If the SPI is associated exclusively with your > news-server, that is a parameter in your SA. > >If, on the other hand, you gave the same SPI keys to more than one >server, why then your policy must be that either can be the NSF-server. >That policy is entirely up to you! > >This is what I understand to be "user-oriented" keying, and requires >some significant changes in the transport and application API. Your outline above is not _necessarily_ user-oriented keying, though it might be. Your text is sufficiently imprecise that it isn't clear to the reader what your assumptions are. Moreover, user-oriented keying, as _already implemented_ in the NRL IPsec implementation, simply didn't require big changes to BSD. Essentially, the application now has additional network socket options that can be set (e.g. authentication required, authentication required with a unique key, encryption requested but not required, encryption required, encryption with unique key required). User-oriented keying is enabled whenever a unique key is requested via setsockopt() OR whenever the system administrator has set the minimum system security level to require unique keying for each session. User-oriented keying, which is required to be _implemented_ in hosts but is NOT required to be _used_ by users, would map an SA to a particular network socket (and thence implicitly to the owner of that network socket) OR to a mailbox identifier (and thence it might be authorisation for any socket owned by the user having that mailbox identifier). The other set of assumptions to watch out for in notes to this list relate to whether a node is running a single-user operating system (e.g. KA9Q with DOS, routers based on KA9Q, Windows95, MacOS) or a multi-user operating system (e.g. UNIX, ClosedVMS, most routers, WindowsNT). Between single-user systems, having a key is often implicitly using user-oriented keying. From a multi-user system to a single-user system, possession of the key does not imply user-oriented keying, though it might have been used that way. There can be risks if one isn't thoughtful (e.g. if some user "Bill" has a host-oriented SA between an IETF workstation and his KA9Q PC, but then some other user "Tony" uses the SA "Bill" configured on that IETF workstation to improperly access Bill's PC -- to give a purely hypothetical example :-). Between multi-user systems, host-oriented keying cannot be used by itself to distinguish users and other methods (e.g. logins/passwords) should be used. Ran rja@cisco.com Note 1: I use the term "mailbox identifier" to mean the tuple of (userid, fully-qualified domain name of node). For example, mine might be expressed as either (rja, inet.org) or rja@inet.org. Note 2: One of the items that really needs to be fixed in RFC-1825-bis is specifying what kinds of names are used with IPsec. Many of our list discussions would be obviated if we had agreement on naming. This problem was noted a year ago but was not fixable then for lack of time. It needs to be fixed before Draft Standard, IMHO. Now would be an appropriate time for people to explain their preferences on naming. From ipsec-owner@p-o.ans.net Mon Jan 15 09:38:40 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14853 (5.65c/IDA-1.4.4 for ); Mon, 15 Jan 1996 14:41:46 -0500 Received: by p-o.ans.net id AA16903 (5.65c/IDA-1.4.4 for ipsec-outgoing); Mon, 15 Jan 1996 19:39:12 GMT Date: Mon, 15 Jan 96 14:38:40 EST From: cfm@columbia.sparta.com (Carl Muckenhirn) Message-Id: <9601151938.AA15687@columbia.sparta.com> To: ipsec@ans.net Subject: Re: Tunneling / Cheating Cc: c@columbia.sparta.com Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net /. From ipsec-owner@p-o.ans.net Wed Jan 24 06:14:55 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14945 (5.65c/IDA-1.4.4 for ); Wed, 24 Jan 1996 02:07:04 -0500 Received: by p-o.ans.net id AA04696 (5.65c/IDA-1.4.4 for ipsec-outgoing); Wed, 24 Jan 1996 06:15:04 GMT Date: Tue, 23 Jan 1996 23:14:55 -0700 From: Hilarie Orman Message-Id: <9601240614.AA31126@uncial.CS.Arizona.EDU> To: ipsec@ans.net Subject: UA xkernel release Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net I've placed a release of all of the xkernel software in our ftp area. This is our protocol development toolkit, with particular pieces that might be of interest to this community. Our elliptic curve group over GF[2^155] subroutines are available, both standalone and for use with Photuris. Our implementations of Photuris (draft 08) and AH/ESP are also included. This software is not a drop-in Unix library --- the xkernel runs as a protocol simulator under most standard Unix systems, or as a supplementary networking facility under Mach3, but it is not suitable for nor intended for production use. Sketchy release notes (please read): ftp://ftp.cs.arizona.edu/xkernel/README.v3.2.sec The full manual ftp://ftp.cs.arizona.edu/xkernel/manual-v3.2.security.ps.Z The entire source base xkernel.v3.2.security.tar.Z From ipsec-owner@p-o.ans.net Wed Jan 31 00:03:44 1996 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA15780 (5.65c/IDA-1.4.4 for ); Tue, 30 Jan 1996 19:08:51 -0500 Received: by p-o.ans.net id AA44659 (5.65c/IDA-1.4.4 for ipsec-outgoing); Wed, 31 Jan 1996 00:03:07 GMT From: markson@osmosys.incog.com (Tom Markson) Message-Id: <9601310003.AA06511@monster.incog.com> Subject: X.509 source library To: ipsec@ans.net Date: Tue, 30 Jan 1996 16:03:44 -0800 (PST) X-Mailer: ELM [version 2.4 PL24 PGP5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Hi, Sun Microsystems is pleased to announce the release of source code to an exportable version our X.509 Certificate library. It features: o Encoding for Version 1 X.509 certificates (X509Cert, X509Skip) o Encoding of Hashed Public Key Certificates (HashCert) o Useful primitive Classes such as Bstream. o Generic Interface Class (SkipCert) o ASN BER encoder/decoder o MD2 and MD5 Hash Functions o SHA-1 Hash Function o Includes Big Number library written by Colin Plumb. Note: This library can only encode or decode Certificates. It is unable to sign or verify signatures on certificates. This is a nontrivial library and the documentation is minimal. If you are not a developer, who is i interested in digging into C++ class libraries, this library may not be for you. You can find more information at http://skip.incog.com ---------------------------------------------------------------------------- License for this software: Copyright (C) 1994, 1995, 1996 Sun Microsystems, Inc. All Rights Reserved. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software or derivatives of the Software, and to permit persons to whom the Software or its derivatives is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL SUN MICROSYSTEMS, INC., BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR DERIVATES OF THIS SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Except as contained in this notice, the name of Sun Microsystems, Inc. shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software or its derivatives without prior written authorization from Sun Microsystems, Inc. -- Tom Markson Internet Commerce Group Sun Microsystems, Inc