Received: from relay.hq.tis.com by neptune.TIS.COM id aa29884; 1 Aug 96 3:58 EDT Received: by relay.hq.tis.com; id EAA08190; Thu, 1 Aug 1996 04:01:19 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma008183; Thu, 1 Aug 96 04:00:55 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA11687; Thu, 1 Aug 96 04:00:27 EDT Received: by relay.hq.tis.com; id EAA08175; Thu, 1 Aug 1996 04:00:53 -0400 Received: from toad.com(140.174.2.1) by relay.tis.com via smap (V3.1.1) id xma008154; Thu, 1 Aug 96 04:00:19 -0400 Received: from localhost (localhost [127.0.0.1]) by toad.com (8.7.5/8.7.3) with SMTP id BAA20589; Thu, 1 Aug 1996 01:02:40 -0700 (PDT) Message-Id: <199608010802.BAA20589@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Ran Atkinson <rja@cisco.com> Cc: ipsec@TIS.COM, postel@isi.edu, gnu@toad.com Subject: Re: Key Management, anyone? (DNS keying) In-Reply-To: <199607230358.UAA20330@puli.cisco.com> Date: Thu, 01 Aug 1996 01:02:40 -0700 From: John Gilmore <gnu@toad.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk Ran Atkinson said: > The IETF requires that _implementations_ of IP also _implement_ > support for DNS. The IETF does NOT require that users actually _USE_ > DNS. Now most users DO use DNS because it is widely implemented and > it is often easier to use than typing an IP number. However, on > occasion users (e.g. me) don't use DNS and instead just type an IP > number on the command line (e.g. "telnet 1.2.3.4") and this isn't > violating any IETF requirement. I agree it's desirable to maintain the ability to use manual keying, like the ability to use manual IP addressing. > Similarly, the IPsec WG would be wrong to try to mandate that "users > MUST use DNS to obtain IPsec keys", while it might be very legitimate > for the IPsec WG to mandate that "IPsec implementations SHOULD/MUST > also implement support for DNSsec" if that is what the IPsec WG were > to decide to do. [1] In the context of "If you use the IPSEC WG's key management protocol", it would be a perfectly fine statement for us to say "the key management software MUST use DNS to obtain IPsec keys". It's like the SMTP spec saying that mailers MUST look for DNS MX records rather than simply looking up domain names in a "host table" file somewhere. If we build a mechanism to solve a problem, and expect to use it widely, then we should mandate its use in that problem domain, to guarantee interoperability. The effort we're going through to define a single key management protocol would be wasted, if that unified key management protocol ended up having to try six different ways to find the other guy's public key. Or to find out if the other guy supports IPSEC at all. Those folks who use somebody else's key management protocol, of course, can get keys by telepathy, voodoo, or by extracting them from a key escrow database. The WG should never say "this is the only key management protocol or key publication protocol you can use". Instead it's "if you want to interoperate with all the other hosts that use this standard, then you should use the protocols we specify". Communications networks that have different needs are completely free to implement both WG-keying to talk to the public and e.g. MIL-keying to talk to each other. The military will be using different packet-level transforms as well, since Skipjack is not as far as I know on the IETF standards track. That would be troublesome, since there is no published spec. I don't think NSA can twist IESG's arm the way they twisted NIST's, to issue a standard which says "Poof, it's a standard, even though we refuse to tell you how it works". They might even have trouble getting IANA to issue them an algorithm number without specifying the algorithm that it identifies. Given that the key-escrowed government network will not use either IPSEC standard transforms, or an IPSEC standard key exchange protocol like Oakley or Photuris, it clearly need not use DNS keys either. But by the same token, their needs or desires are no reason for the rest of us to *avoid* using DNS keys. > NOTE 1: IETF rules prohibit a standards-track RFC at level N in the standards > process from back referencing a standards-track RFC at a level less > than N. At present, IPsec is a Proposed Standard and DNSsec is not > a standards-track RFC. This winter, IPsec will probably move to > Draft Standard, but DNSsec is required to remain at Proposed Standard > until (1) at least 6 months have passed since publication as a > Proposed Standard RFC and (2) interoperability of multiple independent > implementations is demonstrated. Hence, if the IPsec RFCs mandate > implementation of DNSsec, then the progress of the IPsec RFCs is > likely to be delayed accordingly. It is up to the WG as a whole > to develop consensus on whether such an explicit standards-dependence > is desirable. Ran, please don't try to mislead the group on procedural issues. The only IPSEC RFC that would require the use of DNSSEC (if any did) is the IPSEC key management RFC. It isn't yet an Internet-Draft, let alone a standards-track RFC; it's still being hashed out in a smoke-filled room upon Jeff Schiller's request. DNSSEC will be way ahead of it in the standards track, so there is no delay issue. John Gilmore Received: from relay.hq.tis.com by neptune.TIS.COM id aa00883; 1 Aug 96 5:09 EDT Received: by relay.hq.tis.com; id FAA08730; Thu, 1 Aug 1996 05:11:48 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma008728; Thu, 1 Aug 96 05:11:19 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA12829; Thu, 1 Aug 96 05:10:52 EDT Received: by relay.hq.tis.com; id FAA08725; Thu, 1 Aug 1996 05:11:18 -0400 Received: from copernicus.hpc.org(192.187.8.4) by relay.tis.com via smap (V3.1.1) id xma008723; Thu, 1 Aug 96 05:11:08 -0400 Received: from earth.hpc.org (earth.hpc.org [192.187.8.34]) by hpc.org (8.7.1/8.7.1) with SMTP id FAA29883; Thu, 1 Aug 1996 05:16:26 -0400 (EDT) Received: by earth.hpc.org (SMI-8.6/SMI-SVR4) id FAA21838; Thu, 1 Aug 1996 05:15:04 -0400 Date: Thu, 1 Aug 1996 05:15:04 -0400 From: Hilarie Orman <ho@earth.hpc.org> Message-Id: <199608010915.FAA21838@earth.hpc.org> To: PALAMBER@us.oracle.com Cc: ipsec@TIS.COM In-Reply-To: Yourmessage <9607312301.AA16100@maildig1.us.oracle.com> Subject: Re: DNS? was Re: Key Management, anyone? Sender: ipsec-approval@neptune.tis.com Precedence: bulk I agree with the individual points, but I'm not convinced by the conclusion. Why isn't DNSSEC the appropriate minimal common basis for authentication? I believe we need such a basis, and DNSSEC seems to be the obvious choice. This wouldn't rule out the optional use of other methods. TCP requires IP, so the IETF guidelines cannot be taken too seriously in the regard to banning protocol dependencies! Received: from relay.hq.tis.com by neptune.TIS.COM id aa03367; 1 Aug 96 8:04 EDT Received: by relay.hq.tis.com; id IAA09912; Thu, 1 Aug 1996 08:06:49 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma009894; Thu, 1 Aug 96 08:06:22 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA16213; Thu, 1 Aug 96 08:05:54 EDT Received: by relay.hq.tis.com; id IAA09888; Thu, 1 Aug 1996 08:06:20 -0400 Received: from servo.qualcomm.com(129.46.128.14) by relay.tis.com via smap (V3.1.1) id xma009864; Thu, 1 Aug 96 08:05:57 -0400 Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id FAA18604; Thu, 1 Aug 1996 05:08:09 -0700 (PDT) Date: Thu, 1 Aug 1996 05:08:09 -0700 (PDT) From: Phil Karn <karn@qualcomm.com> Message-Id: <199608011208.FAA18604@servo.qualcomm.com> To: adams@tgv.com Cc: ipsec@TIS.COM, naganand@ftp.com In-Reply-To: <19960731140101adams@North-Bridge.cisco.com> (message from Rob Adams on Wed Jul 31 14:01:01 1996) Subject: Re: Question on TCP MSS with repsect to IPSEC Sender: ipsec-approval@neptune.tis.com Precedence: bulk You can only do so much to reduce TCP segment sizes to account for IPSEC headers. Especially since a very common (if not the single most important) case of tunnel mode assumes a TCP that knows nothing about IPSEC. The best you can really hope for is Path MTU support on the sending TCP that will respond appropriately to ICMP messages from an IPSEC tunnel endpoint that knows what its next hop interface MTU is after being adjusted for IPSEC overhead. Phil Received: from relay.hq.tis.com by neptune.TIS.COM id aa04633; 1 Aug 96 9:08 EDT Received: by relay.hq.tis.com; id JAA11607; Thu, 1 Aug 1996 09:11:17 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma011600; Thu, 1 Aug 96 09:10:48 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA19537; Thu, 1 Aug 96 09:10:20 EDT Received: by relay.hq.tis.com; id JAA11594; Thu, 1 Aug 1996 09:10:47 -0400 Received: from ftp.com(128.127.2.122) by relay.tis.com via smap (V3.1.1) id xma011591; Thu, 1 Aug 96 09:10:33 -0400 Received: from ftp.com by ftp.com ; Thu, 1 Aug 1996 09:12:52 -0400 Received: from athena.ftp.com by ftp.com ; Thu, 1 Aug 1996 09:12:52 -0400 Message-Id: <2.2.32.19960801131747.009ac5f4@mailserv-H.ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 01 Aug 1996 09:17:47 -0400 To: Phil Karn <karn@qualcomm.com> From: Naganand Doraswamy <naganand@ftp.com> Subject: Re: Question on TCP MSS with repsect to IPSEC Cc: adams@tgv.com, ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Phil, >The best you can really hope for is Path MTU support on the sending >TCP that will respond appropriately to ICMP messages from an IPSEC >tunnel endpoint that knows what its next hop interface MTU is after >being adjusted for IPSEC overhead. > Doesnt the ICMP message indicate the datagram size (IP Header + data) that it can send? This being the case, the router or tunnel end point may not take into account the overhead of IPSEC, correct? In this scenario, it will be upto the host sending the IPSEC traffic to adjust the tcp data size. Thanks, --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) Received: from relay.hq.tis.com by neptune.TIS.COM id aa06054; 1 Aug 96 10:08 EDT Received: by relay.hq.tis.com; id KAA13222; Thu, 1 Aug 1996 10:11:38 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma013215; Thu, 1 Aug 96 10:11:10 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA22839; Thu, 1 Aug 96 10:10:42 EDT Received: by relay.hq.tis.com; id KAA13208; Thu, 1 Aug 1996 10:11:08 -0400 Received: from fnal.fnal.gov(131.225.110.17) by relay.tis.com via smap (V3.1.1) id xma013198; Thu, 1 Aug 96 10:10:43 -0400 Received: from munin.fnal.gov ("port 3517"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I7R8IQU1JM001G3M@FNAL.FNAL.GOV>; Thu, 01 Aug 1996 09:13:05 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m) id JAA02474; Thu, 01 Aug 1996 09:11:31 -0500 (CDT) Date: Thu, 01 Aug 1996 09:11:30 -0500 From: Matt Crawford <crawdad@fnal.gov> Subject: Re: Question on TCP MSS with repsect to IPSEC In-Reply-To: "01 Aug 1996 05:08:09 PDT." <"199608011208.FAA18604"@servo.qualcomm.com> To: Phil Karn <karn@qualcomm.com> MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Cc: adams@tgv.com, ipsec@TIS.COM, naganand@ftp.com Message-Id: <199608011411.JAA02474@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{<k&QF?d6L7o&zLqb%kXn!!]ykXMKtTiy9#20]$EKP/^Z$T]'P6, 8L#r&mH4PB<ljN,_.=iCpv#N:HIcy5t7{HV:<=g=V?^;-d,J*xkq0r Sender: ipsec-approval@neptune.tis.com Precedence: bulk > You can only do so much to reduce TCP segment sizes to account for > IPSEC headers. Especially since a very common (if not the single most > important) case of tunnel mode assumes a TCP that knows nothing about > IPSEC. Pardon my cloddish opinion, but I think that's the EASY case. The tunnel's far end will decapsulate and the receiver will find its MSS has been respected. > The best you can really hope for is Path MTU support on the sending > TCP that will respond appropriately to ICMP messages from an IPSEC > tunnel endpoint that knows what its next hop interface MTU is after > being adjusted for IPSEC overhead. I think we've all been presuming an implicit MIN(PMTU, MSS+10*ip->ip_v). _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A Received: from relay.hq.tis.com by neptune.TIS.COM id aa08256; 1 Aug 96 11:51 EDT Received: by relay.hq.tis.com; id LAA16379; Thu, 1 Aug 1996 11:54:18 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma016376; Thu, 1 Aug 96 11:54:10 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA01031; Thu, 1 Aug 96 11:53:28 EDT Received: by relay.hq.tis.com; id LAA16366; Thu, 1 Aug 1996 11:53:21 -0400 Received: from guardian.guard.ncsc.mil(144.51.52.1) by relay.tis.com via smap (V3.1.1) id xma016350; Thu, 1 Aug 96 11:52:54 -0400 Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id LAA13272 for <ipsec@TIS.COM>; Thu, 1 Aug 1996 11:55:17 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma013267; Thu Aug 1 11:55:04 1996 Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id LAA13723 for <ipsec@TIS.COM>; Thu, 1 Aug 1996 11:51:42 -0400 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id LAA02388; Thu, 1 Aug 1996 11:54:55 -0400 Date: Thu, 1 Aug 1996 11:54:55 -0400 From: "David P. Kemp" <dpkemp@missi.ncsc.mil> Message-Id: <199608011554.LAA02388@argon.ncsc.mil> To: ipsec@TIS.COM Subject: Re: Key Management, anyone? (DNS keying) X-Sun-Charset: US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk John Gilmore wrote: > In the context of "If you use the IPSEC WG's key management protocol", > it would be a perfectly fine statement for us to say "the key > management software MUST use DNS to obtain IPsec keys". That is unacceptable, given the current state of DNSsec. I don't believe that the requirement to use real certificates for IPSEC keying is going to disappear, and DNSsec has made an explicit decision not to support X.509, PGP, or any other mainstream certificate format. > Those folks who use somebody else's key management protocol, of course, > can get keys by telepathy, voodoo, or by extracting them from a key > escrow database. Instead of telepathy and voodoo, perhaps keys could be gotten by using LDAP (RFC 1777/1798, or LDAP V3: draft-ietf-asid-ldapv3-protocol-01.txt). Or they could be gotten from a Web directory server using URLs as pointers. Or instead of X.509, certificates could be in SPKI format as defined by Ellison, Frantz, and Thomas. Will DNSsec support SPKI certificates? This isn't about "somebody else's" protocol; we're talking about the IPSEC key management protocol which will standardize a set of mandatory, recommended, and optional mechanisms. Manual keying and proprietary key management can still be used with IPSEC data transforms, of course, but that's not particularly germaine to the topic of IPSEC key management. > The WG should never say "this is the only key > management protocol or key publication protocol you can use". Instead > it's "if you want to interoperate with all the other hosts that use > this standard, then you should use the protocols we specify". That is contradictory to the first paragraph. I believe the IPSEC WG position is: "Implementations of the (yet-to-be-agreed-upon) IPSEC Key Management Protocol MUST *include code* to support using DNS to obtain keys." There appears to be rough consensus for that position; I will agree to disagree as long as DNSsec keys are limited to the existing format. But there is no WG requirement that they "MUST *use* DNS to obtain keys." If you want to interoperate with other hosts, you need to implement a mechanism (recommended or required) that is implemented on those other hosts. It is entirely possible that a recommended mechanism could achieve nearly universal coverage, if the mandatory mechanism doesn't meet user's needs. DNS is well-suited as a mechanism to distribute keys associated with IP addresses. It is not as well-suited as an exclusive mechanism to generate and certify long-term keys. It could be used as a default for users who aren't motivated to use any other method. But if I were a cheap Internet user (I am! :-) and had just shelled out a whole 6 bucks for a Verisign cert, I would want to be able to use it. With the world, not just with other owners of the same brand of firewall. The trust models of DNSsec are currently controversial. If it is technically impossible to define DNS RRs to carry X.509, SPKI, or PGP certs (because of their size), then it should at least be possible to define RRs to carry URLs or DNs to allow certs to be retrieved from some other directory. I view that step as a requirement before making a mandatory link between IPSEC key management and DNSsec. > The military will be using different packet-level transforms as well, > since Skipjack is not as far as I know on the IETF standards track. > That would be troublesome, since there is no published spec. I don't > think NSA can twist IESG's arm the way they twisted NIST's, to issue a > standard which says "Poof, it's a standard, even though we refuse to > tell you how it works". They might even have trouble getting IANA to > issue them an algorithm number without specifying the algorithm that > it identifies. Hogwash. 1) The military will be using DES/3DES transforms just like everyone else to get interoperability with the rest of the world. The military believes that there are security advantages to doing crypto in hardware, as well as potential performance advantages and disadvantages, and is including DES in FORTEZZA(tm). (See recent GCN article by Paul Constance.) 2) FORTEZZA(tm) (including Skipjack) is on the IETF standards track, as an algorithm suite in the Transport Layer Security (TLS) protocol. That doesn't imply that anyone other than posessors of FORTEZZA(tm) cards will be expected, or even able, to use that particular mechanism. It meets the need of a large community of users; no objections to standardization of FORTEZZA(tm) as an optional CipherSuite have been raised, or even mentioned, within the TLS WG. Sorry for shouting the name of the card; the lawyers made me do it :-(. Received: from relay.hq.tis.com by neptune.TIS.COM id aa15592; 1 Aug 96 19:18 EDT Received: by relay.hq.tis.com; id TAA00107; Thu, 1 Aug 1996 19:21:08 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma000103; Thu, 1 Aug 96 19:20:41 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA24791; Thu, 1 Aug 96 19:20:12 EDT Received: by relay.hq.tis.com; id TAA29999; Thu, 1 Aug 1996 19:20:38 -0400 Received: from relay.hp.com(15.255.152.2) by relay.tis.com via smap (V3.1.1) id xma029993; Thu, 1 Aug 96 19:20:28 -0400 Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA015741758; Thu, 1 Aug 1996 16:22:38 -0700 Message-Id: <199608012322.AA015741758@relay.hp.com> Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com id AA155051756; Thu, 1 Aug 1996 19:22:36 -0400 To: "David P. Kemp" <dpkemp@missi.ncsc.mil> Cc: ipsec@TIS.COM, ietf-tls@w3.org Subject: Re: Key Management, anyone? (DNS keying) In-Reply-To: dpkemp's message of Thu, 01 Aug 1996 11:54:55 -0400. <199608011554.LAA02388@argon.ncsc.mil> Date: Thu, 01 Aug 1996 19:22:35 -0400 From: Bill Sommerfeld <sommerfeld@apollo.hp.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk > 2) FORTEZZA(tm) (including Skipjack) is on the IETF standards track, as > an algorithm suite in the Transport Layer Security (TLS) protocol. > That doesn't imply that anyone other than posessors of FORTEZZA(tm) > cards will be expected, or even able, to use that particular mechanism. > It meets the need of a large community of users; no objections to > standardization of FORTEZZA(tm) as an optional CipherSuite have been > raised, or even mentioned, within the TLS WG. well, as best I can tell, there's NO WAY for a classified algorithm to be on the IETF standards track. RFC1602 says: (A) ISOC will not propose, adopt, or continue to maintain any standards, including but not limited to standards labelled Proposed, Draft or Internet Standards, which can only be practiced using technology or works that are subject to known copyrights, patents or patent applications, or other rights, except with the prior written assurance of the owner of rights that: l. ISOC may, without cost, freely implement and use the technology or works in its standards work; 2. upon adoption and during maintenance of an Internet Standard, any party will be able to obtain the right to implement and use the technology or works under specified, reasonable, non-discriminatory terms; and 3. the party giving the assurance has the right and power to grant the licenses and knows of no other copyrights, patents, patent applications, or other rights that may prevent ISOC and members of the Internet community from implementing and operating under the standard. Now, this is part of the part of 1602 which was generally felt to be "broken". However, the replacement for RFC1602, draft-ietf-poised95-std-proc-3-06.txt, says: 7.1.2 Incorporation of Other Specifications Other proprietary specifications may be incorporated by reference to a version of the specification as long as the proprietor meets the requirements of section 10. If the other proprietary specification is not widely and readily available, the IESG may request that it be published as an Informational RFC. The IESG generally should not favor a particular proprietary specification over technically equivalent and competing specification(s) by making any incorporated vendor specification "required" or "recommended". and, later on: 10.2 Confidentiality Obligations No contribution that is subject to any requirement of confidentiality or any restriction on its dissemination may be considered in any part of the Internet Standards Process, and there must be no assumption of any confidentiality obligation with respect to any such contribution. - Bill Received: from relay.hq.tis.com by neptune.TIS.COM id aa15628; 1 Aug 96 19:21 EDT Received: by relay.hq.tis.com; id TAA00213; Thu, 1 Aug 1996 19:24:09 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma000206; Thu, 1 Aug 96 19:23:40 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA24851; Thu, 1 Aug 96 19:23:12 EDT Received: by relay.hq.tis.com; id TAA00203; Thu, 1 Aug 1996 19:23:38 -0400 Received: from hubbub.cisco.com(198.92.30.31) by relay.tis.com via smap (V3.1.1) id xma000185; Thu, 1 Aug 96 19:23:12 -0400 Received: from spook (dharkins-ss20.cisco.com [171.69.60.241]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with ESMTP id QAA19487 for <ipsec@tis.com>; Thu, 1 Aug 1996 16:29:11 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by spook (8.6.8+c/CISCO.WS.1.1) with SMTP id QAA00232 for <ipsec@tis.com>; Thu, 1 Aug 1996 16:25:49 -0700 Message-Id: <199608012325.QAA00232@spook> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: ipsec@TIS.COM Subject: New ISAKMP+Oakley code! Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 01 Aug 1996 16:25:48 -0700 From: Daniel Harkins <dharkins@cisco.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk Cisco Systems is pleased to announce the release of the next version of their ISAKMP daemon. This software distribution is being made available free of charge for any commercial or non-commercial use to advance ISAKMP as a solution to Internet Key Management. Major changes from the previous version include: * Compliance with draft-ietf-ipsec-isakmp-oakley-01.txt * HMAC-MD5 ("derived from the RSA Data Security, Inc. MD5 Message- Digest Algorithm") and HMAC-SHA. * Colin Plumb's BigNum multiprecision integer library. * truerand() random number generator by Don Mitchell and Matt Blaze. To software can be obtained by pointing your favorite browser to http://www.cisco.com/public/library/isakmp/isakmp.html and following the hot links. This entire distribution is export controlled and unfortunately cannot be obtained by non-US citizens or non-US permanent residents. This daemon uses the PF_KEY Key Management API to register with a kernel which has implemented this API and the surrounding key management infrastructure. The NRL IPsec software distribution (currently bundled with IPv6) is such an implementation. Security associations negotiated by the ISAKMP daemon are inserted into the kernel's key engine and are available for use by its AH/ESP security mechanisms. To facilitate use of this ISAKMP daemon, the NRL distribution is also being made available an the same URL described above. This distribution comes with a cryptographic library from Cylink Corporation. Cylink has granted Cisco the right to offer this library-- source code to the Diffie-Hellman key exchange, the Digital Signature Standard, and the Digital Encryption Standard-- to all third parties on a royalty-free basis for use only with this ISAKMP reference implementation. Note: Both the BigNum package and the cryptographic library come with exercise routines to validate each package. If errors occur and the respective README is not helpful, please contact the mailing list below for help. If either the BigNum package or the cryptographic library is not in full working order, the ISAKMP daemon will not work properly. A mailing list for problems, bug fixes, porting changes, and general discussion of ISAKMP and Oakley has been established: isakmp-oakley@cisco.com (majordomo@cisco.com for admin requests). Received: from relay.hq.tis.com by neptune.TIS.COM id aa17487; 1 Aug 96 22:04 EDT Received: by relay.hq.tis.com; id WAB02141; Thu, 1 Aug 1996 22:07:09 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma002137; Thu, 1 Aug 96 22:06:40 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA27940; Thu, 1 Aug 96 22:06:13 EDT Received: by relay.hq.tis.com; id WAA02134; Thu, 1 Aug 1996 22:06:39 -0400 Received: from newdev.harvard.edu(128.103.65.15) by relay.tis.com via smap (V3.1.1) id xma002131; Thu, 1 Aug 96 22:06:20 -0400 Received: (from sob@localhost) by newdev.harvard.edu (8.7.3/8.6.10-MT4.00) id WAA00346; Thu, 1 Aug 1996 22:08:38 -0400 (EDT) Date: Thu, 1 Aug 1996 22:08:38 -0400 (EDT) From: Scott Bradner <sob@newdev.harvard.edu> MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Message-Id: <199608020208.WAA00346@newdev.harvard.edu> To: dpkemp@missi.ncsc.mil, sommerfeld@apollo.hp.com Subject: Re: Key Management, anyone? (DNS keying) Cc: ietf-tls@w3.org, ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk > well, as best I can tell, there's NO WAY for a classified algorithm to > be on the IETF standards track. > > rfc1602 sez: note that RFC 1602 has been replaced and is no longer the IETF standards process - the new process has not yet been published as an RFC but can be found in the internet-drafts directory as: draft-ietf-poised95-std-proc-3-06.txt This new version changes the IPR rules quite a bit and the cited language is no longer in the document. Scott Received: from relay.hq.tis.com by neptune.TIS.COM id aa18460; 1 Aug 96 23:32 EDT Received: by relay.hq.tis.com; id WAA02155; Thu, 1 Aug 1996 22:09:39 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma002151; Thu, 1 Aug 96 22:09:11 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA27970; Thu, 1 Aug 96 22:08:43 EDT Received: by relay.hq.tis.com; id WAA02148; Thu, 1 Aug 1996 22:09:09 -0400 Received: from newdev.harvard.edu(128.103.65.15) by relay.tis.com via smap (V3.1.1) id xma002146; Thu, 1 Aug 96 22:09:02 -0400 Received: (from sob@localhost) by newdev.harvard.edu (8.7.3/8.6.10-MT4.00) id WAA00355; Thu, 1 Aug 1996 22:11:26 -0400 (EDT) Date: Thu, 1 Aug 1996 22:11:26 -0400 (EDT) From: Scott Bradner <sob@newdev.harvard.edu> Message-Id: <199608020211.WAA00355@newdev.harvard.edu> To: dpkemp@missi.ncsc.mil, sommerfeld@apollo.hp.com Subject: Re: Key Management, anyone? (DNS keying) Cc: ietf-tls@w3.org, ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk oops - I did not read far enough in the note - if the proposal deals with a classified algorithm then I agree with your reading Scott Received: from relay.hq.tis.com by neptune.TIS.COM id aa24933; 2 Aug 96 8:36 EDT Received: by relay.hq.tis.com; id IAA08306; Fri, 2 Aug 1996 08:39:26 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma008290; Fri, 2 Aug 96 08:39:07 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA11034; Fri, 2 Aug 96 08:38:38 EDT Received: by relay.hq.tis.com; id IAA08283; Fri, 2 Aug 1996 08:38:56 -0400 Received: from mail.border.com(199.71.190.98) by relay.tis.com via smap (V3.1.1) id xma008272; Fri, 2 Aug 96 08:38:52 -0400 Received: by janus.border.com id <18505-1>; Fri, 2 Aug 1996 08:40:18 -0400 Message-Id: <96Aug2.084018edt.18505-1@janus.border.com> X-Mailer: exmh version 1.6.2 7/18/95 To: ipsec@TIS.COM Subject: Re: New ISAKMP+Oakley code! Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 2 Aug 1996 08:41:15 -0400 From: "Ozan S. Yigit" <oz@border.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk > ... This software distribution is being made available > free of charge for any commercial or non-commercial use to advance ISAKMP > as a solution to Internet Key Management. -------------- ------------- i thought isakmp and skip proposals were to be merged into a single proposal. i must have missed something between the ietf meetings and getting on the mailing list... oz Received: from relay.hq.tis.com by neptune.TIS.COM id aa28287; 2 Aug 96 11:32 EDT Received: by relay.hq.tis.com; id LAA25165; Fri, 2 Aug 1996 11:35:04 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma024864; Fri, 2 Aug 96 11:34:39 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA18929; Fri, 2 Aug 96 11:34:07 EDT Received: by relay.hq.tis.com; id LAA24801; Fri, 2 Aug 1996 11:34:33 -0400 Received: from copilot.is.chrysler.com(204.189.94.36) by relay.tis.com via smap (V3.1.1) id xma024609; Fri, 2 Aug 96 11:34:15 -0400 Received: by pilotx.firewall.is.chrysler.com; id LAA21207; Fri, 2 Aug 1996 11:36:25 -0400 Received: from mhbclpr2-le0.is.chrysler.com(172.29.128.206) by pilotx.is.chrysler.com via smap (g3.0.1) id sma021203; Fri, 2 Aug 96 11:36:02 -0400 Received: from rgm3 by mhbclpr2-nf0.is.chrysler.com (8.7.5/SMI-4.1) id LAA07124; Fri, 2 Aug 1996 11:29:05 -0400 (EDT) Message-Id: <2.2.32.19960802153331.00d1c01c@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: Fri, 02 Aug 1996 11:33:31 -0400 To: Derek Atkins <warlord@mit.edu>, dennis.glatting@plaintalk.bellevue.wa.us From: Robert Moskowitz <rgm3@chrysler.com> Subject: Re: DNSSEC for IPSEC? Cc: John Gilmore <gnu@toad.com>, ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 03:08 PM 7/26/96 EDT, Derek Atkins wrote: >> There is an issue. Storing the private key off-line is not >> a deterrent: the mischievous person simply generates a >> new key pair and re-signs the zone. > >Actually, this doesn't work. The problem is that the parent zone >needs to have signed the zone's key. So, I couldn't go and forge >a zone key for MIT.EDU, because the MIT.EDU key needs to be signed >by the EDU key, which in turn needs to be signed by the root key. > >So, you can't forge a key without forging the whole hierarchy. > Gee it sounds like a job for an AlterNIC... Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.hq.tis.com by neptune.TIS.COM id aa28655; 2 Aug 96 11:48 EDT Received: by relay.hq.tis.com; id LAA06117; Fri, 2 Aug 1996 11:51:35 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma005916; Fri, 2 Aug 96 11:51:14 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA19655; Fri, 2 Aug 96 11:50:42 EDT Received: by relay.hq.tis.com; id LAA05807; Fri, 2 Aug 1996 11:51:07 -0400 Received: from soscorp.soscorp.com(204.52.248.130) by relay.tis.com via smap (V3.1.1) id xma005557; Fri, 2 Aug 96 11:50:46 -0400 Received: from fearless.soscorp.com (fearless.soscorp.com [204.52.249.130]) by brimstone.soscorp.com ($Revision: 2.30 $/8.6.12/8.6.4.287) with BSMTP id BS0003595/LAA03602; Fri, 2 Aug 1996 11:53:09 -0400 Received: from fearless.soscorp.com (aggelos@localhost) by fearless.soscorp.com (8.6.12/8.6.4.287) with ESMTP id LAA02557; Fri, 2 Aug 1996 11:52:44 -0400 Message-Id: <199608021552.LAA02557@fearless.soscorp.com> To: dennis.glatting@plaintalk.bellevue.wa.us Cc: John Gilmore <gnu@toad.com>, ipsec@TIS.COM Subject: Re: DNSSEC for IPSEC? -- or, how to exploit DNSSEC In-Reply-To: Your message of "Sat, 27 Jul 1996 12:49:58 PDT." <199607271950.MAA00914@imo.plaintalk.bellevue.wa.us> Date: Fri, 02 Aug 1996 11:52:42 -0400 From: "Angelos D. Keromytis" <aggelos@soscorp.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk Better late than never i guess. In message <199607271950.MAA00914@imo.plaintalk.bellevue.wa.us>, Dennis Glattin g writes: > >The DNSSEC extensions document little addresses the >issue of key roll-over. Consequently, it is difficult to >differentiate between an alarm be sounded as a result of a >root server compromise and the attacker replacing its >key pair and one sounded in response to legitimate key >roll-over. The document mentions the issue of cross >signatures but does not indicate their role. I have not >found a document that addresses these issues. > I believe this is covered by mandating that any implementation should be able to handle at least 2 valid KEY records for each name (intro of section 3). >The DNSSEC extensions document recommends a procedure >for server private key management. That is all it is: a >recommendation. Is that how the entities managing the >root servers will manage them? Moreover, how are the root >servers themselves secured? How will the weakest link, >the people, be managed? > Lock em up and post a marine with an M16A2 outside the door ? Seriously tho, the draft is concerned with the technological aspect of security, not with the...social. No matter what key management one has, people will always be a potential leak/weak link/whatever. >Administrators tend to aggregate service classes to >"ease administration". The same set of procedures and >functions applied to one service are applied to all >members of the aggregate. Therefore, it is highly >probable that a technique used to penetrate one root >server is a successful avenue to another. Consequently, >it is possible to create a believable web of trust across >compromised servers. > I fail to see what this has to do with DNSSEC. Clearly, if a host is compromised, the assumptions on which IPSEC was built no longer hold. Besides, I still don't know why breaking into a DNS server (maybe a root ?) would somehow give you divine powers over the zone data; the private key is supposed to be offline. >When a parent zone changes its key, all its siblings will >have to be updated (hmm, what is the number of zones under >COM?). How will the administrators of those zones get the >new key? How can they trust what they are getting? Suppose >for a moment that a root server is compromised. Oh what >chaos one can create. Get the key through DNS, and this key is signed by the old key (if this is a normal rollover) and by whoever signs the keys for that root. Again, i assume that even the root keys are signed by one or more other "trusted" authorities (maybe IETF, ISOC etc should create a key just to sign root keys, which shouldn't happen all that often). >* A compromised server could redirect the address of the > trusted key repository, resulting in a schizophrenic > Internet. The old key is still in effect, so the server can't fake data. >* If bogus responses are believable, the cache of tens of > thousands of servers will quickly be polluted. To clean > them, those servers will have to be rebooted. The result > is something close to rebooting the Internet. See above. >* The root server can reduce TTL values to their minimum, > resulting in other servers often reloading the RRs > and recomputing SIGs -- watch their CPU load jump! That is true. However, also easily noticeable. >* How about increasing key sizes too. >Morris did nothing compared to the damage possible with >DNSSEC. > Expand on this ? >It is easy for a DNSSEC aware resolver to believe a >response from a DNSSEC aware source; however, in a >combined DNSSEC aware and unaware Internet, what is a >resolver going to do when it gets a response from a DNSSEC >unaware source? Ignore it? To do so would limit >resolution breadth. > Indicate to the user that this might not be as secure a lookup as he might think maybe. Let me ask something else in return. In a mixed IPSEC-using and not Internet, what is someone who wants to securely connect to some remote host that doesn't use IPSEC going to do ? >(Bear in mind that no body has the authority to impose >DNSSEC across the Internet. Therefore, the issue of >DNSSEC aware resolvers having to figure out what to do >with responses from DNSSEC unaware sources will not go >away.) > But it is not a totally impossible task either. There are a few approaches that will accelerate deployment of DNSSEC. > >What kind of chaos can be created if the server's code is >replaced? One thought is to always clear the AD bit in >responses. > Expand on this ? > >Does DNSSEC add value to IPSEC? Maybe. I believe that for >the next several years its value is limited. > There probably are alternatives, but they (probably) won't scale as good, and will require some sort of new infrastructure. -Angelos Received: from relay.hq.tis.com by neptune.TIS.COM id aa04934; 2 Aug 96 18:24 EDT Received: by relay.hq.tis.com; id SAA22853; Fri, 2 Aug 1996 18:26:46 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma022813; Fri, 2 Aug 96 18:26:07 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA05485; Fri, 2 Aug 96 18:25:29 EDT Received: by relay.hq.tis.com; id SAA22795; Fri, 2 Aug 1996 18:25:53 -0400 Received: from unix.ka9q.ampr.org(129.46.90.35) by relay.tis.com via smap (V3.1.1) id xma022779; Fri, 2 Aug 96 18:25:22 -0400 Received: (from karn@localhost) by unix.ka9q.ampr.org (8.7.4/8.7.3) id PAA04957; Fri, 2 Aug 1996 15:21:19 -0700 (PDT) Date: Fri, 2 Aug 1996 15:21:19 -0700 (PDT) Message-Id: <199608022221.PAA04957@unix.ka9q.ampr.org> From: Phil Karn <karn@unix.ka9q.ampr.org> To: naganand@ftp.com Cc: adams@tgv.com, ipsec@TIS.COM In-Reply-To: <2.2.32.19960801131747.009ac5f4@mailserv-H.ftp.com> (message from Naganand Doraswamy on Thu, 01 Aug 1996 09:17:47 -0400) Subject: Re: Question on TCP MSS with repsect to IPSEC Reply-To: karn@qualcomm.com Sender: ipsec-approval@neptune.tis.com Precedence: bulk >Doesnt the ICMP message indicate the datagram size (IP Header + data) that >it can send? This being the case, the router or tunnel end point may not >take into account the overhead of IPSEC, correct? Well, that's how Path MTU discovery works -- it relies on the MTU fields in the ICMP messages that bounce back when a packet is too large to fit and the don't-fragment bit is set. When an IPSEC gateway generates such an ICMP message for a destination on the other end of a tunnel, this field should indeed be adjusted to compensate for the IPSEC overhead. That should cause the original sender to adjust its MSS appropriately, just as it would if IPSEC weren't in use. Phil Received: from relay.hq.tis.com by neptune.TIS.COM id aa28751; 4 Aug 96 22:00 EDT Received: by relay.hq.tis.com; id CAA05001; Fri, 2 Aug 1996 02:37:06 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma004986; Fri, 2 Aug 96 02:36:38 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA02817; Fri, 2 Aug 96 02:36:10 EDT Received: by relay.hq.tis.com; id CAA04982; Fri, 2 Aug 1996 02:36:36 -0400 Received: from necom830.hpcl.titech.ac.jp(131.112.32.132) by relay.tis.com via smap (V3.1.1) id xma004973; Fri, 2 Aug 96 02:36:25 -0400 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Message-Id: <199608020638.PAA12221@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id PAA12221; Fri, 2 Aug 1996 15:38:16 +0900 Subject: Re: DNS? was Re: Key Management, anyone? To: Hilarie Orman <ho@earth.hpc.org> Date: Fri, 2 Aug 96 15:38:15 JST Cc: PALAMBER@us.oracle.com, ipsec@TIS.COM In-Reply-To: <199608010915.FAA21838@earth.hpc.org>; from "Hilarie Orman" at Aug 1, 96 5:15 am X-Mailer: ELM [version 2.3 PL11] Sender: ipsec-approval@neptune.tis.com Precedence: bulk > I agree with the individual points, but I'm not convinced by the conclusion. > Why isn't DNSSEC the appropriate minimal common basis for authentication? Authentication for what? > I believe we need such a basis, Why? I think we don't need DNS-structured authentication chain as a basis. Masataka Ohta Received: from relay.hq.tis.com by neptune.TIS.COM id aa09084; 5 Aug 96 11:45 EDT Received: by relay.hq.tis.com; id LAA23220; Mon, 5 Aug 1996 11:48:30 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma023196; Mon, 5 Aug 96 11:48:06 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA20376; Mon, 5 Aug 96 11:47:32 EDT Received: by relay.hq.tis.com; id LAA23183; Mon, 5 Aug 1996 11:47:59 -0400 Received: from ietf.org(132.151.1.19) by relay.tis.com via smap (V3.1.1) id xmaa23152; Mon, 5 Aug 96 11:47:31 -0400 Received: from localhost by ietf.org id aa01672; 5 Aug 96 11:12 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: ipsec@TIS.COM From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-skip-udh-01.txt Date: Mon, 05 Aug 1996 11:12:50 -0400 Message-Id: <9608051112.aa01672@ietf.org> Sender: ipsec-approval@neptune.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Encoding of an Unsigned Diffie-Hellman Public Value Author(s) : A. Aziz, T. Markson, H. Prafullchandra Filename : draft-ietf-ipsec-skip-udh-01.txt Pages : 6 Date : 08/02/1996 It is useful to be able to communicate public keys in the absence of a certificate hierarchy and a signature infrastructure. This document describes a method by which certificates which communicate Diffie-Hellman public values and parameters may be encoded and securely named. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-skip-udh-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-udh-01.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 (193.205.245.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-ietf-ipsec-skip-udh-01.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@ietf.org 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: <19960805101155.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-skip-udh-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-skip-udh-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960805101155.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from relay.hq.tis.com by neptune.TIS.COM id aa09396; 5 Aug 96 12:00 EDT Received: by relay.hq.tis.com; id MAA23806; Mon, 5 Aug 1996 12:02:59 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma023793; Mon, 5 Aug 96 12:02:31 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA21161; Mon, 5 Aug 96 12:02:02 EDT Received: by relay.hq.tis.com; id MAA23786; Mon, 5 Aug 1996 12:02:29 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1) id xma023780; Mon, 5 Aug 96 12:02:13 -0400 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id JAA07645; Mon, 5 Aug 1996 09:04:32 -0700 Received: by mailsun2.us.oracle.com (SMI-8.6/37.8) id JAA05453; Mon, 5 Aug 1996 09:07:58 -0700 Message-Id: <199608051607.JAA05453@mailsun2.us.oracle.com> Date: 05 Aug 96 08:52:03 -0700 From: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com> To: ho@earth.hpc.org Subject: Re: DNS? was Re: Key Management, anyone? Cc: ipsec@TIS.COM X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-approval@neptune.hq.tis.com's message of 01-Aug-96 05:15 Mime-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.0.2.0.35) Content-Type: multipart/mixed; boundary="=_ORCL_6295698_0_11919608051008590" Sender: ipsec-approval@neptune.tis.com Precedence: bulk --=_ORCL_6295698_0_11919608051008590 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" Hilarie, >TCP requires IP, so the IETF guidelines cannot be >taken too seriously in the regard to banning protocol dependencies! Yes, they are only loose recommendations, and I believe (not having the exact RFC in front of me) that the intent was to minimise the interaction between major subsystems and not specific protocols. >Why isn't DNSSEC the appropriate minimal common basis for authentication? This seems to be a strong direction of recent mailing list discussion... DNSSEC is one way to format and distribute certificates. It also implies a specific trust model and naming based on DNS. An IPsec specification should provide recommendations for the minimum required certificate format for IPsec authentication. For ISAKMP, I do not see why certificate distribution is required. Peer systems can readily exchange all required certificates directly, so a certificate distribution system like DNS may not be required. Paul -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com !!! Still hiring, send resumes to: palamber@us.oracle.com !!! -------------------------------------------------------------- --=_ORCL_6295698_0_11919608051008590 Content-Type:message/rfc822 Date: 01 Aug 96 05:15:04 From:"Hilarie Orman " <ipsec-approval@neptune.hq.tis.com> To:PALAMBER@us.oracle.com Subject:Re: DNS? was Re: Key Management, anyone? Cc:ipsec@tis.com X-Orcl-Application:In-Reply-To: Yourmessage <9607312301.AA16100@maildig1.us.oracle.com> X-Orcl-Application:Sender: ipsec-approval@neptune.hq.tis.com X-Orcl-Application:Precedence: bulk MIME-Version: 1.0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" I agree with the individual points, but I'm not convinced by the conclusion. Why isn't DNSSEC the appropriate minimal common basis for authentication? I believe we need such a basis, and DNSSEC seems to be the obvious choice. This wouldn't rule out the optional use of other methods. TCP requires IP, so the IETF guidelines cannot be taken too seriously in the regard to banning protocol dependencies! --=_ORCL_6295698_0_11919608051008590-- Received: from relay.hq.tis.com by neptune.TIS.COM id aa09943; 5 Aug 96 12:21 EDT Received: by relay.hq.tis.com; id MAA24133; Mon, 5 Aug 1996 12:23:59 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma024128; Mon, 5 Aug 96 12:23:32 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA21951; Mon, 5 Aug 96 12:23:03 EDT Received: by relay.hq.tis.com; id MAA24118; Mon, 5 Aug 1996 12:23:30 -0400 Received: from ietf.org(132.151.1.19) by relay.tis.com via smap (V3.1.1) id xma024110; Mon, 5 Aug 96 12:23:14 -0400 Received: from localhost by ietf.org id aa03714; 5 Aug 96 11:49 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: ipsec@TIS.COM From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-skip-udh-01.txt Date: Mon, 05 Aug 1996 11:49:28 -0400 Message-Id: <9608051149.aa03714@ietf.org> Sender: ipsec-approval@neptune.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Encoding of an Unsigned Diffie-Hellman Public Value Author(s) : A. Aziz, T. Markson, H. Prafullchandra Filename : draft-ietf-ipsec-skip-udh-01.txt Pages : 6 Date : 08/02/1996 It is useful to be able to communicate public keys in the absence of a certificate hierarchy and a signature infrastructure. This document describes a method by which certificates which communicate Diffie-Hellman public values and parameters may be encoded and securely named. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-skip-udh-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-udh-01.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 (193.205.245.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-ietf-ipsec-skip-udh-01.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@ietf.org 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: <19960802103034.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-skip-udh-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-skip-udh-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960802103034.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from relay.hq.tis.com by neptune.TIS.COM id aa17746; 5 Aug 96 19:37 EDT Received: by relay.hq.tis.com; id TAA05226; Mon, 5 Aug 1996 19:40:17 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma005222; Mon, 5 Aug 96 19:39:48 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA00863; Mon, 5 Aug 96 19:39:19 EDT Received: by relay.hq.tis.com; id TAA05217; Mon, 5 Aug 1996 19:39:47 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1) id xma005213; Mon, 5 Aug 96 19:39:33 -0400 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id QAA20547; Mon, 5 Aug 1996 16:41:57 -0700 Received: by mailsun2.us.oracle.com (SMI-8.6/37.8) id QAA16081; Mon, 5 Aug 1996 16:45:32 -0700 Message-Id: <199608052345.QAA16081@mailsun2.us.oracle.com> Date: 05 Aug 96 16:34:53 -0700 From: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com> To: ipsec@TIS.COM Subject: IPsec Minutes from Montreal Mime-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.0.2.0.35) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Sender: ipsec-approval@neptune.tis.com Precedence: bulk The minutes of the last IPsec Working Group were posted to the IETF weeks ago and have yet to appear in the official archive. For those of you that missed attending the meeting in Montreal the minutes are attached below. Regards, Paul -------------------------------------------------------------- IPSEC WG Meeting Notes, Montreal IETF, June 1996 The co-chairs would like to thank Steve Kent for contributing his personal notes on the meeting, which were used as the basis for these minutes. The co-chairs edited the notes somewhat, so any errors are their responsibility. SESSION 1, Tuesday: AH/ESP and existing IPsec documents Jim Hughes presented his Combined ESP transform with HMAC and anti-replay. Steve Kent suggested changing the proposal to rely on a negotiated anti-replay window size, to accept all packets within the window unless they are replays, and to not try to reduce the overhead by relying on a constructed IV. All three suggestions were adopted. Note that this protocol requires distinct simplex channel keys, derived from a master key for the SA. RSA reported on their S/WAN interoperability testing: TIS, NSA, Raptor, SCC, and others worked well together. The next test session will require Oakley/ISAKMP, and optionally SKIP, for key management, in support of AH and ESP. John Gilmore argued for widespread, near term deployment to protect against passive wiretapping. His goal is 5% of Internet traffic by the end of 1996. His personal agenda is to counter government (not just US Government) efforts for key-escrow initiatives. His proposal is to put crypto-walls in place (devices that don't even do packet filtering and don't rely on authenticated keys). His tactic is to leverage freely available software in order to build such crypto-walls, define new DNS records for unauthenticated key storage, avoid export controls by developing software outside of the US. A firewall vendor gave a talk on using IPSEC with firewalls, as a followup to mobile IP problem of getting mobile IP traffic out of a foreign domain. Asssume a model where presence of valid AH is required for firewall traversal, in either direction. The initially presented model looks at traversing a single firewall, nominally at the home agent permieter. The second model presented shows foreign and home firewalls. The talk points out the need for multiple, layered SAs, from MN-to-firewall-1, then maybe between firewalls, then from HA to firewall-2, and eventually one SA above these to carry forwarded traffic from HA to MN. Speaker notes the problems of being able to transmit the mobile IP messages, ICMP messages, and key management messages through firewalls as a precursor to establishing SAs in this complex environment. The bottom line is that one has to look carefully at the rules that firewalls employ to determine what traffic will be allowed across, as this might cause serious problems for SA establishment, especially for mobile IP case. However, the proposed solution is pretty complex and there are easier approaches to dealing with this problem in the mobile IP case, e.g., co-locating FAs and HAs with firewalls, or establishing long term SAs, between HAs and FAs and their local firewalls, to facilitate forwarding of mobile IP traffic. Ran Atkinson spoke about the standards process and it's applicability to the IPSEC RFCs. Because some of the 1825-29 RFCs are being replaced, and because all of them cross reference one another, the group cannot be advanced from Proposed Standard to Draft Standard until 6 months elapses after the last of the inter-related documents have been updated. Ran also discussed his revised IPSEC Security Architecture document, a replacement for RFC-1825. Steve Kent suggested that the WG revisit AH to remove its two-different modes of use, given the new ESP options that incorporate autehntication and thus obviate the need for the embedded AH mode (ESP followed directly by AH). Steve also suggested that the WG revise ESP to add in optional, variable length fields for IVs, integrity checks, etc. so that the transform documents are independent of one another and don't grow geometrically as new algorithms are added. The WG adopted both suggestions and Steve Kent agreed to work with the WG co-chairs to provide suitable text for the revised RFCs. Session 2, Wednesday: Key Management Issues Bob Moskowitz (Chrysler) challenged the group to solve a network layer security problem for communication among automotive parts suppliers and manufacturers, but with a lot of nasty residual problems, e.g., misuse of net numbers by particiants, diverse set of existing firewalls, etc. Bob's goal is to start deploying IPsec by the end of 1996. Ashar Aziz presented SKIP. Note the use of the SKIP header between IP header and AH or ESP. Two modes of use: the first mode has no setup messages once the master keys are in place, no Perfect Forward Secrecy, and has significant per-message overhead. This mode relies on pre-positioned D-H master keys from which unicast keys are derived. The second mode uses ephemeral Diffie-Hellman, with certificates, in a 4-6 message exchange, with approximate PFS, anonymity, etc. Claimed multicast mode support is based on a group co-ordinator creating a group key (distribution of the private key to group members is not described here and is potentially hard to implement or scale) which the sender uses as the target for Diffie-Hellman computation. Checkpoint, Toshiba, ETH, Sun have interoperable implementations of SKIP, based on recent testing. Some gaps in the SKIP-06 spec were uncovered, and are being fixed in the next draft. Ashar pushed for adoption of the certificate discovery protocol (CDP) independent of SKIP. Also can move CRLs as well as certificates, not just X.509 certificates, but PGP too. Doug Maughan reported on ISAKMP. Free software is available via MIT server at http://web.mit.edu/network/isakmp. cisco has also worked on an ISAKMP with Oakley implementation, also freely available from cisco and MIT web sites. There is also an implementation by the UK Defence Research Agency. ISAKMP provides very general KMP framework, capable of supporting various key exchange algorithms, authentication, security association management, and denial of service protection. Recent I-D changes: moved from request/response to chained payload format (for better performance and/or more flexible for multi-exchange protocols), can negotiate multiple SPIs at the same time (for greater efficiency and flexibility), and an expanded set of authentication payload types (for better support of more exchnage types). Format is more complex now, because of support of multiple paylodas per message, negotiating multiple protocols at one time, etc. See version 5 specification I-D for details. Jon Millen's analysis notes that cookies don't buy much Denial-of-Service protection, and that authentication and key exchange is sufficiently decoupled to require further analysis. Interoperability testing, using Oakley, is now going on between cisco and DRA. Work will continue to add other key exchange algorithms, commercial and government. Hilarie Orman described Oakley briefly. Oakley is quite flexible: can use Diffie-Hellman exchange and/or pre-positioned keys or Public Key (RSA) encryption ; authentication via RSA encryption, signatures or predistributed shared secrets; integrity is available but can be omitted, and Perfect Forward Secrecy is available but can be omitted. Minimal message exchange is 3 messages, though more round-trips can also occur. She has also published the group paramaters for several bases, yielding 90-bit strength key outputs. ISAKMP integration is almost complete. She suggested having the ESP and AH transforms define how the necessary key bits are extracted from the output of the Oakley computation. Basically, a general collection of modules that can meet lots of different requirements, using a consistent syntax. Dan Harkins reported on the status of the ISAKMP-Oakley integration effort. A new Internet-Draft is out with a coherent profile of ISAKMP and Oakley when used together. The first two ISAKMP messages establish an SA, then the parties negotiate SAs for their clients. Four modes of Oakley are specified: Main Mode (for ISAKMP phase 1 exchange, four messages); Agressive Mode (quick, but no identity protection, an alternate phase 1 exchange in 3 messages); Quick Mode ( a phase 2 exchange, in 3 messages, but can be repeated multiple times after a phase 1 exchange); Group Mode (for changing from one group to another, over time). cisco's free ISAKMP+Oakley code will be implementing this specification. Hugo made some comments on Oakley/ISAKMP. He likes the overall framework, but sees a need to refine the specs to remove some ambiguity and facilitate interoperability. From a cryptographic standpoint he has some suggestions, but lacked time to go into details. From a capability perspective, he would like to see a support for pre-positioned or centrally-distributed symetric keys, with PFS, which Oakley does allow. cisco has indicated that they would accommodate that request. Hugo doesn't like the reliance on Diffie-Hellman in the new Oakley/ISAKMP profile, relative to the broader capabilities of Oakley. Finally, Hugo expressed some concerns about the differences in types of attacks one might mount in the public key vs. symmetric key arena. The bottom line is that the ISAKMP and Oakley protocols accommodate all of these suggestions, it's just an issue of of getting the cisco implementation to incorporate these features. Very brief, surprizing comments from John Gilmore, announcing that he has purchased all of Bill Simpson's rights, including copyright, for Photuris, to ensure that it is considered as a viable contender in the key management protocol sweepstakes. However, he has not obtained any rights to Photuris from Phil Karn. Further, there is no new draft available addressing the previously discussed deficiencies of Photuris. There was no evidence of broad support for Photuris at this meeting. There was a short talk on Eliptical Curve Cryptography (ECC) technology, for both Diffie-Hellman exchanges and DSA- & RSA-equivalent (signature with recovery, but not excatly RSA) signautues. A major benefit is that shorter key lengths are security equivalent to larger key lengths. The IEEE P1363 specifications were mentioned and there was some discussion of patents relative to the use of ECC. There are some ECC-related patents, in addition to the general public key patent, but they relate mostly to implementations not to the basic math. The speaker is from Certicom, which holds some of these implementation patents. Closing discussions were process oriented, i.e., how will the WG decide what will become the default key management standard for IPSEC ? Jeff Schiller conducted straw polls which showed significant differences of opinion between Oakley/ISAKMP and SKIP, although everyone wants a quick resolution to the issue! Jeff suggests having a special committee come back with a justifiable resolution. -- Received: from relay.hq.tis.com by neptune.TIS.COM id aa23005; 6 Aug 96 2:51 EDT Received: by relay.hq.tis.com; id CAA08072; Tue, 6 Aug 1996 02:54:17 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma008070; Tue, 6 Aug 96 02:53:49 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA06185; Tue, 6 Aug 96 02:53:19 EDT Received: by relay.hq.tis.com; id CAA08065; Tue, 6 Aug 1996 02:53:48 -0400 Received: from toad.com(140.174.2.1) by relay.tis.com via smap (V3.1.1) id xma008060; Tue, 6 Aug 96 02:53:22 -0400 Received: from localhost (localhost [127.0.0.1]) by toad.com (8.7.5/8.7.3) with SMTP id XAA10933; Mon, 5 Aug 1996 23:55:26 -0700 (PDT) Message-Id: <199608060655.XAA10933@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com> Cc: ipsec@TIS.COM, gnu@toad.com Subject: Re: IPsec Minutes from Montreal In-Reply-To: <199608052345.QAA16081@mailsun2.us.oracle.com> Date: Mon, 05 Aug 1996 23:55:26 -0700 From: John Gilmore <gnu@toad.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk Some minutes additions from my own notes: Details on my presentation on rapid deployment of IPSEC in the first meeting are available at http://www.cygnus.com/~gnu/swan.html. Jeff Schiller's closing discussions in the second meeting included these "straw poll" questions, with my rough estimations of the audience reaction. He said he deliberately structured the questions to avoid a straw-poll on particular algorithms, but instead focused on our goals or process. Should we let the marketplace decide on a key managment standard, or should we pick one and move forward? Marketplace - 2/5 Pick one - 3/5 Should we favor generality, or simplicity? Generality - 2/5 Simplicity - 3/5 Do we have to have a plan by the next IETF? On this we have consensus -- YES. Should Jeff grab a few of the WG people who are known not to be committed to any proposal, and together decide? Strong consensus that this was not the way to go. This was when he suggested convening a small group, largely composed of the authors/proponents of existing proposals, to try to hammer out a compromise proposal. He also said that if this group didn't come up with anything by September, Jeff would personally choose one as the standard, though he did not want to be forced to do that. John Received: from relay.hq.tis.com by neptune.TIS.COM id aa28811; 6 Aug 96 9:50 EDT Received: by relay.hq.tis.com; id JAA12444; Tue, 6 Aug 1996 09:53:18 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma012438; Tue, 6 Aug 96 09:52:50 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA15998; Tue, 6 Aug 96 09:52:19 EDT Received: by relay.hq.tis.com; id JAA12432; Tue, 6 Aug 1996 09:52:48 -0400 Received: from ns.newbridge.com(192.75.23.67) by relay.tis.com via smap (V3.1.1) id xma012426; Tue, 6 Aug 96 09:52:20 -0400 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id JAA10154; Tue, 6 Aug 1996 09:54:09 -0400 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma010062; Tue Aug 6 09:53:36 1996 Received: from tsntsrv1.timestep.com (tsntsrv1.timestep.com [192.168.219.190]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with ESMTP id JAA22084; Tue, 6 Aug 1996 09:53:35 -0400 Received: from Microsoft Mail (PU Serial #1121) by tsntsrv1.timestep.com (PostalUnion/SMTP(tm) v2.1.8d for Windows NT(tm)) id AA-1996Aug06.094718.1121.40243; Tue, 06 Aug 1996 09:52:55 -0400 From: Roy Pereira <rpereira@timestep.com> To: "Brian W. McKenney" <mckenney@smiley.mitre.org>, "'IPSEC@TIS.COM'" <IPSEC@TIS.COM> Message-Id: <1996Aug06.094718.1121.40243@tsntsrv1.timestep.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Organization: TimeStep Corporation Date: Tue, 06 Aug 1996 09:52:55 -0400 Subject: RE: ESP RC5-CBC Transform Sender: ipsec-approval@neptune.tis.com Precedence: bulk >The recent S/WAN interoperability tests were focused on DES-CBC for ESP. >Will future tests include RC5-CBC for ESP? I am interested in >vendor/product support for this transform. >The future standard that is being pushed for ESP is the Combined ESP >transform (identified in latest IETF-DRAFT), although other algorithms and >modes may also be implemented. TimeStep Corp will include the RC5-CBC ESP transform in its next generation PermitPC products. Received: from relay.hq.tis.com by neptune.TIS.COM id aa29171; 6 Aug 96 10:05 EDT Received: by relay.hq.tis.com; id KAA12770; Tue, 6 Aug 1996 10:07:49 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma012760; Tue, 6 Aug 96 10:07:24 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA16871; Tue, 6 Aug 96 10:06:50 EDT Received: by relay.hq.tis.com; id KAA12746; Tue, 6 Aug 1996 10:07:18 -0400 Received: from ietf.org(132.151.1.19) by relay.tis.com via smap (V3.1.1) id xmab12731; Tue, 6 Aug 96 10:07:05 -0400 Received: from localhost by ietf.org id aa04416; 6 Aug 96 9:19 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: ipsec@TIS.COM From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-skip-mc-01.txt Date: Tue, 06 Aug 1996 09:18:59 -0400 Message-Id: <9608060919.aa04416@ietf.org> Sender: ipsec-approval@neptune.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : SKIP Extensions for IP Multicast Author(s) : A. Aziz, T. Markson, H. Prafullchandra Filename : draft-ietf-ipsec-skip-mc-01.txt Pages : 20 Date : 08/05/1996 This document describes extensions to the base SKIP [1] protocol to allow encrypted/authenticated multicast communications. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-skip-mc-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-mc-01.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 (193.205.245.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-ietf-ipsec-skip-mc-01.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@ietf.org 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: <19960805161131.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-skip-mc-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-skip-mc-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960805161131.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from relay.hq.tis.com by neptune.TIS.COM id aa29169; 6 Aug 96 10:05 EDT Received: by relay.hq.tis.com; id KAA12772; Tue, 6 Aug 1996 10:07:48 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma012761; Tue, 6 Aug 96 10:07:26 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA16872; Tue, 6 Aug 96 10:06:52 EDT Received: by relay.hq.tis.com; id KAA12743; Tue, 6 Aug 1996 10:07:18 -0400 Received: from ietf.org(132.151.1.19) by relay.tis.com via smap (V3.1.1) id xma012731; Tue, 6 Aug 96 10:07:05 -0400 Received: from localhost by ietf.org id aa04384; 6 Aug 96 9:18 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: ipsec@TIS.COM From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-skip-x509-01.txt Date: Tue, 06 Aug 1996 09:18:55 -0400 Message-Id: <9608060918.aa04384@ietf.org> Sender: ipsec-approval@neptune.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : X.509 Encoding of Diffie-Hellman Public Values Author(s) : A. Aziz, T. Markson, H. Prafullchandra Filename : draft-ietf-ipsec-skip-x509-01.txt Pages : 6 Date : 08/05/1996 This document describes the ASN.1 [1] encoding of the CCITT 1988 X.509 [2] certificate with Diffie-Hellman public values for use with SKIP [5]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-skip-x509-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-x509-01.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 (193.205.245.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-ietf-ipsec-skip-x509-01.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@ietf.org 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: <19960805155442.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-skip-x509-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-skip-x509-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960805155442.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from relay.hq.tis.com by neptune.TIS.COM id aa29170; 6 Aug 96 10:05 EDT Received: by relay.hq.tis.com; id KAA12773; Tue, 6 Aug 1996 10:07:48 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma012762; Tue, 6 Aug 96 10:07:27 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA16873; Tue, 6 Aug 96 10:06:52 EDT Received: by relay.hq.tis.com; id KAA12748; Tue, 6 Aug 1996 10:07:19 -0400 Received: from ietf.org(132.151.1.19) by relay.tis.com via smap (V3.1.1) id xmac12731; Tue, 6 Aug 96 10:07:06 -0400 Received: from localhost by ietf.org id aa04432; 6 Aug 96 9:19 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: ipsec@TIS.COM From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-skip-pfs-01.txt Date: Tue, 06 Aug 1996 09:19:01 -0400 Message-Id: <9608060919.aa04432@ietf.org> Sender: ipsec-approval@neptune.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : SKIP extension for Perfect Forward Secrecy (PFS) Author(s) : A. Aziz Filename : draft-ietf-ipsec-skip-pfs-01.txt Pages : 11 Date : 08/05/1996 This document describes an optional extension specifying how to use an ephemeral Diffie-Hellman exchange in conjunction with the SKIP protocol in order to provide perfect forward secrecy for situations where forward secrecy is necessary. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-skip-pfs-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-pfs-01.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 (193.205.245.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-ietf-ipsec-skip-pfs-01.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@ietf.org 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: <19960805161609.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-skip-pfs-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-skip-pfs-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960805161609.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from relay.hq.tis.com by neptune.TIS.COM id aa29172; 6 Aug 96 10:05 EDT Received: by relay.hq.tis.com; id KAA12771; Tue, 6 Aug 1996 10:07:48 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma012759; Tue, 6 Aug 96 10:07:23 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA16870; Tue, 6 Aug 96 10:06:50 EDT Received: by relay.hq.tis.com; id KAA12745; Tue, 6 Aug 1996 10:07:18 -0400 Received: from ietf.org(132.151.1.19) by relay.tis.com via smap (V3.1.1) id xmaa12731; Tue, 6 Aug 96 10:07:05 -0400 Received: from localhost by ietf.org id aa04400; 6 Aug 96 9:18 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: ipsec@TIS.COM From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-skip-adp-01.txt Date: Tue, 06 Aug 1996 09:18:57 -0400 Message-Id: <9608060918.aa04400@ietf.org> Sender: ipsec-approval@neptune.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : SKIP Algorithm Discovery Protocol Author(s) : A. Aziz, T. Markson, H. Prafullchandra Filename : draft-ietf-ipsec-skip-adp-01.txt Pages : 7 Date : 08/05/1996 SKIP [1] provides privacy and authentication with Internet Protocols. It does not define a method by which two entities may mutually agree on encryption, authentication and compression algorithms. We describe a protocol which will allow one SKIP entity to inform another entity of the capabilities it supports. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-skip-adp-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-adp-01.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 (193.205.245.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-ietf-ipsec-skip-adp-01.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@ietf.org 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: <19960805160054.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-skip-adp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-skip-adp-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960805160054.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from relay.hq.tis.com by neptune.TIS.COM id aa29311; 7 Aug 96 13:40 EDT Received: by relay.hq.tis.com; id NAA18374; Wed, 7 Aug 1996 13:43:22 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma018372; Wed, 7 Aug 96 13:42:54 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA23587; Wed, 7 Aug 96 13:42:22 EDT Received: by relay.hq.tis.com; id NAA18367; Wed, 7 Aug 1996 13:42:52 -0400 Received: from dg-webo.us.dg.com(128.221.131.1) by relay.tis.com via smap (V3.1.1) id xma018362; Wed, 7 Aug 96 13:42:44 -0400 Received: from wellspring by dg-webo.webo.dg.com (5.4R3.10/dg-webo-v1) id AA23471; Wed, 7 Aug 1996 13:44:35 -0400 Received: from ferguson by wellspring.us.dg.com (5.4R3.10/dg-gens08) id AA20413; Wed, 7 Aug 1996 13:44:34 -0400 Message-Id: <9608071744.AA20413@wellspring.us.dg.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 07 Aug 1996 13:44:11 -0400 To: ipsec@TIS.COM From: Rodney Thayer <rodney@sabletech.com> Subject: I-D ACTION:draft-thayer-seccomp-00.txt Sender: ipsec-approval@neptune.tis.com Precedence: bulk I would like to find out if anyone else has thought about what format would be needed to represent compressed data within an IPSEC datastream. I've written up something (see attached) per suggestions I received at the Montreal IETF. >To: IETF-Announce:; >Sender: ietf-announce-request@ietf.org >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-thayer-seccomp-00.txt >Date: Mon, 22 Jul 1996 10:04:32 -0400 >X-Orig-Sender: cclark@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Compression Payload for Use with IP Security > Author(s) : R. Thayer > Filename : draft-thayer-seccomp-00.txt > Pages : 4 > Date : 07/17/1996 > >This document describes a payload format to be used to store compressed >protocol messages within an IP packet which is using security features as >defined in [RFC-1825]. > >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-thayer-seccomp-00.txt". >A URL for the Internet-Draft is: >ftp://ds.internic.net/internet-drafts/draft-thayer-seccomp-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 (193.205.245.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-thayer-seccomp-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@ietf.org > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version >of the Internet-Draft. >Content-Type: text/plain >Content-ID: <19960717141737.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-thayer-seccomp-00.txt >Content-Type: text/plain >Content-ID: <19960717141737.I-D@ietf.org> > Rodney Thayer <rodney@sabletech.com> +1 617 332 7292 Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA Fax: +1 617 332 7970 http://www.shore.net/~sable "Developers of communications software" Received: from relay.hq.tis.com by neptune.TIS.COM id aa01197; 7 Aug 96 14:57 EDT Received: by relay.hq.tis.com; id OAA20821; Wed, 7 Aug 1996 14:59:52 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma020812; Wed, 7 Aug 96 14:59:24 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA27813; Wed, 7 Aug 96 14:58:52 EDT Received: by relay.hq.tis.com; id OAA20807; Wed, 7 Aug 1996 14:59:22 -0400 Received: from ietf.org(132.151.1.19) by relay.tis.com via smap (V3.1.1) id xma020791; Wed, 7 Aug 96 14:59:08 -0400 Received: from localhost by ietf.org id aa19436; 7 Aug 96 14:58 EDT To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: ipsec@TIS.COM From: The IESG <iesg-secretary@ietf.org> Subject: Last Call: HMAC-IP Authentication with Replay Prevention to Proposed Standard Reply-To: iesg@ietf.org Date: Wed, 07 Aug 1996 14:58:16 -0400 Message-Id: <9608071458.aa19436@ietf.org> Sender: ipsec-approval@neptune.tis.com Precedence: bulk The IESG has received a request from the IP Security Protocol Working Group to consider the following Internet-Drafts for Proposed Standard: 1. HMAC-MD5 IP Authentication with Replay Prevention <draft-ietf-ipsec-ah-hmac-md5-01.txt> 2. HMAC-SHA IP Authentication with Replay Prevention <draft-ietf-ipsec-ah-hmac-sha-01.txt> The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by August 20, 1996. Received: from relay.hq.tis.com by neptune.TIS.COM id aa11398; 7 Aug 96 22:56 EDT Received: by relay.hq.tis.com; id WAA01430; Wed, 7 Aug 1996 22:59:44 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma001428; Wed, 7 Aug 96 22:59:25 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA14077; Wed, 7 Aug 96 22:58:44 EDT Received: by relay.hq.tis.com; id WAA01422; Wed, 7 Aug 1996 22:59:14 -0400 Received: from copernicus.hpc.org(192.187.8.4) by relay.tis.com via smap (V3.1.1) id xma001419; Wed, 7 Aug 96 22:59:09 -0400 Received: from earth.hpc.org (earth.hpc.org [192.187.8.34]) by hpc.org (8.7.1/8.7.1) with SMTP id XAA15627; Wed, 7 Aug 1996 23:04:33 -0400 (EDT) Received: by earth.hpc.org (SMI-8.6/SMI-SVR4) id XAA02552; Wed, 7 Aug 1996 23:03:02 -0400 Date: Wed, 7 Aug 1996 23:03:02 -0400 From: Hilarie Orman <ho@earth.hpc.org> Message-Id: <199608080303.XAA02552@earth.hpc.org> To: mohta@necom830.hpcl.titech.ac.jp MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Cc: ipsec@TIS.COM In-Reply-To: Yourmessage <199608050227.TAA06242@baskerville.CS.Arizona.EDU> Subject: Re: "Re: DNS? was Re: Key Management, anyone?" Sender: ipsec-approval@neptune.tis.com Precedence: bulk > Authentication for what? Clarified Assertion: The minimal basis for authentication is the association of a public key with an IP address. The minimal authentication chain is through DNS zone authorities. This seems to me to be generally useful and meaningful mechanism for most Internet purposes. If a site doesn't have an appropriate key entry, it won't be able participate in ordinary authenticated services --- sort of like not having a valid IP address would invalidate it as an Internet member. So, why is this wrong? Received: from relay.hq.tis.com by neptune.TIS.COM id aa11701; 7 Aug 96 23:20 EDT Received: by relay.hq.tis.com; id XAA01674; Wed, 7 Aug 1996 23:22:44 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma001669; Wed, 7 Aug 96 23:22:16 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA14575; Wed, 7 Aug 96 23:21:45 EDT Received: by relay.hq.tis.com; id XAA01663; Wed, 7 Aug 1996 23:22:14 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1) id xma001658; Wed, 7 Aug 96 23:21:49 -0400 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id UAA00041; Wed, 7 Aug 1996 20:24:11 -0700 Received: by mailsun2.us.oracle.com (SMI-8.6/37.8) id UAA29223; Wed, 7 Aug 1996 20:27:47 -0700 Message-Id: <199608080327.UAA29223@mailsun2.us.oracle.com> Date: 07 Aug 96 19:52:51 -0700 From: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com> To: mcr@milkyway.com Subject: Re: IPsec Minutes from Montreal Cc: ipsec@TIS.COM X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:mcr@milkyway.com's message of 06-Aug-96 10:30 Mime-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.0.2.0.35) Content-Type: multipart/mixed; boundary="=_ORCL_6371449_0_11919608072128460" Sender: ipsec-approval@neptune.tis.com Precedence: bulk --=_ORCL_6371449_0_11919608072128460 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" >(I think everyone will agree that we have endless >debates about what layering is allowed!) It seems like any layering should be allowed. A harder question is determining if there should be a mandate for minimum support of layering required in a conformant IPsec implementation. For now it seems premature to mandate support for specific layering configuration, but it would be useful to document some common useful configurations. Paul -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com !!! Hiring, send resumes to: palamber@us.oracle.com !!! -------------------------------------------------------------- --=_ORCL_6371449_0_11919608072128460 Content-Type:message/rfc822 Date: 06 Aug 96 10:30:16 From:"Michael Richardson " <mcr@milkyway.com> To:PALAMBER@us.oracle.com Subject:Re: IPsec Minutes from Montreal X-Mailer: exmh version 1.6.7 5/3/96 X-Orcl-Application:Pgp-Action: none; rfc822=off X-Face: x7OynEM*dB$e.2'7pigelLk>5:Nu:%r*iV96{F2XIT.apbrc-vOFSi{yI$3=nJ-Qi)allj4 X-Face: =)4cWlX@IQ1Dsmk}T4qX~{XI5Z01>PV^cYR'~cL]&ma<{rYg~Ao-:~:sM%z}^M65`;1TZ}Tze"4/=F X-Face: ~o&8;"SKHwB?%"xpP/=pkhdZVP$rQQ{"{QT`#kcx7!\/y+crQa4^nLEms6_k4O*o#fo[WBs~~&.%jf X-Face: |;W@E2K#{U~%vhvth^uDLWD`<OLQ;48T].laq_}3abY7nO5 X-Uri: http://www.milkyway.com/People/Michael_Richardson/Bio.html X-Orcl-Application:References: <199608052345.QAA16081@mailsun2.us.oracle.com> X-Orcl-Application:In-Reply-To: Your message of "05 Aug 1996 16:34:53 PDT." X-Orcl-Application:In-Reply-To: <199608052345.QAA16081@mailsun2.us.oracle.com> X-Orcl-Application:Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" In a galaxy far, far away, : 05 Aug 1996 16:34:53 PDT > A firewall vendor gave a talk on using IPSEC with firewalls, as a > followup to mobile IP problem of getting mobile IP traffic out of a foreign > domain. Asssume a model where presence of valid AH is required for firewall > traversal, in either direction. The initially presented model looks at > traversing a single firewall, nominally at the home agent permieter. The > second model presented shows foreign and home firewalls. The talk points out >- > the need for multiple, layered SAs, from MN-to-firewall-1, then maybe between >- > firewalls, then from HA to firewall-2, and eventually one SA above these to > carry forwarded traffic from HA to MN. Speaker notes the problems of being > able to transmit the mobile IP messages, ICMP messages, and key management > messages through firewalls as a precursor to establishing SAs in this complex >- > environment. The bottom line is that one has to look carefully at the rules > that firewalls employ to determine what traffic will be allowed across, as Up to this point, I agree with the minutes. > this might cause serious problems for SA establishment, especially for mobile >- > IP case. However, the proposed solution is pretty complex and there are My perspective is that mobile IP is simply the tip of the iceberg. A good part of the IPsec architecture makes space for security gateways and the like. (I think everyone will agree that we have endless debates about what layering is allowed!) > easier approaches to dealing with this problem in the mobile IP case, e.g., > co-locating FAs and HAs with firewalls, or establishing long term SAs, betwee >-n > HAs and FAs and their local firewalls, to facilitate forwarding of mobile IP > traffic. This doesn't solve the general problem. Does this general problem really exist? Yes: I should point out that Bob Moskowitz's problem is very highly related. (This might not be clear to some, but remember that I build application layer firewalls. I fear to be too partisan if I were to describe how I'd use IPsec+application layer firewalls to solve his problems. Besides, I haven't seen his requirements document yet... Bob?) -- mcr@milkyway.com | <A HREF="http://www.milkyway.com/">Milkyway Networks Corporation</A> Michael C. Richardson | Makers of the Black Hole firewall Senior Research Specialist | info@milkyway.com for BlackHole questions Home: <A HREF="http://www.sandelman.ocunix.on.ca/People/Michael_Richardson/Bio .html">mcr@sandelman.ocunix.on.ca</A>. "In a razor of Love." "Voodoo People! Magic People! Voodoo People! Magic People!" --=_ORCL_6371449_0_11919608072128460-- Received: from relay.hq.tis.com by neptune.TIS.COM id aa13024; 8 Aug 96 1:06 EDT Received: by relay.hq.tis.com; id BAA02410; Thu, 8 Aug 1996 01:09:14 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma002408; Thu, 8 Aug 96 01:08:46 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA16477; Thu, 8 Aug 96 01:08:14 EDT Received: by relay.hq.tis.com; id BAA02405; Thu, 8 Aug 1996 01:08:44 -0400 Received: from necom830.hpcl.titech.ac.jp(131.112.32.132) by relay.tis.com via smap (V3.1.1) id xma002403; Thu, 8 Aug 96 01:08:40 -0400 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Message-Id: <199608080510.OAA10224@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id OAA10224; Thu, 8 Aug 1996 14:10:35 +0900 Subject: Re: "Re: DNS? was Re: Key Management, anyone?" To: Hilarie Orman <ho@earth.hpc.org> Date: Thu, 8 Aug 96 14:10:34 JST Cc: mohta@necom830.hpcl.titech.ac.jp, ipsec@TIS.COM In-Reply-To: <199608080303.XAA02552@earth.hpc.org>; from "Hilarie Orman" at Aug 7, 96 11:03 pm X-Mailer: ELM [version 2.3 PL11] Sender: ipsec-approval@neptune.tis.com Precedence: bulk > > Authentication for what? > > Clarified Assertion: > The minimal basis for authentication is the association of a public key > with an IP address. Agreed, though the association of a public key with a hostname would be a little more useful. But, note that any string, for example, URLs, containing a hostname, signature, date etc. can authenticate a hostname. > The minimal authentication chain is through DNS > zone authorities. I disagree here. The source, root, of the authentication varies application by application. DNS zone delegation chain is the natural chain for Internic to ^^^^^^^^^^^^ authenticate DNS data structure itself, but nothing more than that. Secure DNS chain is NOT useful to track to an authentication root. To track to the proper root, we need application specific signatures. For example, it is possible to modify SIG RRs and KEY RRs of secure DNS to have some field designating the authentication root. Then, using multiple SIG and KEY RRs for each root, we can track the appropriate chain to reach the desired root of the authentication. This, I think, could be the minimal authentication chain with DNS. But, now, we are not so much motivated to let the authentication chain follow the DNS structure. Authetication chain can just be a relationship between DNS nodes. Note that traversing DNS structure with NS, glue A and CNAME cause a lot of wierd problems unrelated to the authentication chain itself. Finally, the problem of using DNS for such generic authentication is that, we need separate SIG RR and KEY RR for each root, which can easily cause DNS UDP packet overflow. So, I'm rather discouraged to use DNS for authentication other than securing DNS structure itself. Masataka Ohta Received: from relay.hq.tis.com by neptune.TIS.COM id aa22288; 8 Aug 96 10:19 EDT Received: by relay.hq.tis.com; id KAA10336; Thu, 8 Aug 1996 10:22:26 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma010328; Thu, 8 Aug 96 10:22:00 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA01441; Thu, 8 Aug 96 10:21:28 EDT Received: by relay.hq.tis.com; id KAA10321; Thu, 8 Aug 1996 10:21:57 -0400 Received: from zafu.bbn.com(128.89.0.25) by relay.tis.com via smap (V3.1.1) id xma010314; Thu, 8 Aug 96 10:21:52 -0400 Received: from [128.89.0.110] (COMSEC.BBN.COM [128.89.0.110]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id KAA26053; Thu, 8 Aug 1996 10:28:43 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: <v02130506ae2fa443cfc6@[128.89.0.110]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 8 Aug 1996 10:24:53 -0400 To: Hilarie Orman <ho@earth.hpc.org> From: Stephen Kent <kent@bbn.com> Subject: Re: "Re: DNS? was Re: Key Management, anyone?" Cc: mohta@necom830.hpcl.titech.ac.jp, ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Hilarie, I think there have been two threads of authentication discussion, both of which have merit. As Steve Bellovin pointed out, if one starts with a DNS name, then one wants the binding between the name and the corresponding IP address to be authenticated, or you are in trouble. However, although most of the security association (SA) establishment procedures take that path, some might proceed directly from an address. Hence, an authenticated binding between an IP address and a public key also is necessary, and sometime sufficient. Th DNS security mechanism facilities provide a necessary service whenever one starts with a DNS name as an input to SA creation, especially if one is not sure about the existance of key material for the target, or the target's existance. If you know that the target exists, and has key material, then one could do without the DNS security facilities and merely fetch a certificate from the DNS (or elsewhere). That certificate could embody the address/key binding, and it might also include the DNS name. (X.509 v3 certificates allow for multiple alternative name forms in a single certificate, so it is feasible to include multiple bindings, so long as one can establish a certification system that is consistent with the multiple bindings.) So, I also agree with the observations made by David Kemp, that the DNS security approach to providing key and signature records is not the only game in town. Some subscribers may find that they require some of the features that come from using certificates (vs. the signature and key records of DNSSEC). The two schemes are not necessarily in conflcit; they offer somewhat different sets of services. One might even go with a hybrid scheme where DNSSEC was used to authenticate existing records for hosts, but certificates were stored for the hosts themselves. This would reduce the extent to which DNS signature and key records would be introduced, since they would be required only to represent the domains (not the hosts), while certificates could be used for the hosts. (Just a quick thought, noithing that I've worked on in depth.) Steve Received: from relay.hq.tis.com by neptune.TIS.COM id aa23052; 8 Aug 96 10:47 EDT Received: by relay.hq.tis.com; id KAA11342; Thu, 8 Aug 1996 10:50:27 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma011314; Thu, 8 Aug 96 10:50:00 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA03377; Thu, 8 Aug 96 10:49:27 EDT Received: by relay.hq.tis.com; id KAA11302; Thu, 8 Aug 1996 10:49:57 -0400 Received: from ftp.com(128.127.2.122) by relay.tis.com via smap (V3.1.1) id xma011295; Thu, 8 Aug 96 10:49:55 -0400 Received: from ftp.com by ftp.com ; Thu, 8 Aug 1996 10:52:18 -0400 Received: from athena.ftp.com by ftp.com ; Thu, 8 Aug 1996 10:52:18 -0400 Message-Id: <2.2.32.19960808145715.00b4d320@mailserv-H.ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 08 Aug 1996 10:57:15 -0400 To: ipsec@TIS.COM From: Naganand Doraswamy <naganand@ftp.com> Subject: Comments on ISAKMP/Oakley Sender: ipsec-approval@neptune.tis.com Precedence: bulk These are mostly implemetation type comments: 2.4.1. Security Association Payload Is the "Payload Length" field *really* supposed to be specified in four-octet units, or should it be in octets as all the other payloads are? A.6.1. Attribute Value Assigned Numbers, IPSEC ESP TLV constructs: how long is "Type"? How long is "Length"? Is "Length" in terms of octets, or some other unit? Are the lengths of "Type" and "Length" included in "Length" or not? Where is "Multiple Precision Integer" specified? A.7.1 The basic proposal format does has the following fields defined in the header: - Proposal #, Proposal Len, Protocol # and Attribute TLV's However, the ESP, AH, and ISAKMP proposals have defined the Transforms ID's and a reserved field. Shouldnt the basic proposal format take care of this as well? A.7.4. Proposal Formats, ISAKMP: ??? A.8.1. Security Association Payload Format Does the Situation field length need to be an integral multiple of four octets, as the Proposal field needs to be? Is the Situation Length field (Figure 20) specified as octets, four-octet units, or ... ? draft-ietf-ipsec-isakmp-oakley-00.txt Where are ISAKMP exchange numbers defined for the various Oakley modes? What happens to the Base, Identity Protection, and Authentication Only exchanges defined in the ISAKMP draft? How does one implemement the other exchanges (which are defined as MUSTs in the ISAKMP draft) if Oakley is the only supported key exchange and is there any need to implement the basic ISAKMP modes if one is supporting only key exchange for IPSEC? 5.1 Oakley Main Mode Oakley Main Mode looks a lot like the Identity Protection exchange from the ISAKMP draft, except that the Envelope is missing in all transactions, a Nonce is added to the third and fourth messages, and the placement of the optional Certificate relative to the Signature in the fifth and sixth messages is reversed. Can these two exchanges be merged somehow? Thanks, -- Shawn Mamros and Naganand Doraswamy Received: from relay.hq.tis.com by neptune.TIS.COM id aa23381; 8 Aug 96 10:59 EDT Received: by relay.hq.tis.com; id LAA11979; Thu, 8 Aug 1996 11:02:12 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma011952; Thu, 8 Aug 96 11:01:47 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA04033; Thu, 8 Aug 96 11:01:14 EDT Received: by relay.hq.tis.com; id LAA11939; Thu, 8 Aug 1996 11:01:41 -0400 Received: from janus.border.com(199.71.190.98) by relay.tis.com via smap (V3.1.1) id xma011899; Thu, 8 Aug 96 11:01:10 -0400 Received: by janus.border.com id <18491-2>; Thu, 8 Aug 1996 10:56:38 -0400 Date: Thu, 8 Aug 1996 10:55:11 -0400 From: Norman Shulman <norm@border.com> To: iesg@ietf.net MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Cc: ietf@ietf.net, ipsec@TIS.COM, mjo@tycho.ncsc.mil, rob.glenn@nist.gov MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Subject: <draft-ietf-ipsec-ah-hmac-md5-01.txt> Message-Id: <96Aug8.105638edt.18491-2@janus.border.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk Comments on <draft-ietf-ipsec-ah-hmac-md5-01.txt> Page 4, 2.1, paragraph 1: "Protection" should be "Prevention" in two places. Page 5, 2.2, paragraph 1, line 4: "zeros" should be "zeros prior to the computation". Page 5, 2.2, paragraph 2, line 4: "SHA" should be "MD5". Norman Shulman Border Network Technologies Inc. Software Engineer Tel 1 416 368 7157 ext 304 norm@border.com Fax 1 416 368 7178 Received: from relay.hq.tis.com by neptune.TIS.COM id aa23611; 8 Aug 96 11:03 EDT Received: by relay.hq.tis.com; id LAA12267; Thu, 8 Aug 1996 11:06:39 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma012241; Thu, 8 Aug 96 11:06:17 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA04276; Thu, 8 Aug 96 11:05:42 EDT Received: by relay.hq.tis.com; id LAA12229; Thu, 8 Aug 1996 11:06:09 -0400 Received: from janus.border.com(199.71.190.98) by relay.tis.com via smap (V3.1.1) id xma012224; Thu, 8 Aug 96 11:05:49 -0400 Received: by janus.border.com id <18468-1>; Thu, 8 Aug 1996 11:01:22 -0400 Date: Thu, 8 Aug 1996 10:58:36 -0400 From: Norman Shulman <norm@border.com> To: iesg@ietf.net MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Cc: ietf@ietf.net, ipsec@TIS.COM, shu-jen.chang@nist.gov, rob.glenn@nist.gov MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Subject: <draft-ietf-ipsec-ah-hmac-sha-01.txt> Message-Id: <96Aug8.110122edt.18468-1@janus.border.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk Comments on <draft-ietf-ipsec-ah-hmac-sha-01.txt> Page 4, paragraph 2, line 6: Delete the double quote. Page 4, 1.2, third sentence: Seems to me that the ability to handle unpadded message digests should either be dropped or made mandatory. If it is optional, then it adds an element to the security parameter negotiations. If it is retained, then 2.2(8) must be modified accordingly. Page 5, paragraph 1: "Protection" should be "Prevention" in two places. Page 6, 2.2(8): This has to be modified to accommodate an unpadded hash. Norman Shulman Border Network Technologies Inc. Software Engineer Tel 1 416 368 7157 ext 304 norm@border.com Fax 1 416 368 7178 Received: from relay.hq.tis.com by neptune.TIS.COM id aa25105; 8 Aug 96 12:09 EDT Received: by relay.hq.tis.com; id MAA15017; Thu, 8 Aug 1996 12:12:02 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma015011; Thu, 8 Aug 96 12:11:34 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA08265; Thu, 8 Aug 96 12:11:02 EDT Received: by relay.hq.tis.com; id MAA15008; Thu, 8 Aug 1996 12:11:32 -0400 Received: from ftp.com(128.127.2.122) by relay.tis.com via smap (V3.1.1) id xma015006; Thu, 8 Aug 96 12:11:22 -0400 Received: from ftp.com by ftp.com ; Thu, 8 Aug 1996 12:13:39 -0400 Received: from athena.ftp.com by ftp.com ; Thu, 8 Aug 1996 12:13:39 -0400 Message-Id: <2.2.32.19960808161836.00b48ca0@mailserv-H.ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 08 Aug 1996 12:18:36 -0400 To: Rodney Thayer <rodney@sabletech.com> From: Naganand Doraswamy <naganand@ftp.com> Subject: Re: I-D ACTION:draft-thayer-seccomp-00.txt Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Instead of adding a new header for compression, does it make sense to say that we negotiate compression as a part of transform? For example, can we negotiate a trasform for ESP which says DES-CBC 64 bit IV with compression enabled so that we compress the data before encrypting. We will avoid the extra overhead of another header this way. --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) Received: from relay.hq.tis.com by neptune.TIS.COM id aa03458; 8 Aug 96 17:37 EDT Received: by relay.hq.tis.com; id RAA27310; Thu, 8 Aug 1996 17:40:21 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma027285; Thu, 8 Aug 96 17:39:53 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA02519; Thu, 8 Aug 96 17:39:20 EDT Received: by relay.hq.tis.com; id RAA27277; Thu, 8 Aug 1996 17:39:51 -0400 Received: from iberia-c.it.earthlink.net(206.85.92.119) by relay.tis.com via smap (V3.1.1) id xma027271; Thu, 8 Aug 96 17:39:48 -0400 Received: from rmonsour (max2-wc-ca-39.earthlink.net [206.149.198.139]) by iberia.it.earthlink.net (8.7.5/8.7.3) with SMTP id OAA04041; Thu, 8 Aug 1996 14:40:46 -0700 (PDT) Message-Id: <2.2.32.19960808214308.006e95d4@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 08 Aug 1996 14:43:08 -0700 To: Naganand Doraswamy <naganand@ftp.com>, Rodney Thayer <rodney@sabletech.com> From: Bob Monsour <rmonsour@earthlink.net> Subject: Re: I-D ACTION:draft-thayer-seccomp-00.txt Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 12:18 PM 8/8/96 -0400, Naganand Doraswamy wrote: >Instead of adding a new header for compression, does it make sense to say >that we negotiate compression as a part of transform? For example, can we >negotiate a trasform for ESP which says DES-CBC 64 bit IV with compression >enabled so that we compress the data before encrypting. We will avoid the >extra overhead of another header this way. We at Stac have also been thinking about methods for adding compression in the context of IPsec; specifically due to the problem as identified in the draft as follows: The introduction of security into packets transmitted using Internet IP (Version 4) [RFC-791] causes a change in the applicability of compression technology to data communications. Specifically, when a packet is encrypted, it becomes essentially random data, and therefore is highly incompressible. This makes it difficult to use conventional techniques to compress IP datagrams, such as PPP compression. To solve this problem it becomes desirable to compress the data before it is encapsulated with security features. Our original thoughts were to push the compression function down to the ESP transform level, i.e., define a transform (or set of transforms) which combine compression with encryption under ESP and to include additional "opaque" transform data that was compression-specific to handle packet to packet sequencing for maintaining compression history across packets. The downside to this approach, however, is that it does not allow compression to be used in the absence of ESP (say, where only AH is used). I think that the general method proposed in Rodney's draft (or a derivative thereof) may indeed be preferable as it circumvents this problem. I would add that this does pose another problem for the environment where there may be a subsystem (say a chip or chipset) which takes an under-construction IP datagram as input and performs compression, encryption and AH MAC computation, outputting the complete IP datagram to be transmitted. Since the AH MAC is computed over the entire IP datagram, the datagram/payload length field of the packet is not known until after the data is compressed (prior to encryption). In order to avoid making multiple passes over the data, I would propose that the definition of the span of the MAC for AH eliminate the datagram/payload length field. Comments? Bob Monsour Stac, Inc. rmonsour@stac.com Received: from relay.hq.tis.com by neptune.TIS.COM id aa04588; 8 Aug 96 18:49 EDT Received: by relay.hq.tis.com; id SAA29323; Thu, 8 Aug 1996 18:52:22 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma029312; Thu, 8 Aug 96 18:51:53 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA04260; Thu, 8 Aug 96 18:51:21 EDT Received: by relay.hq.tis.com; id SAA29306; Thu, 8 Aug 1996 18:51:52 -0400 Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1.1) id xma029299; Thu, 8 Aug 96 18:51:22 -0400 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.5/8.6.12) with SMTP id SAA18933; Thu, 8 Aug 1996 18:53:29 -0400 (EDT) Message-Id: <199608082253.SAA18933@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Bob Monsour <rmonsour@earthlink.net> Cc: ipsec@TIS.COM Subject: Re: I-D ACTION:draft-thayer-seccomp-00.txt In-Reply-To: Your message of "Thu, 08 Aug 1996 14:43:08 PDT." <2.2.32.19960808214308.006e95d4@earthlink.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Thu, 08 Aug 1996 18:53:29 -0400 From: "Perry E. Metzger" <perry@piermont.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk Bob Monsour writes: > I would add that this does pose another problem for the environment where > there may be a subsystem (say a chip or chipset) which takes an > under-construction IP datagram as input and performs compression, encryption > and AH MAC computation, outputting the complete IP datagram to be > transmitted. Since the AH MAC is computed over the entire IP datagram, the > datagram/payload length field of the packet is not known until after the > data is compressed (prior to encryption). In order to avoid making multiple > passes over the data, I would propose that the definition of the span of the > MAC for AH eliminate the datagram/payload length field. > > Comments? That probably lowers security in some environments. Folding in the length of the datagram makes it harder to fake a datagram with the same MAC. Perry Received: from relay.hq.tis.com by neptune.TIS.COM id aa12867; 9 Aug 96 5:18 EDT Received: by relay.hq.tis.com; id FAA04564; Fri, 9 Aug 1996 05:21:36 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma004561; Fri, 9 Aug 96 05:21:08 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA15016; Fri, 9 Aug 96 05:20:35 EDT Received: by relay.hq.tis.com; id FAA04555; Fri, 9 Aug 1996 05:21:06 -0400 Received: from tik1.ethz.ch(129.132.119.131) by relay.tis.com via smap (V3.1.1) id xma004545; Fri, 9 Aug 96 05:20:52 -0400 Received: from komsys-pc-mw.ethz.ch (komsys-pc-mw [129.132.66.24]) by tik1.ethz.ch (8.7.5/8.7.3) with SMTP id LAA11191; Fri, 9 Aug 1996 11:22:54 +0200 (MET DST) Message-Id: <199608090922.LAA11191@tik1.ethz.ch> Received: by komsys-pc-mw.ethz.ch (NX5.67f2/NX3.0X) id AA00297; Fri, 9 Aug 96 11:22:44 +0200 Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) In-Reply-To: <2.2.32.19960808161836.00b48ca0@mailserv-H.ftp.com> X-Nextstep-Mailer: Mail 3.3 (Enhance 1.3) Received: by NeXT.Mailer (1.118.2) From: Marcel Waldvogel <mwa@tik.ee.ethz.ch> Date: Fri, 9 Aug 96 11:22:42 +0200 To: Naganand Doraswamy <naganand@ftp.com> Subject: Re: I-D ACTION:draft-thayer-seccomp-00.txt Cc: ipsec@TIS.COM References: <2.2.32.19960808161836.00b48ca0@mailserv-H.ftp.com> X-Image-Url: http://www.tik.ee.ethz.ch/~mwa/mwa.mail.tiff Sender: ipsec-approval@neptune.tis.com Precedence: bulk On Thu, 08 Aug 1996, Naganand Doraswamy <naganand@ftp.com> wrote: > Instead of adding a new header for compression, does it make sense to say > that we negotiate compression as a part of transform? For example, can we > negotiate a trasform for ESP which says DES-CBC 64 bit IV with compression > enabled so that we compress the data before encrypting. We will avoid the > extra overhead of another header this way. I think it's much better to have separate AH, ESP and COMP headers. I don't like the approach of creating combined AH-ESP transforms. Especially now, with the upcoming compression algorithms (which I'm very much in favor of), this would result in a massive explosion of the number of combined AH-COMP-ESP-transforms. Just having 2 of each of the transforms plus the possibility to drop any of them already gives us (2+1)^3=27 combinations, which already will make creating/maintaining any IPSEC implementation into a nightmare. Therefore I very much like the orthogonality approach originally intended, so that you can choose every combination of AH, COMP, and ESP you think fits your needs best. This approach also improves modularity and flexibility in the implementation. -Marcel --- Marcel Waldvogel Swiss Federal Institute of Technology (ETH) Phone/Fax +41-1-632 70 62/10 35 Computer Engineering and Networks Laboratory http://www.tik.ee.ethz.ch/~mwa ETH Zentrum, ETZ G63; CH-8092 Zürich PGP public key fingerprint = 5D D0 A1 6D F2 BC 60 69 46 49 2C 6D F8 EE 9E BF Received: from relay.hq.tis.com by neptune.TIS.COM id aa20960; 9 Aug 96 13:12 EDT Received: by relay.hq.tis.com; id NAA14267; Fri, 9 Aug 1996 13:02:43 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma014246; Fri, 9 Aug 96 13:02:14 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA06782; Fri, 9 Aug 96 13:01:41 EDT Received: by relay.hq.tis.com; id NAA14240; Fri, 9 Aug 1996 13:02:13 -0400 Received: from park.interport.net(199.184.165.2) by relay.tis.com via smap (V3.1.1) id xma014236; Fri, 9 Aug 96 13:01:49 -0400 Received: from massey (massey.ftp.com [128.127.128.152]) by park.interport.net (8.7.3/8.7.3) with SMTP id NAA05486; Fri, 9 Aug 1996 13:04:07 -0400 (EDT) Message-Id: <199608091704.NAA05486@park.interport.net> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 09 Aug 1996 13:03:46 -0400 To: ipsec@TIS.COM From: Rodney Thayer <rodney@sabletech.com> Subject: Re: compression algorithms Sender: ipsec-approval@neptune.tis.com Precedence: bulk Regarding mail from Marcel Waldvogel... >X-Nextstep-Mailer: Mail 3.3 (Enhance 1.3) >From: Marcel Waldvogel <mwa@tik.ee.ethz.ch> >Date: Fri, 9 Aug 96 11:22:42 +0200 >Especially now, with the upcoming compression algorithms (which I'm very >much in favor of), this would result in a massive explosion of the number of >combined AH-COMP-ESP-transforms. Which compression algorithms should be covered? I myself have thought about ZLIB, STAC, IBM. I know of at least one other. I'm curios if there are others because I'm trying to think about this in terms of providing capability for compression history/context or other features, Rodney Thayer <rodney@sabletech.com> +1 617 332 7292 Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA Fax: +1 617 332 7970 http://www.shore.net/~sable "Developers of communications software" Received: from relay.hq.tis.com by neptune.TIS.COM id aa22095; 9 Aug 96 13:57 EDT Received: by relay.hq.tis.com; id NAA16824; Fri, 9 Aug 1996 13:59:37 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma016812; Fri, 9 Aug 96 13:59:09 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA09559; Fri, 9 Aug 96 13:58:35 EDT Received: by relay.hq.tis.com; id NAA16809; Fri, 9 Aug 1996 13:59:06 -0400 Received: from zafu.bbn.com(128.89.0.25) by relay.tis.com via smap (V3.1.1) id xma016795; Fri, 9 Aug 96 13:58:50 -0400 Received: from [192.1.7.164] ([192.1.7.164]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id OAA26481; Fri, 9 Aug 1996 14:05:49 -0400 (EDT) Date: Fri, 9 Aug 1996 14:05:49 -0400 (EDT) X-Sender: rshirey@rosslyn.bbn.com Message-Id: <v02140b20ae30f468a8d0@[192.1.7.164]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Rodney Thayer <rodney@sabletech.com>, ipsec@TIS.COM From: "Robert W. Shirey" <rshirey@bbn.com> Subject: Re: compression algorithms A FEW MORE Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 1:03 PM 8/9/96, Rodney Thayer wrote: >Regarding mail from Marcel Waldvogel... > >>X-Nextstep-Mailer: Mail 3.3 (Enhance 1.3) >>From: Marcel Waldvogel <mwa@tik.ee.ethz.ch> >>Date: Fri, 9 Aug 96 11:22:42 +0200 > >>Especially now, with the upcoming compression algorithms (which I'm very >>much in favor of), this would result in a massive explosion of the number of >>combined AH-COMP-ESP-transforms. > >Which compression algorithms should be covered? I myself have thought about >ZLIB, STAC, IBM. I know of at least one other. I'm curios if there are >others because I'm trying to think about this in terms of providing >capability for compression history/context or other features, > > Rodney Thayer <rodney@sabletech.com> +1 617 332 7292 > Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA > Fax: +1 617 332 7970 http://www.shore.net/~sable > "Developers of communications software" Rod, There are a "few" that you have missed. (See attachment.) Regards, -Rob- rshirey@bbn.com, Tel 703-284-4641, Sec 284-4600, Fax 284-4777 Robert W. Shirey, BBN Corporation, Mail Stop 30/4C, Suite 1200, 1300 North Seventeenth Street, Arlington, Virginia 22209-3801 USA ----------------------------------------------------------------- The most recent copy of this text may be anonymous ftp'd from ftp.cso.uiuc.edu (128.174.5.61) in the directory /doc/pcnet as the file compression. This file is maintained by David Lemson (lemson@uiuc.edu). Please do not strip this note from this list when passing it on. ------------------------------------------------------------------------------- DECODING THIS CHART: This chart has been compacted to fit into 80 columns so it can be viewed on-line. The first column is the name of the compression/ archiving technique. The next field is the file extension given to the resulting file. After that are 5 columns each for a different operating system. Each one of these consists of the name of the file/program to undo the given compression/archiving style and a letter that tells where the file/program may be obtained. All symbols and letters are decoded at the bottom portion of this file. ------------------------------------------------------------------------------- FILE COMPRESSION, ARCHIVING, AND TEXT<->BINARY FORMATS Last Update: 17 October 1994 Operating System/Unpackaging Program NAME File DOS * Mac * Unix * VM/CMS * Amiga * Extension abe ? abe.exe N - abe Q - - afio - - - afio ? - - ar (any) - - ar L - - ARC .ARC arc602.exe B ArcMac1.3c D arc521 Barcutil2.04K Arc 0.23 Aa ARCHDOS .IBM Internal IBM only - creates .EXE self-extractors also ARJ .ARJ arj239d.exe B unarjmac B unarj230 B unarj K - BinHex .Hqx BINHEX.EXE B BinHex4.0 + A mcvert D binhex X - xbin23.zip B binscii * - - sciibin3.10 - - BLU ? - - - - - BOO .BOO msbpct.exe B ? ? - - - msbmkb.exe btoa (any)atob11.zip B + btoa L - compress Ab Bundle .bndl - Bundle ? Unbundle M - - CardDump(any) - - - card K - compact .C - - uncompact L - - Compact Pro .cpt EXT_PC10.arj ? Compact Pro 1.34 D - - - compress.Z u16.zip A MacCompress3.2D compress L compress K compress Ac comp430d.zip B .compressed *** NEXTSTEP - same as .tar.Z, use zcat <filnam> | tar xf - GNU ZIP .gz gzip123.exe B MacGzip0.2 D gzip123 L (NOTE: also known as "GNU Compress" and used .z extension until v 1.1.1) cpio ? pax2exe.zip H - cpio L - - COMT .COM comt010d.zip B - - - - Crunch ? - - - arcutil K - Diamond (spc+hibit) - Diamond 3.0 Z - - - Diet (any)diet110a.zip B - - - - Disk- Doubler .dd - DiskDoubler3.7.6 Z - - - Disk- .DMS - - - - dms-102 B Masher .EXE DWC .DWC dwc-a501.exe B - - - - FPack (any) ? ? FPack2.2 D ? ? - - HPACK .HPK hpack78.zip B HYPER .HYP hyper25.zip B - - - - Imploder(any) - - - - imploder1.3 B Ish .ish ish200.lzh B ishmac-0.6 D ? ? ? JPEG (any) (See note at bottom - C source available) *** Larc .LZS larc333.zip B - - - - LHA .LHA lha255b.exe B MacLHA 2.13 D lha1.00 U - lha_e138.run B LHarc .LZH lh113c.exe H MacLHarc 0.41 D lharc102 U - LHarc Ad (NOTE: LHA supersedes LHarc in functionality) LHWarp .LZW - LZWRes 1.0 D - - Lhwarp Ae LU (LAR).LBR lue220.arc B - l(t)ar ? arcutil K - LZari ? - MacLZAri 7-11 ? - - - LZEXE .EXE lzexe91.zip A - - - - LZSS .lzss ? ? CompRes 1.1 D - - - MDCD .MD mdcd10.arc B - - - - pack .z - - unpack L - - PackIt .pit UnPackIt ? PackIt3.1.3 D unpit ? - - PAK .PAK pak251.exe H ? ? - - - PKLITE .EXE pklte115.exe B - - - - PKPAK .ARC pk361.exe A ArcMac1.3c A arc521 I arcutil2.0K PKAX ? PKZIP .ZIP pkz204g.exe B ZipIt1.2.6 D unzip511 B arcutil2.04K PKAZip Af Power- .pp Packer - - - - PowerPacker Ai Scrunch .COM scrnch.arc B - - - - Shark - - sh E shell - .shar archive toadshr1.arc B UnShar2.1 D unshar L - UnShar Ag Ship (any) (See note at bottom about Ship and Portable Zip) * shrinkit.shk nulib34 O - nulib34 O - - Shrink- ToFit .stf - STF1.2 A - - - SPL ? - ? ? - - - Squash .ARC squash.arc B - - - - Squeeze .xQx sqpc131.arc B ? ? ? ? arcutil K Sq.Usq Ah Squeeze .sqz sqz1083.exe B StuffIt .sit unstuff.exe B StuffItLite307D unsit D - - tar .tar tar.zip A Tar 4.0b D tar L - TarSplit Ai tarread.arc I extar10.zip B ltarv1.zip B terse (any)Copyright IBM - - vmarc + - uuencode.UUE ncdc151.zip B uutool2.3.2 B uudecode L arcutil K uudecode Aj UltraCII.UC2 uc2ins.exe B - - - - Warp .WRP - - - - WarpUtil Ak whap .AP ? ? yabbawhap M ? yabbawhap M xxencode.XXE ncdc150.zip B - xxdecode A xxdecode K - yabba .Y ? ? yabbawhap M ? yabbawhap M ZOO .ZOO zoo210.exe A MacBooz2.1 D zoo210 B zoo K amigazoo A ------------------------------------------------------------------------------ Extended Chart: VMS * Apple 2 * Atari * OS/2 * Windows3 aaf (any) - aaftools O abe ? - - - - - afio - - - - - - ar (any) - - - - - ARC .arc arcvms.uue B angel.shk O B arc521e.arc R arc2.arc A - ARJ .ARJ unarj220 B - unarj_st.lzh R - - BinHex .Hqx - - - - - binscii * - binscii.exe O - - - BLU ? - unblu O - - - BOO .BOO - - - - - btoa (any) - - - - - Bundle .bndl - - - - - CardDump(any) - - - - - compact .C - - - - - Compact Pro .cpt - - - - - compress.Z lzdcomp.exe P compress.shk O compress.arc R - - cpio ? - - - - - Crunch ? - - - - - Disk- Doubler ? - - - - - DWC .DWC - - - - - FPack (any) - - - - - GZIP .gz gzip-1-2-2.zipP HPACK .HPK ? * ? * ? * ? * ? * HYPER .HYP - - - - - Larc .LZS - - - - - LHA .LHA - angel O - lha214_2 - LHarc .LZH - - lzh_2011.lzh R clhar103 S - LHWarp .LZW - - - - - LU(LAR) .LBR vmssweep B - - - - LZari ? - - - - - LZEXE .EXE - - - - - LZSS .lzss - - - - - MDCD .MD - - - - - PackIt .pit - - - - - PAK .PAK - - - - - PKPAK .ARC - - pkunarc.arc R - - PKZIP .ZIP unzip51 P pmpunzip20 B STZIP22.tos R pkz101-2.exe A - Power- Packer (any) - - - - - Scrunch .COM - - - - - shell- archive .shar - unshar.shk O shar.arc R - - shrinkit.shk - ? O - - - Shrink- ToFit .stf - - - - - SPL ? - - - - - Squash .ARC - - - - - Squeeze ? vmsusq.pas B a2unix O ezsqueeze.arc R - - StuffIt .Sit - - - - - tar .tar vmstar Q - sttar.arc R - - terse (any) - - - - - uuencode.uue uudecode2.vmsB uu.en.decode O uucode10.arcR - - Warp .WRP - - - - - whap ? ? - ? ? - xxencode.XXE - - - - - yabba ? ? - ? ? - ZOO .ZOO ZOO210.TAR-Z B - zoo21bin.arcR booz.exe A - ------------------------------------------------------------------------------ WHERE TO GET THEM: A. ftp.cso.uiuc.edu [128.174.5.61] /pc/exec-pc/ {Zip, arc, lots of good stuff} /pc/local /mac/ NOTE: Many mac things in: /mac/MUG/Utilities2.0-sit.Hqx;1 /amiga/fish/(see individual references) a ff070 b ff051 c ff051 d ff312 e ff305 f ff311 g ff345 h ff051 i ff053 j ff092 k ff243 i ff253 B. wuarchive.wustl.edu [128.252.135.4] (UIUC: NFS mounted on uxa and mrcnext) -> See H. below for another site for /systems/ibmpc/simtel/ directories <- /systems/ibmpc/simtel/archivers/ {arc, LHARC, hpack} /filutl/ {atob11, msbpct - BOO, toadshr, DIET, ncdc151} /sq-usq/ {NUSQ} /zip/ {unzip} /mac/ {unsit30} /systems/mac/info-mac/util/ /systems/unix/arc-progs/ {ARC,GZIP} /misc/vaxvms/ {UNZIP for VMS} /misc/unix/ {UNZIP, ZOO for UNIX/VMS, UNARJ} /systems/amiga/aminet/util/arc {AMIGA} /systems/amiga/aminet/util/pack {AMIGA} /systems/apple2/umich.edu/gs/util {Apple 2} C. omnigate.clarkson.edu [128.153.4.2] /pub/ncsa2.2tn/ D. sumex-aim.stanford.edu [36.44.0.6] /info-mac/util/ {Stuffit Lite, Compactor Pro, etc.} /unix/ {unsit, mcvert} E. ftp.uu.net [137.39.1.9] /pub/ /ioccc/shar.1990.* {shark} F. grape.ecs.clarkson.edu [128.153.28.129.] - collection varies - see the file 'allfiles' G. watsun.cc.columbia.edu [128.59.39.2] Definitive source for KERMIT releases for all machines /kermit/a/ H. wsmr-simtel20.army.mil [192.88.110.20] oak.oakland.edu [141.210.10.117] is the primary mirror for simtel20. wuarchive (B) is a secondary mirror. cd pd1:<msdos.arc-lbr> SIMTEL20 files are available by anonymous ftp from mirror sites OAK.Oakland.Edu (141.210.10.117), wuarchive.wustl.edu (128.252.135.4), archive.orst.edu (128.193.2.13), ftp.uu.net (137.39.1.9), nic.funet.fi (128.214.6.100), src.doc.ic.ac.uk (146.169.3.7), nic.switch.ch (130.59.1.40), archie.au (139.130.4.6), NCTUCCCA.edu.tw (140.111.3.21), by e-mail through the BITNET/EARN file servers, or by uucp from UUNET's 1-900-GOT-SRCS. See UUNET file uunet!~/info/archive-help for details. I. pc.usl.edu [130.70.40.3] /pub/unix/ K. vmd.cso.uiuc.edu [128.174.5.98] card - cd public.460 others, including ARCUTIL - cd public.477 - NOTE: UUDECODE, UNARJ, ZOO and COMPRESS are originally from LISTSERV@BLEKUL11 L. (should be available on all major unix systems including wuarchive.wustl.edu in /unix-c/arc-progs also uxc.cso.uiuc.edu in /pub) M. comp.sources.unix archives (varies, including wuarchive in /usenet/comp.sources.unix) N. comp.binaries.ibm.pc archives (varies, including wuarchive in /usenet/comp.binaries.ibm.pc) O. cco.caltech.edu [131.215.139.100] /pub/apple2/ {binscii.exe} /ARCHIVERS {angel.shk, unblu in a2unix.aaf} /source {aaftools} P. ftp.spc.edu [192.107.46.27] GZIP - [.macro32.savesets]gzip-1-*.zip (use [.macro32]unzip.exe to extract) Q. vmsa.oac.uci.edu [128.200.9.5] / R. atari.archive.umich.edu [141.211.164.8] /atari/archivers/ S. mtsg.ubc.ca [137.82.27.1] /os2 U. alt.sources archives (available on wuarchive.wustl.edu in /usenet/alt.sources/) {LHarc is articles number 2217 and 2218} V. rascal.ics.utexas.edu [128.83.138.20] /misc/mac/utilies W. akiu.gw.tohoku.ac.jp [130.34.8.9] /pub/mac/tools/archiver X. brownvm.brown.edu [128.148.128.40] / {BINHEX.READ-ME for instructions} Z. Commercial software product - check discount mail order software houses, computer stores. NOTES: Symbols: + means see the notes below for special information - means that nothing exists to the best of my knowledge ? means that something exists but I do not know the name of the program or where to get it * means that e-mail should be sent to lemson@uiuc.edu for details/explanation JPEG - source (Free code) is available in ftp.uu.net:/graphics/jpeg/jpegsrc.v?.tar.Z. Supports conversion between JPEG "JFIF" format and image files in PBMPLUS PPM, Utah RLE, Truevision Targa, and GIF file formats. Contact for more info: Dr. Thomas G. Lane, organizer, Independent JPEG Group Internet: jpeg-info@uunet.uu.net Current version (1/93) is v4. PKZIP 2.04g is shareware. The Encryption version is freely exportable to all countries except Cuba,Iran,Iraq,North Korea, the police or military of South Africa, Syria, and Vietnam. (by order of the US Government) Some uuencode/uudecode programs are able to read xxencode files. Stuffit Lite 3.0 is the replacement version of Stuffit Classic 1.6 for Macintosh. Stuffit Lite is shareware, $25. Stuffit Deluxe is the commercial version from Aladdin Software. Stuffit Expander 3.0.1 is a free version from Aladdin that can decompress most Macintosh compression schemes. It is available in the same place as other Mac decompression products. VMARC, available with the command "TELL LISTSERV AT RPIECS GET VMARC PACKAGE" from a CMS machine, will decode any CMS terse program. The PC version of terse is a commercial program available from IBM directly. There is a portable 'ZIP' that goes along with unzip50p1 that is available from wuarchive and other mirrors in the same places as unzip. (see (B) above) WizUnzip, WINUNZ20.ZIP in the WINDOWS3 dir on wuarchive (B), is a MS Windows 3 version of Unzip50p1. GZIP, the GNU Zip-like utility, is available from prep.ai.mit.edu. Current version is 1.2.2 (16 June 93). A VMS version is available as follows: (this has binaries for VMS for VAX and AXP) To get gzip via anonymous ftp from ftp.spc.edu, you'll need: [.MACRO32]UNZIP.EXE or UNZIP.ALPHA_EXE [.MACRO32.SAVESETS]GZIP-1-2-2.ZIP To get it via e-mail, send the following commands in the body of a mail message to FILESERV@WKUVX1.WKU.EDU: SEND GZIP-1-2-2 SEND FILESERV_TOOLS There is a set of translators that will allow Stuffit Deluxe to read btoa, UUencoded files, zip, pack, tar, MacBinary, and others. They are in sumex-aim.stanford.edu:/info-mac/utils/stuffit-deluxe-translators.hqx. When using tar.exe for PC's, the order of option flags is important. For extraction, use tar -xvf <filename>. ARC : From SEA, ARC 6.02 is the latest widespread shareware release. It is available at A (ftp.cso.uiuc.edu). Also, SEA has ARC 7.10, but it is commercial, not shareware. (see note at bottom) When using binscii.exe for an Apple II, there are different file extensions depending on the type of file being changed. BinHexed files (with the extension .hqx) can be UnBinHexed with BinHex 4.0 or Stuffit (preferably Stuffit). BinHex5.0 format is a MacBinary format, while BinHex 4.0 files are ASCII format. The files listed are only supposed to uncompress/unarchive. To compress/archive, further software may be needed. USAGE NOTES: There are certain "standard" combinations of compression used: unix - .tar.Z (often this will be .taz for PC's) unix - tar.Z.btoa (abbrev. to .TZB sometimes) (aka "tarmail") mac - .sit.hqx - these must be undone in order starting at the end of the name Sometimes an archive may be self-extracting. These will look like normal executable programs. Simply run them to undo the archive. LZEXE (PC), PKLITE(PC), Imploder(Amiga), and PowerPacker(Amiga) are executable compressors. They compress an executable file and attach an uncompressing header so that the file can still be executed while in compressed form. The listed programs for these utilities compress files, in order to uncompress a file with these types of compression, just execute them. DIET (PC) is a TSR program that compresses and decompresses both executables and data files as needed. DEFINITIVE SOURCES: PKWARE Support BBS - avaliable 24 hours (414) 352-7176 ZOO - author: Rahul Dhesi source code in C on Usenet and GEnie's IBM PC Roundtable ARC - SEA (System Enhancement Associates, Inc.) 804-442-5865 Received: from relay.hq.tis.com by neptune.TIS.COM id aa25026; 9 Aug 96 16:14 EDT Received: by relay.hq.tis.com; id QAA20304; Fri, 9 Aug 1996 16:17:07 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma020301; Fri, 9 Aug 96 16:16:41 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA16211; Fri, 9 Aug 96 16:16:07 EDT Received: by relay.hq.tis.com; id QAA20288; Fri, 9 Aug 1996 16:16:38 -0400 Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1.1) id xma020279; Fri, 9 Aug 96 16:16:09 -0400 Received: from copacabana.watson.ibm.com (copacabana.watson.ibm.com [9.2.19.74]) by igw2.watson.ibm.com (8.7.4/8.7.1) with SMTP id QAA21160; Fri, 9 Aug 1996 16:18:57 -0400 Received: by copacabana.watson.ibm.com (AIX 3.2/UCB 5.64/5/18/96) id AA19934; Fri, 9 Aug 1996 16:16:53 -0400 Date: Fri, 9 Aug 1996 16:16:53 -0400 From: "H.Krawczyk" <hugo@watson.ibm.com> Message-Id: <9608092016.AA19934@copacabana.watson.ibm.com> To: iesg@ietf.org Subject: Re: Last Call: HMAC-IP (Truncated HMAC-SHA) Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk > > 2. HMAC-SHA IP Authentication with Replay Prevention > <draft-ietf-ipsec-ah-hmac-sha-01.txt> > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by August 20, 1996. I propose the following change to the above draft (page 6). Replace: > (7) apply SHA to the stream generated in step (6) > (8) The sender then zero pads the resulting hash to a 64-bit boundary > for word alignment. The receiver compares the generated 160-bit hash > to the first 160-bits of authentication data contained in the AH. With: (7) apply SHA to the stream generated in step (6) and output the first (leftmost) 128 bits of the result. -------- Thus, I am proposing that instead of padding the 160 bits of SHA output to 192 bits, truncate the result to 128 bits. Beyond the advantage for bandwidth, this truncation is plausible to add to the security. In general, it is an old practice to truncate MACs. In the context of keyed-hash this has been explicitely proposed by Preneel and van Oorschot (Crypto'95). I do not know of any *proof* that truncating adds to the security. However, there are examples of attacks where this is the case. And as long as you do not truncate "too much" then everything indicates that it helps. In particular, I know of no reason how or why truncating HMAC-SHA to 128 bits would hurt in any scenario. Note: Be careful not to get confused with the unkeyed uses of SHA. There, collision resistance is usually the sacred goal and truncating the output HURTS HURTS HURTS (because of birthday attacks). For keyed-hash for message authentication the story is very different. Actually, the justification for truncation in [PV] is *exactly* because it helps *against* birthday attacks. (Yes, I know it sounds confusing but that's the way it is...) Still in the application of HMAC the 160 bits in the definition of SHA help as the length of the *intermediate* results of the compression function, but not as the final result. ANyway, truncation as a general method has an advantage (less information available to the adversary) and a disadvantage (less bits to predict for the attacker). When truncating 160 to 128 the advatage is far more significant than the disadvantage (It would be different if we truncated to 64 bits; that would make me uncomfortable -- 80 bits for SHA or even for MD5 are my "personal minimum".) BTW, in the RFC on HMAC that I am submitting to the IETF there is a section on truncation of HMAC output. ---------- The patent issue: There is a patent by Novell (US 5349642) that claims keyed hash functions for message authentication. Such claim would cover (I am not a lawyer!) all hash based schemes that have ever been suggested in this WG, including HMAC. Fortunately, the filing date of that patent is Nov 3 1992, while Gene Tsudik's paper proposing such functions appeared in Infocom in May 1992. (This work is also part of Gene's UCLA's PhD dissertation of May 1991). The one element that does not appear in Tsudik's work is truncation. However, truncating the output of MAC functions is an old and very well known practice in cryptography. For example, [MM] Meyer, S. and Matyas, S.M., Cryptography, New York Wiley, 1982. [ANSI] ANSI X9.9, ``American National Standard for Financial Institution Message Authentication (Wholesale),'' American Bankers Association, 1981. Revised 1986. and therefore a hard to defend claim (I'm not a lawyer!!). After consulting with Jeff Schiller and the WG chairs, it became clear to me that the existence of Novell's patent shouldn't be an obstacle to include a section on truncation in the HMAC rfc, and more significantly, to propose it for adoption for AH-HMAC-SHA. Hugo PS: In the next weeks I will be reading e-mail very sporadicly (like, maybe, once each two weeks :), so do not get angry if I do not respond (especially after Tuesday). Received: from relay.hq.tis.com by neptune.TIS.COM id aa25334; 9 Aug 96 16:25 EDT Received: by relay.hq.tis.com; id QAA20612; Fri, 9 Aug 1996 16:28:37 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma020596; Fri, 9 Aug 96 16:28:10 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA16738; Fri, 9 Aug 96 16:27:37 EDT Received: by relay.hq.tis.com; id QAA20591; Fri, 9 Aug 1996 16:28:07 -0400 Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1.1) id xma020566; Fri, 9 Aug 96 16:27:44 -0400 Received: from copacabana.watson.ibm.com (copacabana.watson.ibm.com [9.2.19.74]) by igw2.watson.ibm.com (8.7.4/8.7.1) with SMTP id QAA08862; Fri, 9 Aug 1996 16:30:35 -0400 Received: by copacabana.watson.ibm.com (AIX 3.2/UCB 5.64/5/18/96) id AA24044; Fri, 9 Aug 1996 16:28:48 -0400 Date: Fri, 9 Aug 1996 16:28:48 -0400 From: "H.Krawczyk" <hugo@watson.ibm.com> Message-Id: <9608092028.AA24044@copacabana.watson.ibm.com> To: perry@piermont.com Subject: Re: I-D ACTION:draft-thayer-seccomp-00.txt Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Perry, > > Bob Monsour writes: > > I would add that this does pose another problem for the environment where > > there may be a subsystem (say a chip or chipset) which takes an > > under-construction IP datagram as input and performs compression, encryption > > and AH MAC computation, outputting the complete IP datagram to be > > transmitted. Since the AH MAC is computed over the entire IP datagram, the > > datagram/payload length field of the packet is not known until after the > > data is compressed (prior to encryption). In order to avoid making multiple > > passes over the data, I would propose that the definition of the span of the > > MAC for AH eliminate the datagram/payload length field. > > > > Comments? > > That probably lowers security in some environments. Folding in the > length of the datagram makes it harder to fake a datagram with the > same MAC. A personal "historical" remark: One of the design principles of HMAC was not to rely on prepended length. Actually, my own involvement with MAC based on hash functions in IPSEC started when the "official" proposal for AH was to use prepend-only key (ie, MD5(K,data)) which *requires* prepended length (to prevent trivial extension attacks). The answer to this objection of mine by certain people in the group (I'm sure you remember) was that IP headers carry the length anyway. I tried to argue that relying on that was a security and engineering mistake: ``may be one day...'' went the argument. The day is now here. A good lesson against security myopia And by the way, in Jim Hughes' draft the header (and then length) is not authenticated either. All of this is not to say that certain MAC (like CBC-MAC or even HMAC with some hash functions) couldn't be benefited from prepended length. But in that case the MAC MUST include the prepended length as part of its definition and not to rely on the particularities of the data being authenticated. Hugo > > Perry Received: from relay.hq.tis.com by neptune.TIS.COM id aa25791; 9 Aug 96 16:36 EDT Received: by relay.hq.tis.com; id QAA20963; Fri, 9 Aug 1996 16:39:07 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma020952; Fri, 9 Aug 96 16:38:39 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA17198; Fri, 9 Aug 96 16:38:06 EDT Received: by relay.hq.tis.com; id QAA20946; Fri, 9 Aug 1996 16:38:37 -0400 Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1.1) id xma020937; Fri, 9 Aug 96 16:38:17 -0400 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.5/8.6.12) with SMTP id QAA05056; Fri, 9 Aug 1996 16:40:37 -0400 (EDT) Message-Id: <199608092040.QAA05056@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: "H.Krawczyk" <hugo@watson.ibm.com> Cc: ipsec@TIS.COM Subject: Re: I-D ACTION:draft-thayer-seccomp-00.txt In-Reply-To: Your message of "Fri, 09 Aug 1996 16:28:48 EDT." <9608092028.AA24044@copacabana.watson.ibm.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 09 Aug 1996 16:40:31 -0400 From: "Perry E. Metzger" <perry@piermont.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk "H.Krawczyk" writes: > > That probably lowers security in some environments. Folding in the > > length of the datagram makes it harder to fake a datagram with the > > same MAC. > > A personal "historical" remark: > > One of the design principles of HMAC was not to rely on prepended length. Certainly. But not all MACs used by IPSEC will necessarily be as robust as HMAC. > All of this is not to say that certain MAC (like CBC-MAC or even HMAC > with some hash functions) couldn't be benefited from prepended length. But > in that case the MAC MUST include the prepended length as part of its > definition and not to rely on the particularities of the data being > authenticated. Certainly at the very least one must mention in such a transform document that one is explicitly relying on the length being present... Perry Received: from relay.hq.tis.com by neptune.TIS.COM id aa27233; 9 Aug 96 17:33 EDT Received: by relay.hq.tis.com; id RAA22173; Fri, 9 Aug 1996 17:36:07 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma022154; Fri, 9 Aug 96 17:35:47 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA19145; Fri, 9 Aug 96 17:35:06 EDT Received: by relay.hq.tis.com; id RAA22144; Fri, 9 Aug 1996 17:35:38 -0400 Received: from mailserv.esat.kuleuven.ac.be(134.58.56.129) by relay.tis.com via smap (V3.1.1) id xma022136; Fri, 9 Aug 96 17:35:20 -0400 Received: from domus.esat.kuleuven.ac.be by mailserv (5.67b8/IDA/v1.5) id AA14910; Fri, 9 Aug 1996 23:37:22 +0200 Date: Fri, 9 Aug 1996 23:37:23 +0200 (METDST) From: Bart Preneel <Bart.Preneel@esat.kuleuven.ac.be> To: "H.Krawczyk" <hugo@watson.ibm.com> Cc: iesg@ietf.org, ipsec@TIS.COM Subject: Re: Last Call: HMAC-IP (Truncated HMAC-SHA) In-Reply-To: <9608092016.AA19934@copacabana.watson.ibm.com> Message-Id: <Pine.HPP.3.91.960809232943.11184E-100000@domus.esat.kuleuven.ac.be> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Charset: ISO_8859-1 X-Char-Esc: 29 Sender: ipsec-approval@neptune.tis.com Precedence: bulk Hugo, I support your statement that shortening the result of HMAC based on SHA-1 from 160 to 128 bits will probably be an improvement. I would not even see a problem to shorten the SHA-1 output to 64 bits. When considering attack scenarios, I would be much more worried about an attacker who uses the known text-MAC pairs to obtain information on the key than about an attacker who tries to predict some bits to forge a MAC for two reasons: - a key recovery is more serious than a forgery - for concrete hash functions such as MD5 and SHA-1, I feel that the first attack is more likely (just intuition). Bart ------------------------------------------------------------------------------- Katholieke Universiteit Leuven tel. +32 16 32 11 48 Dept. Electrical Engineering-ESAT / COSIC fax. +32 16 32 19 86 K. Mercierlaan 94, B-3001 Heverlee, BELGIUM bart.preneel@esat.kuleuven.ac.be ------------------------------------------------------------------------------- On Fri, 9 Aug 1996, H.Krawczyk wrote: ... > Thus, I am proposing that instead of padding the 160 bits of SHA output > to 192 bits, truncate the result to 128 bits. > > Beyond the advantage for bandwidth, this truncation is plausible to > add to the security. > ... > Anyway, truncation as a general method has an advantage (less information > available to the adversary) and a disadvantage (less bits to predict for the > attacker). When truncating 160 to 128 the advatage is far more significant > than the disadvantage (It would be different if we truncated to 64 bits; > that would make me uncomfortable -- 80 bits for SHA or even for MD5 are my > "personal minimum".) > ... Received: from relay.hq.tis.com by neptune.TIS.COM id aa27702; 9 Aug 96 17:53 EDT Received: by relay.hq.tis.com; id RAA22547; Fri, 9 Aug 1996 17:56:08 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma022543; Fri, 9 Aug 96 17:55:40 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA19704; Fri, 9 Aug 96 17:55:06 EDT Received: by relay.hq.tis.com; id RAA22537; Fri, 9 Aug 1996 17:55:38 -0400 Received: from janus.border.com(199.71.190.98) by relay.tis.com via smap (V3.1.1) id xma022532; Fri, 9 Aug 96 17:55:31 -0400 Received: by janus.border.com id <18436-1>; Fri, 9 Aug 1996 17:57:20 -0400 Message-Id: <96Aug9.175720edt.18436-1@janus.border.com> To: "Robert W. Shirey" <rshirey@bbn.com> Cc: Rodney Thayer <rodney@sabletech.com>, ipsec@TIS.COM Subject: Re: compression algorithms A FEW MORE References: <v02140b20ae30f468a8d0@[192.1.7.164]> In-Reply-To: Your message of "Fri, 09 Aug 1996 14:05:49 -0400". <v02140b20ae30f468a8d0@[192.1.7.164]> From: "C. Harald Koch" <chk@border.com> Organization: Border Network Technologies Inc. Phone: +1 416 368 7157 X-Uri: <URL:http://www.border.com/homes/chk/> X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Fri, 9 Aug 1996 17:57:47 -0400 Sender: ipsec-approval@neptune.tis.com Precedence: bulk This is getting a bit off-topic. However: In message <v02140b20ae30f468a8d0@[192.1.7.164]>, "Robert W. Shirey" writes: > > There are a "few" that you have missed. (See attachment.) That list contains file comression and archiving *software*, not compression algorithms. Those packages use one (or more) of a very small number of compression algorithms. In fact, most of the algorithms used are simply variants on LZ77 and LZ78, usually combined with other algorithms like Huffman coding or Shannon-Fano coding. For more details on compression algorithms, see the comp.compression FAQ documents, available from <ftp://rtfm.mit.edu/pub/usenet/news.answers/compression-faq/> (among other places). One explicit quote: "All popular archivers (arj, lha, zip, zoo) are variations on the LZ77 theme." -- C. Harald Koch | Border Network Technologies Inc. chk@border.com | Senior System Developer +1 416 368 7157 (voice) | 20 Toronto Street, Suite 400, Toronto ON M5C 2B8 +1 416 368 7789 (fax) | Madness takes its toll. Please have exact change. Received: from relay.hq.tis.com by neptune.TIS.COM id aa24343; 11 Aug 96 17:44 EDT Received: by relay.hq.tis.com; id RAA07293; Sun, 11 Aug 1996 17:47:33 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma007291; Sun, 11 Aug 96 17:47:05 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA21490; Sun, 11 Aug 96 17:46:30 EDT Received: by relay.hq.tis.com; id RAA07288; Sun, 11 Aug 1996 17:47:03 -0400 Received: from merit.edu(35.1.1.42) by relay.tis.com via smap (V3.1.1) id xma007283; Sun, 11 Aug 96 17:46:48 -0400 Received: from Bill.Simpson.DialUp.Mich.Net (pm002-21.dialip.mich.net [141.211.7.157]) by merit.edu (8.7.5/merit-2.0) with SMTP id RAA02117 for <ipsec@TIS.COM>; Sun, 11 Aug 1996 17:49:03 -0400 (EDT) Date: Sun, 11 Aug 96 21:37:26 GMT From: William Allen Simpson <wsimpson@greendragon.com> Message-Id: <5409.wsimpson@greendragon.com> To: iesg@ietf.org Cc: ipsec@TIS.COM Subject: Re: Last Call: HMAC-IP (Truncated HMAC-SHA) Sender: ipsec-approval@neptune.tis.com Precedence: bulk I had proposed shortening the length of the SHA output last winter. However, there was strong consensus on the ipsec-dev list that multiple lengths be supported. And thus, the language in draft-simpson-ah-sha- kdp-00.txt. I urge these authors to insert this facility in their draft: Therefore, several options are available for data alignment (most preferred to least preferred): 1) only the most significant 128-bits (16 octets) of output are used. 2) an additional 32-bits (4 octets) of padding is added before the SHA1 output. 3) an additional 32-bits (4 octets) of padding is added after the SHA1 output. 4) the SHA1 output is variably bit-positioned within 192-bits (24 octets). The size and position of the output are negotiated as part of the key management. Padding bits are filled with unspecified implementation dependent (random) values, which are ignored on receipt. Discussion: Although truncation of the output for alignment purposes may appear to reduce the effectiveness of the algorithm, some analysts of attack verification suggest that this may instead improve the overall robustness [PO95a]. ... [PO95a] Preneel, B., and van Oorshot, P., "MDx-MAC and Building Fast MACs from Hash Functions", Advances in Cryptology -- Crypto '95 Proceedings, Santa Barbara, California, August 1995. > Date: Fri, 9 Aug 1996 23:37:23 +0200 (METDST) > From: Bart Preneel <Bart.Preneel@esat.kuleuven.ac.be> > I would not even see a problem to shorten the SHA-1 output to > 64 bits. When considering attack scenarios, I would be much more > worried about an attacker who uses the known text-MAC pairs to > obtain information on the key than about an attacker who tries to > predict some bits to forge a MAC for two reasons: > - a key recovery is more serious than a forgery > - for concrete hash functions such as MD5 and SHA-1, I feel > that the first attack is more likely (just intuition). > WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 Received: from relay.hq.tis.com by neptune.TIS.COM id aa04923; 12 Aug 96 7:35 EDT Received: by relay.hq.tis.com; id HAA12073; Mon, 12 Aug 1996 07:38:34 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma012070; Mon, 12 Aug 96 07:38:07 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA01841; Mon, 12 Aug 96 07:37:31 EDT Received: by relay.hq.tis.com; id HAA12065; Mon, 12 Aug 1996 07:38:04 -0400 Received: from unknown.tycho.ncsc.mil(144.51.3.1) by relay.tis.com via smap (V3.1.1) id xma012059; Mon, 12 Aug 96 07:37:34 -0400 Received: by tarius.tycho.ncsc.mil (4.1/SMI-4.1) id AA07014; Mon, 12 Aug 96 07:39:40 EDT Date: Mon, 12 Aug 96 07:39:40 EDT From: "Mark S. Schneider" <mss@tycho.ncsc.mil> Message-Id: <9608121139.AA07014@tarius.tycho.ncsc.mil> To: naganand@ftp.com Subject: Re: Comments on ISAKMP/Oakley Cc: ipsec@TIS.COM, mss@tycho.ncsc.mil, wdm@tycho.ncsc.mil, sjt@tycho.ncsc.mil, mjs@terisa.com Sender: ipsec-approval@neptune.tis.com Precedence: bulk > From: Naganand Doraswamy <naganand@ftp.com> > > These are mostly implemetation type comments: > > 2.4.1. Security Association Payload > Is the "Payload Length" field *really* supposed to be specified in > four-octet units, or should it be in octets as all the other payloads > are? > I believe it should be in octets. It seems unlikely that a SA payload will ever be large enough to require a length in 4-octet units. > > A.6.1. Attribute Value Assigned Numbers, IPSEC ESP > TLV constructs: how long is "Type"? How long is "Length"? Is "Length" > in terms of octets, or some other unit? Are the lengths of "Type" and > "Length" included in "Length" or not? 1 2 3 TLV = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Tag/Type ! Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value/Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where Length is the length of the Value/Data *only* in the TLV. > > Where is "Multiple Precision Integer" specified? > It's defined in draft-ietf-ipsec-oakley-01.txt, Appendix D. > > A.7.1 The basic proposal format does has the following fields defined in the > header: > - Proposal #, Proposal Len, Protocol # and Attribute TLV's > However, the ESP, AH, and ISAKMP proposals have defined the > Transforms ID's and a reserved field. Shouldnt the basic proposal > format take care of this as well? Yes. I guess we intended that the TLV could be used for the Transform ID. Granted, that would take 8 octets. Are you suggesting adding a Transform ID field to the Proposal #, Proposal Len, and Protocol # fields? If so, how do you think this should be done? Reducing the size of the Protocol # field? Your thoughts are appreciated. > > A.7.4. Proposal Formats, ISAKMP: ??? > Section A.7.4. is intended to describe the confidentiality and authentication mechanisms that are internal to ISAKMP and used to provide Phase I security. Confidentiality will be provided by applying the IPsec ESP transform(s) to ISAKMP messages. Authentication can also use IPsec AH transforms, only if keys have been preplaced. This means we have to determine a public key mechanism for authentication. We're working on this. > > A.8.1. Security Association Payload Format > Does the Situation field length need to be an integral multiple of > four octets, as the Proposal field needs to be? Is the Situation Length > field (Figure 20) specified as octets, four-octet units, or ... ? > It should be specified as the size in octets. > draft-ietf-ipsec-isakmp-oakley-00.txt > Where are ISAKMP exchange numbers defined for the various Oakley modes? They currently aren't defined in the ISAKMP draft. In the next version, I assume they will be assigned exchange numbers 4-7. > What happens to the Base, Identity Protection, and Authentication Only > exchanges defined in the ISAKMP draft? How does one implemement the other > exchanges (which are defined as MUSTs in the ISAKMP draft) if Oakley is > the only supported key exchange and is there any need to implement the basic > ISAKMP modes if one is supporting only key exchange for IPSEC? We see ISAKMP as a framework that permits negotiation of many security features, including the key exchange mechanism. The exchange types defined by the ISAKMP/Oakley resolution draft all have a defined key exchange. In this case the key exchange is not negotiable. To support negotiation of key exchange mechanisms, the three exchange types defined in ISAKMP are *required*. If they didn't exist, then it would be impossible to negotiatiate key exchange mechanisms. Actually, upon looking closer at the ISAKMP exchanges and Oakley exchanges, a generalization of the Oakley modes can be made in the ISAKMP draft. Since, as you note below, Oakley Main Mode is equivalent to ISAKMP's ID Protect exchange, then it seems that Oakley Aggressive, Quick, and New Group modes (maybe) can be generalized to ISAKMP Aggressive, Quick, and SA Only exchanges. The proposal could then include Oakley as the key exchange mechanism along with the specific Oakley group that should be used. Thoughts on this?? > 5.1 Oakley Main Mode > Oakley Main Mode looks a lot like the Identity Protection exchange from > the ISAKMP draft, except that the Envelope is missing in all transactions, > a Nonce is added to the third and fourth messages, and the placement of > the optional Certificate relative to the Signature in the fifth and sixth > messages is reversed. Can these two exchanges be merged somehow? Actually, I think the two should look identical. ISAKMP is missing nonces for "freshness". We also feel the envelope payload should be standardized in all messages: i.e. always used for consistency purposes. They can't be merged as the Oakley key exchange is required in Oakley Main Mode and not required in ISAKMP's ID Protect Mode. > Thanks, > -- Shawn Mamros and Naganand Doraswamy Regards, Mark Schneider Received: from relay.hq.tis.com by neptune.TIS.COM id aa11693; 12 Aug 96 13:13 EDT Received: by relay.hq.tis.com; id NAA22473; Mon, 12 Aug 1996 13:16:39 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma022465; Mon, 12 Aug 96 13:16:12 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA20539; Mon, 12 Aug 96 13:15:36 EDT Received: by relay.hq.tis.com; id NAA22459; Mon, 12 Aug 1996 13:16:09 -0400 Received: from p-spatsch.cs.arizona.edu(150.135.1.98) by relay.tis.com via smap (V3.1.1) id xma022448; Mon, 12 Aug 96 13:15:47 -0400 Received: from localhost (spatsch@localhost) by P-spatsch.cs.arizona.edu (8.6.12/8.6.9) with SMTP id KAA30687; Mon, 12 Aug 1996 10:03:48 -0700 X-Authentication-Warning: P-spatsch.cs.arizona.edu: spatsch owned process doing -bs Date: Mon, 12 Aug 1996 10:03:46 -0700 (MST) From: Oliver Spatscheck <spatsch@cs.arizona.edu> To: "Mark S. Schneider" <mss@tycho.ncsc.mil> Cc: naganand@ftp.com, ipsec@TIS.COM, wdm@tycho.ncsc.mil, sjt@tycho.ncsc.mil, mjs@terisa.com Subject: Re: Comments on ISAKMP/Oakley In-Reply-To: <9608121139.AA07014@tarius.tycho.ncsc.mil> Message-Id: <Pine.LNX.3.94.960812095207.30099B-100000@P-spatsch.cs.arizona.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Mon, 12 Aug 1996, Mark S. Schneider wrote: > > We see ISAKMP as a framework that permits negotiation of many security > features, including the key exchange mechanism. The exchange types > defined by the ISAKMP/Oakley resolution draft all have a defined key > exchange. In this case the key exchange is not negotiable. To support > negotiation of key exchange mechanisms, the three exchange types defined > in ISAKMP are *required*. If they didn't exist, then it would be > impossible to negotiatiate key exchange mechanisms. > > Actually, upon looking closer at the ISAKMP exchanges and Oakley exchanges, > a generalization of the Oakley modes can be made in the ISAKMP draft. Since, > as you note below, Oakley Main Mode is equivalent to ISAKMP's ID Protect > exchange, then it seems that Oakley Aggressive, Quick, and New Group > modes (maybe) can be generalized to ISAKMP Aggressive, Quick, and SA Only > exchanges. The proposal could then include Oakley as the key exchange > mechanism along with the specific Oakley group that should be used. > Thoughts on this?? > > I completely agree. I also think the ISAKMP proposal fits the Oakley requirements. Actually the way I am implementing ISAKMP/Oakley currently uses the ISAKMP proposal with the Oakley KEI. I made this decision since the payload formats in the current Oakley draft don't match the current ISAKMP draft(In the hope that my implementation will be close to the final standard). Oliver -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBMg9j8znVPgUZ7uZJAQGxLwQAsnhP2jH8YS/ASD6daaxui9/lIWCkUbiJ BSSyz/L2AJNfWa/K4xNVXn40CTs8orCsnGKqUwTwPZIBRciAZBanzn7YHOZ5b4Km m5752x3ch1rOPYsjHHwi8xnOfSd0GyYTpAK61xwnCld2bx3oCLr9e++9C1PyfB0l xV2G23Pg5Rk= =UslG -----END PGP SIGNATURE----- Received: from relay.hq.tis.com by neptune.TIS.COM id aa16453; 12 Aug 96 19:02 EDT Received: by relay.hq.tis.com; id TAA03134; Mon, 12 Aug 1996 19:05:08 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma003127; Mon, 12 Aug 96 19:04:39 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA11477; Mon, 12 Aug 96 19:04:03 EDT Received: by relay.hq.tis.com; id TAA03121; Mon, 12 Aug 1996 19:04:38 -0400 Received: from zafu.bbn.com(128.89.0.25) by relay.tis.com via smap (V3.1.1) id xma003118; Mon, 12 Aug 96 19:04:11 -0400 Received: from [128.89.0.110] (COMSEC.BBN.COM [128.89.0.110]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id TAA23036; Mon, 12 Aug 1996 19:11:18 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: <v02130509ae356852519e@[128.89.0.110]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 12 Aug 1996 19:07:30 -0400 To: Marcel Waldvogel <mwa@tik.ee.ethz.ch> From: Stephen Kent <kent@bbn.com> Subject: Re: I-D ACTION:draft-thayer-seccomp-00.txt Cc: Naganand Doraswamy <naganand@ftp.com>, ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Marcel, Our plans for re-writing the ESP and AH specs will avoid the need to document the combinatorial set of transforms. Instead, it will be possible to define the algorithms or transform elements via distinct RFCs. The ESP and AH specs will be upgraded to define formats for all of the optional fields required by the different transforms. None of this avoids the complexity that comes with implementing various subsets of the transforms. However, moving transforms into separate protocols arguably does not avoid this complexity either. At the last meeting we also decided to address this problem, in part, by registering allowed combinations of transforms through the IANA (after WG approval), as a means of identifying allowed combinations. Still, the WG needs to evaluate the attractiveness of various combinations and pass judgement on them; that is the ultimate means of keeping the complexity level manageable. Steve Received: from relay.hq.tis.com by neptune.TIS.COM id aa24428; 13 Aug 96 10:52 EDT Received: by relay.hq.tis.com; id KAA13011; Tue, 13 Aug 1996 10:55:30 -0400 From: pau@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma013004; Tue, 13 Aug 96 10:55:10 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA02814; Tue, 13 Aug 96 10:54:28 EDT Received: by relay.hq.tis.com; id KAA12984; Tue, 13 Aug 1996 10:54:54 -0400 Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1.1) id xma012979; Tue, 13 Aug 96 10:54:46 -0400 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id KAA08755; Tue, 13 Aug 1996 10:56:21 -0400 Received: from secpwr.watson.ibm.com (secpwr.watson.ibm.com [9.2.24.17]) by mailhub1.watson.ibm.com (8.7.1/08-11-96) with SMTP id KAA61845; Tue, 13 Aug 1996 10:55:44 -0400 Received: by secpwr.watson.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA22570; Tue, 13 Aug 1996 10:55:48 -0400 Date: Tue, 13 Aug 1996 10:55:48 -0400 Message-Id: <9608131455.AA22570@secpwr.watson.ibm.com> To: mss@tycho.ncsc.mil Subject: Re: Comments on ISAKMP/Oakley Cc: ipsec@TIS.COM, mss@tycho.ncsc.mil, wdm@tycho.ncsc.mil, sjt@tycho.ncsc.mil, mjs@terisa.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Md5: YxdKgByZ+/O/xjsdiqeYrQ== Sender: ipsec-approval@neptune.tis.com Precedence: bulk > From ipsec-request@neptune.hq.tis.com Mon Aug 12 10:46:16 1996 > Date: Mon, 12 Aug 96 07:39:40 EDT > From: "Mark S. Schneider" <mss@tycho.ncsc.mil> > Message-Id: <9608121139.AA07014@tarius.tycho.ncsc.mil> > To: naganand@ftp.com > Subject: Re: Comments on ISAKMP/Oakley > Cc: ipsec@TIS.COM, mss@tycho.ncsc.mil, wdm@tycho.ncsc.mil, = sjt@tycho.ncsc.mil, mjs@terisa.com > Sender: ipsec-approval@neptune.hq.tis.com > Precedence: bulk > Content-Length: 5367 > Status: RO ......... . >=20 > >=20 > > A.6.1. Attribute Value Assigned Numbers, IPSEC ESP > > TLV constructs: how long is "Type"? How long is "Length"? Is = "Length" > > in terms of octets, or some other unit? Are the lengths of = "Type" and > > "Length" included in "Length" or not? >=20 > 1 2 3 > TLV =3D 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 = 0 1 > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Tag/Type ! Length = = ! > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ Value/Data = = ~ > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Where Length is the length of the Value/Data *only* in the TLV. Mark, are the values of "tag" and their associate data defined any where = ? ........................ >=20 > > Where are ISAKMP exchange numbers defined for the various Oakley = modes? >=20 > They currently aren't defined in the ISAKMP draft. In the next = version, > I assume they will be assigned exchange numbers 4-7. >=20 > > What happens to the Base, Identity Protection, and Authentication = Only > > exchanges defined in the ISAKMP draft? How does one implemement the = other > > exchanges (which are defined as MUSTs in the ISAKMP draft) if Oakley = is > > the only supported key exchange and is there any need to implement = the basic > > ISAKMP modes if one is supporting only key exchange for IPSEC? >=20 >=20 > We see ISAKMP as a framework that permits negotiation of many = security > features, including the key exchange mechanism. The exchange types > defined by the ISAKMP/Oakley resolution draft all have a defined key > exchange. In this case the key exchange is not negotiable. To = support > negotiation of key exchange mechanisms, the three exchange types = defined > in ISAKMP are *required*. If they didn't exist, then it would be =20 > impossible to negotiatiate key exchange mechanisms. >=20 > Actually, upon looking closer at the ISAKMP exchanges and Oakley = exchanges, > a generalization of the Oakley modes can be made in the ISAKMP = draft. Since, > as you note below, Oakley Main Mode is equivalent to ISAKMP's ID = Protect > exchange, then it seems that Oakley Aggressive, Quick, and New Group > modes (maybe) can be generalized to ISAKMP Aggressive, Quick, and SA = Only = ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > exchanges. The proposal could then include Oakley as the key = exchange > mechanism along with the specific Oakley group that should be used.=20 > Thoughts on this?? Mark, I am confused by your answer. If Key Exchange Protocol is meant = to be nogotiated (which I think is a good idea), why not put Oakley in = the proposal part of a ISAKMP base exchange ? I mean, is there a need to=20 define exhcnage numbers for Oakley ? There are only twelve unused = values for the 4-bit "exchane" field. I think the values should be reserved = for some very different flows of messages. =20 Also, I don't see draft 5 mentioning ISAKMP Aggressive, Quick, and SA = Only exchanges. Am I missing something ? >=20 ..................... >=20 >=20 > Regards, > Mark Schneider >=20 =20 Thank you. Regards, Pau-Chen Received: from relay.hq.tis.com by neptune.TIS.COM id aa27579; 13 Aug 96 15:29 EDT Received: by relay.hq.tis.com; id PAA23692; Tue, 13 Aug 1996 15:32:26 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma023683; Tue, 13 Aug 96 15:32:03 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA19466; Tue, 13 Aug 96 15:31:23 EDT Received: by relay.hq.tis.com; id PAA23671; Tue, 13 Aug 1996 15:31:57 -0400 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1.1) id xma023662; Tue, 13 Aug 96 15:31:41 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.12/8.6.5) id MAA11630 for ipsec@tis.com; Tue, 13 Aug 1996 12:33:57 -0700 Message-Id: <199608131933.MAA11630@puli.cisco.com> From: Ran Atkinson <rja@cisco.com> Date: Tue, 13 Aug 1996 12:33:56 PDT X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipsec@TIS.COM Subject: PF_KEY paper Sender: ipsec-approval@neptune.tis.com Precedence: bulk The PF_KEY paper by Dan McDonald that was presented at INET'96 in Montreal last June is available online in Postscript from: http://tonnant.itd.nrl.navy.mil/PF_KEY.ps The NRL IPsec software for BSD is an example of an implementation of PF_KEY. I hope to see a PF_KEY I-D appear online in the near future. I believe there is an effort underway to create such an I-D based on both the NRL PF_KEY API and also on the similar PF_SADB API of the NIST/NCSC IPsec code. Ran rja@inet.org -- Received: from relay.hq.tis.com by neptune.TIS.COM id aa28686; 13 Aug 96 16:59 EDT Received: by relay.hq.tis.com; id RAA27695; Tue, 13 Aug 1996 17:02:57 -0400 From: pau@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma027692; Tue, 13 Aug 96 17:02:36 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA27944; Tue, 13 Aug 96 17:01:53 EDT Received: by relay.hq.tis.com; id RAA27689; Tue, 13 Aug 1996 17:02:27 -0400 Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1.1) id xma027687; Tue, 13 Aug 96 17:02:18 -0400 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id RAA20601; Tue, 13 Aug 1996 17:05:08 -0400 Received: from secpwr.watson.ibm.com (secpwr.watson.ibm.com [9.2.24.17]) by mailhub1.watson.ibm.com (8.7.1/08-13-96) with SMTP id RAA121205; Tue, 13 Aug 1996 17:04:30 -0400 Received: by secpwr.watson.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA22698; Tue, 13 Aug 1996 17:04:30 -0400 Date: Tue, 13 Aug 1996 17:04:30 -0400 Message-Id: <9608132104.AA22698@secpwr.watson.ibm.com> Subject: Re: Comments on ISAKMP/Oakley To: mss@tycho.ncsc.mil Cc: ipsec@TIS.COM, mjs@terisa.com, mss@tycho.ncsc.mil, wdm@tycho.ncsc.mil, sjt@tycho.ncsc.mil Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Md5: rpLAtYeX9q3nfYV6oLCHag== Sender: ipsec-approval@neptune.tis.com Precedence: bulk > Subject: Re: Comments on ISAKMP/Oakley > Cc: ipsec@TIS.COM, mss@tycho.ncsc.mil, wdm@tycho.ncsc.mil, = sjt@tycho.ncsc.mil, mjs@terisa.com > Sender: ipsec-approval@neptune.hq.tis.com > Precedence: bulk > Content-Length: 5367 > Status: RO ......... . >=20 > >=20 > > A.6.1. Attribute Value Assigned Numbers, IPSEC ESP > > TLV constructs: how long is "Type"? How long is "Length"? Is = "Length" > > in terms of octets, or some other unit? Are the lengths of = "Type" and > > "Length" included in "Length" or not? >=20 > 1 2 3 > TLV =3D 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 = 0 1 > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Tag/Type ! Length = = ! > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ Value/Data = = ~ > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Where Length is the length of the Value/Data *only* in the TLV. Mark, are the values of "tag" and their associate data defined any where = ? ........................ >=20 > > Where are ISAKMP exchange numbers defined for the various Oakley = modes? >=20 > They currently aren't defined in the ISAKMP draft. In the next = version, > I assume they will be assigned exchange numbers 4-7. >=20 > > What happens to the Base, Identity Protection, and Authentication = Only > > exchanges defined in the ISAKMP draft? How does one implemement the = other > > exchanges (which are defined as MUSTs in the ISAKMP draft) if Oakley = is > > the only supported key exchange and is there any need to implement = the basic > > ISAKMP modes if one is supporting only key exchange for IPSEC? >=20 >=20 > We see ISAKMP as a framework that permits negotiation of many = security > features, including the key exchange mechanism. The exchange types > defined by the ISAKMP/Oakley resolution draft all have a defined key > exchange. In this case the key exchange is not negotiable. To = support > negotiation of key exchange mechanisms, the three exchange types = defined > in ISAKMP are *required*. If they didn't exist, then it would be =20 > impossible to negotiatiate key exchange mechanisms. >=20 > Actually, upon looking closer at the ISAKMP exchanges and Oakley = exchanges, > a generalization of the Oakley modes can be made in the ISAKMP = draft. Since, > as you note below, Oakley Main Mode is equivalent to ISAKMP's ID = Protect > exchange, then it seems that Oakley Aggressive, Quick, and New Group > modes (maybe) can be generalized to ISAKMP Aggressive, Quick, and SA = Only = ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > exchanges. The proposal could then include Oakley as the key = exchange > mechanism along with the specific Oakley group that should be used.=20 > Thoughts on this?? Mark, I am confused by your answer. If Key Exchange Protocol is meant = to be nogotiated (which I think is a good idea), why not put Oakley in = the proposal part of a ISAKMP base exchange ? I mean, is there a need to=20 define exhcnage numbers for Oakley ? There are only twelve unused = values for the 4-bit "exchane" field. I think the values should be reserved = for some very different flows of messages. =20 Also, I don't see draft 5 mentioning ISAKMP Aggressive, Quick, and SA = Only exchanges. Am I missing something ? >=20 ..................... >=20 >=20 > Regards, > Mark Schneider >=20 =20 Thank you. Regards, Pau-Chen=20 ------------- End Forwarded Message ------------- Received: from relay.hq.tis.com by neptune.TIS.COM id aa01348; 13 Aug 96 21:28 EDT Received: by relay.hq.tis.com; id VAA02319; Tue, 13 Aug 1996 21:31:33 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma002312; Tue, 13 Aug 96 21:31:14 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA05740; Tue, 13 Aug 96 21:30:28 EDT Received: by relay.hq.tis.com; id VAA02304; Tue, 13 Aug 1996 21:31:04 -0400 Received: from inet-user-gw-1.us.oracle.com(192.86.155.82) by relay.tis.com via smap (V3.1.1) id xma002296; Tue, 13 Aug 96 21:30:37 -0400 Received: from mailsun2.us.oracle.com by inet-user-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id SAA06194; Tue, 13 Aug 1996 18:32:17 -0700 Received: by mailsun2.us.oracle.com (SMI-8.6/37.8) id SAA15815; Tue, 13 Aug 1996 18:30:13 -0700 Message-Id: <199608140130.SAA15815@mailsun2.us.oracle.com> Date: 13 Aug 96 18:24:13 -0700 From: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com> To: ipsec@TIS.COM Subject: Re: "Re: DNS? was Re: Key Management, anyone?" X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-approval@neptune.hq.tis.com's message of 07-Aug-96 23:03 Mime-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.0.2.0.35) Content-Type: multipart/mixed; boundary="=_ORCL_6501180_0_11919608131931140" Sender: ipsec-approval@neptune.tis.com Precedence: bulk --=_ORCL_6501180_0_11919608131931140 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" Hilarie, On you assertion: >Clarified Assertion: >The minimal basis for authentication is the association >of a public key with an IP address. The minimal >authentication chain is through DNS zone authorities. I have always viewed the minimum information to be a "name"... Perhaps I'm wrong, but your assertion provides clarity to the discussions and this an issue that needs resolution. So ... A Different Assertion: The minimal basis for authentication is the association of a public key with a name that can be used to support access control decisions. IP addresses may be dynamically assigned and are not as useful as "names" in supporting end system security. Paul -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com -------------------------------------------------------------- --=_ORCL_6501180_0_11919608131931140 Content-Type:message/rfc822 Date: 07 Aug 96 23:03:02 From:"Hilarie Orman " <ipsec-approval@neptune.hq.tis.com> To:mohta@necom830.hpcl.titech.ac.jp Subject:Re: "Re: DNS? was Re: Key Management, anyone?" Cc:ipsec@tis.com X-Orcl-Application:Mmdf-Warning: Unable to confirm address in preceding line at neptune.TIS.COM X-Orcl-Application:In-Reply-To: Yourmessage <199608050227.TAA06242@baskerville.CS.Arizona.EDU> X-Orcl-Application:Sender: ipsec-approval@neptune.hq.tis.com X-Orcl-Application:Precedence: bulk MIME-Version: 1.0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" > Authentication for what? Clarified Assertion: The minimal basis for authentication is the association of a public key with an IP address. The minimal authentication chain is through DNS zone authorities. This seems to me to be generally useful and meaningful mechanism for most Internet purposes. If a site doesn't have an appropriate key entry, it won't be able participate in ordinary authenticated services --- sort of like not having a valid IP address would invalidate it as an Internet member. So, why is this wrong? --=_ORCL_6501180_0_11919608131931140-- Received: from relay.hq.tis.com by neptune.TIS.COM id aa09535; 14 Aug 96 13:29 EDT Received: by relay.hq.tis.com; id NAA24884; Wed, 14 Aug 1996 13:32:32 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma024872; Wed, 14 Aug 96 13:32:03 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA19249; Wed, 14 Aug 96 13:31:25 EDT Received: by relay.hq.tis.com; id NAA24869; Wed, 14 Aug 1996 13:32:02 -0400 Received: from motgate2.mot.com(129.188.136.20) by relay.tis.com via smap (V3.1.1) id xma024850; Wed, 14 Aug 96 13:31:37 -0400 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (8.7.3/8.6.10/MOT-3.8) with ESMTP id RAA25016 for <ipsec@tis.com>; Wed, 14 Aug 1996 17:30:48 GMT Received: from ilbx.mot.com (ilbx.mot.com [129.188.137.185]) by pobox.mot.com (8.7.3/8.6.10/MOT-3.8) with SMTP id MAA23526 for <ipsec@tis.com>; Wed, 14 Aug 1996 12:33:47 -0500 (CDT) Received: by ilbx.mot.com (1.37.109.4/16.2) id AA15812; Wed, 14 Aug 96 12:33:46 -0500 Date: Wed, 14 Aug 1996 11:53:42 -0500 From: David Wheeler-P26179 <David_Wheeler-P26179@email.mot.com> Message-Id: <MSMAIL PC */PRMD=MOT/ADMD=MOT/C=US/@MHS> Subject: Re: "Re: DNS? was Re: Key Management, an To: ipsec@TIS.COM X400-Mts-Identifier: [ /P=MOT/A=MOT/C=US/ ; m\gstmd\960814115342d ] X-Mailer: Worldtalk (4.0.2-p15)/STREAM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Paul Lambert writes: >Hilarie, > >On you assertion: > >>Clarified Assertion: >>The minimal basis for authentication is the association >>of a public key with an IP address. The minimal >>authentication chain is through DNS zone authorities. > >I have always viewed the minimum information to be a "name"... Perhaps I'm >wrong, but your assertion provides clarity to the discussions and this an >issue that needs resolution. So ... > >A Different Assertion: > >The minimal basis for authentication is the association >of a public key with a name that can be used to support access control >decisions. > >IP addresses may be dynamically assigned and are not as useful as "names" in >supporting end system security. I have a problem with this as a basis for authentication also. If I am "dialed-in" through my ISP, and receive a dynamic address, I don't have a DNS entry, hostname, or otherwise. In fact, the only thing I really have is an e- mail address. The question that really needs to be asked is: "What am I authenticating: a person, a machine/host, or a network entrypoint? I can make a case for all three given different security policies, and different security perspectives. The personal authentication is intuitive (but I'll clarify anyway); a particular application only allows named users and specific authenticated users to access it's services (e.g. a library database server only wants John Smith to have access - because he paid his bill - we don't want to allow anyone from joesmidnightisp.com [John's ISP provider] to have access). Host authentication is most common (did I really get to host XYZ.ABC.COM ?). This is the perspective of a client accessing a server. Can I be sure that the newest beta version of Netscape I just downloaded is from the Netscape server? Network entrypoint authentication is the opposite perspective. The host wants authentication of the origin of access. It is common to restrict a host to be accessed from only certain locations - we do this all the time with network management using various techniques (called-back using modems etc.) What about the network manager that wants full access from home through his/ her ISP to correct network problems at 2 AM? We surely want VERY strong authentication that this is really the network manager and not Bobby Hacker. I don't have a really good a solution - I need to think about it some more. Regardless, all types of authentication will be important, and neither IP address nor hostname covers all three. Maybe the best thing to do is say all three types of authentication will be handled by different certificates. Is it sufficient to say that authentication is based on an e-mail address (personal), hostname, OR an IP address (network entrypoint)? Then the application/service which is accepting the authenticated identity must determine if this binding is sufficient authentication for the particular activity/access/application? Then the minimal basis for authentication is the association of a public key with an e-mail address, a hostname, or an IP address that can be used to support access control decisions. Comments? Dave Wheeler Information Security Operations Space and Systems Technology Group, Motorola Scottsdale, Arizona Received: from relay.hq.tis.com by neptune.TIS.COM id aa13261; 14 Aug 96 19:51 EDT Received: by relay.hq.tis.com; id TAA07032; Wed, 14 Aug 1996 19:54:23 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma007022; Wed, 14 Aug 96 19:53:56 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA09882; Wed, 14 Aug 96 19:53:18 EDT Received: by relay.hq.tis.com; id TAA07010; Wed, 14 Aug 1996 19:53:54 -0400 Received: from toad.com(140.174.2.1) by relay.tis.com via smap (V3.1.1) id xma007001; Wed, 14 Aug 96 19:53:41 -0400 Received: from localhost (localhost [127.0.0.1]) by toad.com (8.7.5/8.7.3) with SMTP id QAA08155; Wed, 14 Aug 1996 16:56:00 -0700 (PDT) Message-Id: <199608142356.QAA08155@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: ipsec@TIS.COM, gnu@toad.com Subject: Re: DNS? was Key Management Date: Wed, 14 Aug 1996 16:55:59 -0700 From: John Gilmore <gnu@toad.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk One of the problems that has hung up all sorts of crypto protocols is getting confused about what problem you are trying to solve. Like PEM, let's not define all the packet formats and then spend three years arguing over who authenticates what to who. > Then the minimal basis for authentication is the association of a public key > with an e-mail address, a hostname, or an IP address that can be used to > support access control decisions. DNSSEC supports associating a public key (or several public keys) with each of the above. IP addresses are encoded into the domain-name space in the usual 1.2.174.140.in-addr.arpa way. Email addresses are encoded as e.g. gnu.toad.com by setting a bit in the KEY record which indicates that the first component refers to a user rather than to a host or subdomain. However, IPSEC only authenticates to IP addresses. There's no further identification in the IPSEC packets. Even if usernames or hostnames are used in generating keys, there's no well-defined way to get that information back to an application; all it has is getpeername(). > Is it sufficient to say that authentication is based on an e-mail address > (personal), hostname, OR an IP address (network entrypoint)? Then the > application/service which is accepting the authenticated identity must > determine if this binding is sufficient authentication for the particular > activity/access/application? I believe you meant "sufficient authorization". IPSEC and DNSEEC do not solve this second problem (applications deciding whether to accept authenticated identities). That's an access control question (is he allowed?) as opposed to an identity question (who is he?). IPSEC doesn't solve the global "single signon" problem; don't expect it to. I may supply information to authenticate myself to other parts of the network, and a firewall somewhere may use this information to decide whether to let my packets in the door. But IPSEC running at FOO.COM should be willing to build an encrypted tunnel to my laptop, whether or not my laptop later ends up authenticated as "the laptop that FOO.COM's system administrator borrowed while he was at a conference". I also think we should focus on shipping standards that hit the sweet spot (most gain for least pain), which includes securing communications among all the hosts with fixed IP addresses. If dynamically assigned IP addresses are easy, throw 'em in; if not, leave them for the next round of standards. Since everyone seems to think they're hard, let's leave them for next time, and secure the large fraction of the Internet that we know how to do now. John Gilmore Received: from relay.hq.tis.com by neptune.TIS.COM id aa14036; 14 Aug 96 21:29 EDT Received: by relay.hq.tis.com; id VAA08293; Wed, 14 Aug 1996 21:32:53 -0400 From: wobber@pa.dec.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma008291; Wed, 14 Aug 96 21:32:25 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA12014; Wed, 14 Aug 96 21:31:47 EDT Received: by relay.hq.tis.com; id VAA08286; Wed, 14 Aug 1996 21:32:24 -0400 Received: from mail2.digital.com(204.123.2.56) by relay.tis.com via smap (V3.1.1) id xma008282; Wed, 14 Aug 96 21:32:05 -0400 Received: from hickory.pa.dec.com by mail2.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA17448; Wed, 14 Aug 1996 18:27:12 -0700 Received: by hickory.pa.dec.com; id AA15906; Wed, 14 Aug 1996 18:27:07 -0700 Message-Id: <9608150127.AA15906@hickory.pa.dec.com> To: John Gilmore <gnu@toad.com> Cc: ipsec@TIS.COM Subject: Re: DNS? was Key Management In-Reply-To: Message of Wed, 14 Aug 1996 16:55:59 -0700 from John Gilmore <gnu@toad.com> <199608142356.QAA08155@toad.com> Date: Wed, 14 Aug 96 18:27:07 -0700 X-Mts: smtp Sender: ipsec-approval@neptune.tis.com Precedence: bulk >> However, IPSEC only authenticates to IP addresses. There's no further >> identification in the IPSEC packets. Even if usernames or hostnames >> are used in generating keys, there's no well-defined way to get that >> information back to an application; all it has is getpeername(). Isn't it the case that IPSEC packets are bound to security associations, and that security associations are sufficient to identify all sorts of communicating entities (not just IP addresses)? If so, then the proposed protocols should support authentication within multiple namespaces/trust domains. The problem is how to standardize an appropriate API for managing the security associations appurtenant to communications channels. While I agree that authentication of fixed IP addresses probably constitutes a "sweet spot", it would be unfortunate if this ruled out other forms of authentication appropriate to security-aware applications. Regards, Ted Wobber DEC Systems Research Center Received: from relay.hq.tis.com by neptune.TIS.COM id aa19411; 15 Aug 96 9:18 EDT Received: by relay.hq.tis.com; id JAA20399; Thu, 15 Aug 1996 09:21:23 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma020397; Thu, 15 Aug 96 09:20:56 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA01579; Thu, 15 Aug 96 09:20:17 EDT Received: by relay.hq.tis.com; id JAA20388; Thu, 15 Aug 1996 09:20:54 -0400 Received: from ietf.org(132.151.1.19) by relay.tis.com via smap (V3.1.1) id xma020375; Thu, 15 Aug 96 09:20:33 -0400 Received: from localhost by ietf.org id aa01666; 15 Aug 96 9:16 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: ipsec@TIS.COM From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-skip-07.txt Date: Thu, 15 Aug 1996 09:16:15 -0400 Message-Id: <9608150916.aa01666@ietf.org> Sender: ipsec-approval@neptune.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Simple Key-Management For Internet Protocols (SKIP) Author(s) : A. Aziz, T. Markson, H. Prafullchandra Filename : draft-ietf-ipsec-skip-07.txt Pages : 34 Date : 08/14/1996 There are occasions where it is advantageous to put authenticity and privacy features at the network layer. The vast majority of the privacy and authentication protocols in the literature deal with session oriented key-management schemes. However, many of the commonly used network layer protocols (for example, IPv4 and IPv6) are session-less datagram oriented protocols. We describe a key-management scheme that is particularly well suited for use in conjunction with a session-less datagram protocol like IPv4 or IPv6. SKIP has been designed to work with the IP Security Protocols AH and ESP [8, 9, 10] which are specified for both IPv4 and IPv6. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-skip-07.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-07.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 (193.205.245.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-ietf-ipsec-skip-07.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@ietf.org 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: <19960814144020.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-skip-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-skip-07.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960814144020.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from relay.hq.tis.com by neptune.TIS.COM id aa20437; 15 Aug 96 10:59 EDT Received: by relay.hq.tis.com; id LAA23812; Thu, 15 Aug 1996 11:02:53 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma023788; Thu, 15 Aug 96 11:02:25 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA07120; Thu, 15 Aug 96 11:01:44 EDT Received: by relay.hq.tis.com; id LAA23777; Thu, 15 Aug 1996 11:02:21 -0400 Received: from ns.border.com(199.71.190.98) by relay.tis.com via smap (V3.1.1) id xma023768; Thu, 15 Aug 96 11:02:10 -0400 Received: by janus.border.com id <18446-1>; Thu, 15 Aug 1996 11:04:05 -0400 Message-Id: <96Aug15.110405edt.18446-1@janus.border.com> To: John Gilmore <gnu@toad.com> Cc: ipsec@TIS.COM Subject: Re: DNS? was Key Management References: <199608142356.QAA08155@toad.com> In-Reply-To: Your message of "Wed, 14 Aug 1996 19:55:59 -0400". <199608142356.QAA08155@toad.com> From: "C. Harald Koch" <chk@border.com> Date: Thu, 15 Aug 1996 11:04:12 -0400 Sender: ipsec-approval@neptune.tis.com Precedence: bulk In message <199608142356.QAA08155@toad.com>, John Gilmore writes: > > However, IPSEC only authenticates to IP addresses. There's no further > identification in the IPSEC packets. Even if usernames or hostnames > are used in generating keys, there's no well-defined way to get that > information back to an application; all it has is getpeername(). Since when? It was my understanding that IPsec authenticated to the nebulous concept of a "key owner", which could be a single user, a host, or even a set of hosts (say, behind a crypto-gateway?). As for authorization, the most common use I see for IPsec, in the short term, is to secure 'standard' A&A techniques (such as OTP, challenge response cards, etc.) from network-layer based attacks. After all, if I can trust that a TCP session has not been tampered with, then I can make stronger trust decisions about OTP or token based authentication of the user at the end of the tunnel, right? -- Harald Koch chk@border.com Received: from relay.hq.tis.com by neptune.TIS.COM id aa20808; 15 Aug 96 11:27 EDT Received: by relay.hq.tis.com; id LAA24610; Thu, 15 Aug 1996 11:30:51 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma024601; Thu, 15 Aug 96 11:30:26 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA08690; Thu, 15 Aug 96 11:29:46 EDT Received: by relay.hq.tis.com; id LAA24596; Thu, 15 Aug 1996 11:30:21 -0400 Received: from dg-webo.us.dg.com(128.221.131.1) by relay.tis.com via smap (V3.1.1) id xma024590; Thu, 15 Aug 96 11:30:07 -0400 Received: from wellspring by dg-webo.webo.dg.com (5.4R3.10/dg-webo-v1) id AA24618; Thu, 15 Aug 1996 11:31:23 -0400 Received: from ferguson by wellspring.us.dg.com (5.4R3.10/dg-gens08) id AA17325; Thu, 15 Aug 1996 11:31:22 -0400 Message-Id: <9608151531.AA17325@wellspring.us.dg.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 Aug 1996 11:31:03 -0400 To: ipsec@TIS.COM From: Rodney Thayer <rodney@sabletech.com> Subject: ...draft ...*skip*... Sender: ipsec-approval@neptune.tis.com Precedence: bulk Excuse me but what's the status of the "what key management scheme are we agreeing upon" process? If SKIP is it than this is nice. IF SKIP isn't it then what is this? (I mean, it's a free internet but that would mean the filename didn't start with "draft-ietf-...") Attention SKIP people: this message is *not* meant in any way to be derogatory towards SKIP, I'm just confused and your email was in my hand when I decided it was time to say something. >To: IETF-Announce:;, tis.com@TIS.COM >MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM >Cc: ipsec@TIS.COM >From: Internet-Drafts@ietf.org >Reply-To: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-ietf-ipsec-skip-07.txt >Date: Thu, 15 Aug 1996 09:16:15 -0400 >Sender: ipsec-approval@neptune.hq.tis.com > >A Revised Internet-Draft is available from the on-line Internet-Drafts >directories. This draft is a work item of the IP Security Protocol Working >Group of the IETF. > > Title : Simple Key-Management For Internet Protocols (SKIP) > Author(s) : A. Aziz, T. Markson, H. Prafullchandra > Filename : draft-ietf-ipsec-skip-07.txt > Pages : 34 > Date : 08/14/1996 > >There are occasions where it is advantageous to put authenticity and >privacy features at the network layer. The vast majority of the privacy and >authentication protocols in the literature deal with session oriented >key-management schemes. However, many of the commonly used network layer >protocols (for example, IPv4 and IPv6) are session-less datagram oriented >protocols. We describe a key-management scheme that is particularly well >suited for use in conjunction with a session-less datagram protocol like >IPv4 or IPv6. > >SKIP has been designed to work with the IP Security Protocols AH and ESP >[8, 9, 10] which are specified for both IPv4 and IPv6. > >Internet-Drafts are available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-ipsec-skip-07.txt". >A URL for the Internet-Draft is: >ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-07.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 (193.205.245.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-ietf-ipsec-skip-07.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@ietf.org > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version >of the Internet-Draft. >Content-Type: text/plain >Content-ID: <19960814144020.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-ipsec-skip-07.txt >Content-Type: text/plain >Content-ID: <19960814144020.I-D@ietf.org> > Rodney Thayer <rodney@sabletech.com> +1 617 332 7292 Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA Fax: +1 617 332 7970 http://www.shore.net/~sable "Developers of communications software" Received: from relay.hq.tis.com by neptune.TIS.COM id aa21547; 15 Aug 96 12:18 EDT Received: by relay.hq.tis.com; id MAA26512; Thu, 15 Aug 1996 12:21:43 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma026498; Thu, 15 Aug 96 12:21:15 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA12476; Thu, 15 Aug 96 12:20:36 EDT Received: by relay.hq.tis.com; id MAA26491; Thu, 15 Aug 1996 12:21:13 -0400 Received: from ftp.com(128.127.2.122) by relay.tis.com via smap (V3.1.1) id xma026484; Thu, 15 Aug 96 12:21:10 -0400 Received: from ftp.com by ftp.com ; Thu, 15 Aug 1996 12:23:23 -0400 Received: from athena.ftp.com by ftp.com ; Thu, 15 Aug 1996 12:23:23 -0400 Message-Id: <2.2.32.19960815162824.00ae9794@mailserv-H.ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 Aug 1996 12:28:24 -0400 To: "Mark S. Schneider" <mss@tycho.ncsc.mil> From: Naganand Doraswamy <naganand@ftp.com> Subject: Re: Comments on ISAKMP/Oakley Cc: ipsec@TIS.COM, mss@tycho.ncsc.mil, wdm@tycho.ncsc.mil, sjt@tycho.ncsc.mil, mjs@terisa.com Sender: ipsec-approval@neptune.tis.com Precedence: bulk >> >> Where is "Multiple Precision Integer" specified? >> > > It's defined in draft-ietf-ipsec-oakley-01.txt, Appendix D. > For completeness, I suggest that you atleast mention where to look for the definition of multiple precision integer, or just add it in appendix in the draft. >> >> A.7.1 The basic proposal format does has the following fields defined in the >> header: >> - Proposal #, Proposal Len, Protocol # and Attribute TLV's >> However, the ESP, AH, and ISAKMP proposals have defined the >> Transforms ID's and a reserved field. Shouldnt the basic proposal >> format take care of this as well? > > Yes. I guess we intended that the TLV could be used for the Transform > ID. Granted, that would take 8 octets. Are you suggesting adding a > Transform ID field to the Proposal #, Proposal Len, and Protocol # > fields? If so, how do you think this should be done? Reducing the > size of the Protocol # field? Your thoughts are appreciated. >> I think we could reduce the protocol field size to one octet. Almost all the protocols I have seen have only one octet allocated for protocol ID and I feel it is safe to allocate one byte and use the other octet for transform ID, unless other people feel strongly against this. >> A.7.4. Proposal Formats, ISAKMP: ??? >> > >Section A.7.4. is intended to describe the confidentiality and authentication >mechanisms that are internal to ISAKMP and used to provide Phase I security. >Confidentiality will be provided by applying the IPsec ESP transform(s) to >ISAKMP messages. Authentication can also use IPsec AH transforms, only if >keys have been preplaced. This means we have to determine a public key >mechanism for authentication. We're working on this. > > How does one obtain the keys for ESP transform on Phase I ISAKMP messages? Is it an out of band mechanism or are the keys derived based on some public key mechanism? > We see ISAKMP as a framework that permits negotiation of many security > features, including the key exchange mechanism. The exchange types > defined by the ISAKMP/Oakley resolution draft all have a defined key > exchange. In this case the key exchange is not negotiable. To support > negotiation of key exchange mechanisms, the three exchange types defined > in ISAKMP are *required*. If they didn't exist, then it would be > impossible to negotiatiate key exchange mechanisms. > > Actually, upon looking closer at the ISAKMP exchanges and Oakley exchanges, > a generalization of the Oakley modes can be made in the ISAKMP draft. Since, > as you note below, Oakley Main Mode is equivalent to ISAKMP's ID Protect > exchange, then it seems that Oakley Aggressive, Quick, and New Group > modes (maybe) can be generalized to ISAKMP Aggressive, Quick, and SA Only > exchanges. The proposal could then include Oakley as the key exchange > mechanism along with the specific Oakley group that should be used. > Thoughts on this?? > > This will help a lot as the number of protocol formats one needs to implement will be fewer. Also, as ISAKMP is a general mechanism, as it is already doing, there should be more protocol exhance modes defined so that it can support various key exchange mechanisms. That is the reason why I like the idea of trying to fit Oakley key exchange mechanisms within the available ISAKMP modes rahter than defining new modes for the basic modes. This way we a new key exchange mechanism is added we dont end up adding another "n" xchg types to the ISAKMP headers and we may soon run out of these 4 bits! I have a few questions on Modify payload. - How does one send a Modify payload. Do I use the reserved XCHG to send this message? Is so, dont I need some kind of verfication? The same argument is true even for the Delete payload. - When I send a modify message do I create a new SPI or modify the attributes of the existing SA? For example, say between two machines A and B I have an SA established. On A I want B to use a different transform, then I will send a Modify message to B with the SPI B was using to send secure messages to A in the SPI field of the Modify payload. In addition to that I will also send a SA payload. Does the auxillary SPI field in the SA payload point to a new SPI or can I reuse the old one? If I reuse the old one, how will I handle the packets that are sent from B to A in the window where the Modify message that A sent has still not reached B and A has already modify it's SA? --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) Received: from relay.hq.tis.com by neptune.TIS.COM id aa21795; 15 Aug 96 12:35 EDT Received: by relay.hq.tis.com; id MAA26982; Thu, 15 Aug 1996 12:38:13 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma026966; Thu, 15 Aug 96 12:37:50 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA14268; Thu, 15 Aug 96 12:37:11 EDT Received: by relay.hq.tis.com; id MAA26952; Thu, 15 Aug 1996 12:37:46 -0400 Received: from raptor.com(204.7.243.11) by relay.tis.com via smap (V3.1.1) id xma026937; Thu, 15 Aug 96 12:37:23 -0400 Received: from raptor1.raptor.com ([204.7.242.10]) by eagle1.raptor.com via smtpd (for relay.hq.tis.com [192.94.214.100]) with SMTP; 15 Aug 1996 16:39:22 UT Received: from Joe_Tardo.raptor.com (pool030.Max20.San-Francisco.CA.DYNIP.ALTER.NET [153.37.20.94]) by raptor1.raptor.com (8.7.3/8.7.3) with SMTP id MAA19969; Thu, 15 Aug 1996 12:38:54 -0400 (EDT) Message-Id: <2.2.32.19960815163912.006f75f4@204.7.242.10> X-Sender: jtardo@204.7.242.10 X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 Aug 1996 09:39:12 -0700 To: John Gilmore <gnu@toad.com> From: Joe Tardo <tardo@raptor.com> Subject: Re: DNS? was Key Management Cc: ipsec@TIS.COM, wobber@pa.dec.com Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 04:55 PM 8/14/96 -0700, John Gilmore wrote: >However, IPSEC only authenticates to IP addresses. There's no further >identification in the IPSEC packets. Even if usernames or hostnames >are used in generating keys, there's no well-defined way to get that >information back to an application; all it has is getpeername(). As Ted points out, IPSEC packets are bound to SA's, and that's where the actual authenticated identity is, not in ESP or AH packets. While true that the ISAKMP Internet DOI as defined in the NSA draft only uses ip addresses and FQDN's for identifiers, these are really needed to identify SA endpoints (hosts and subnetworks), especially for proxy netotiation. They are not necessarily the only means for identifying the authenticated "entity" that will be using that SA. Even if shortcomings such as this in the current draft remained, identities can still be passed in other fields whose semantics have yet to be pinned down (e.g., in certificates). >I may supply information to authenticate myself to other parts of the >network, and a firewall somewhere may use this information to decide >whether to let my packets in the door. But IPSEC running at FOO.COM >should be willing to build an encrypted tunnel to my laptop, whether >or not my laptop later ends up authenticated as "the laptop that >FOO.COM's system administrator borrowed while he was at a conference". I don't follow. Are you advocating that DNSSEC be used even if the best it can do is one-way authentication, since authentication in the other direction is ... somebody else's problem? >I also think we should focus on shipping standards that hit the sweet >spot (most gain for least pain), which includes securing communications >among all the hosts with fixed IP addresses. If dynamically assigned >IP addresses are easy, throw 'em in; if not, leave them for the next >round of standards. Since everyone seems to think they're hard, >let's leave them for next time, and secure the large fraction of >the Internet that we know how to do now. You should qualify "sweet spot" by "in yesterday's internet". This message originated at pool030.Max20.San-Francisco.CA.DYNIP.ALTER.NET and comes to you via an encrypted tunnel to our POP server in Waltham, MA. This is my "sweet spot", hard for DNSSEC to handle maybe, but not rocket science. DNSSEC is *not* a "shipping standard". If you want a shipping standard, I'll point out that X.509 based schemes are currently deployed and becomming more widely so every day (e.g., VeriSign, Netscape, Microsoft, Cybertrust, Sun, Nortel ...). They are used extensively in tls. Why exclude this shipping standard and include one that still experimental, permits only one trust infrastructure, has no developed sense of quality of authentication (read: who takes responsiblilty and liability for for authenticated but bogus domain names), and for which there is no committed schedule for deployment? Put another way, if you want good encryption, why use authentication that doesn't solve enough of the problem? -- Joe = ========================================================= = Joe Tardo Voice: 415-843-0991 Raptor Systems, Inc. 777 San Antonio Ave. Suite 92 Fax: 617-487-6755 Palo Alto, CA. 94303 = ========================================================= = Received: from relay.hq.tis.com by neptune.TIS.COM id aa22042; 15 Aug 96 12:50 EDT Received: by relay.hq.tis.com; id MAA27439; Thu, 15 Aug 1996 12:53:43 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma027414; Thu, 15 Aug 96 12:53:15 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA15916; Thu, 15 Aug 96 12:52:36 EDT Received: by relay.hq.tis.com; id MAA27408; Thu, 15 Aug 1996 12:53:13 -0400 Received: from milkyway.com(198.53.167.2) by relay.tis.com via smap (V3.1.1) id xma027403; Thu, 15 Aug 96 12:53:09 -0400 Received: from jupiter.milkyway.com (jupiter.milkyway.com [192.168.77.9]) by internet with ESMTP (DuhMail/3.0) id MAA01264; Thu, 15 Aug 1996 12:53:45 -0400 Received: from milkyway.com (root@metis.milkyway.com [192.168.77.21]) by jupiter.milkyway.com (8.6.12/8.6.12) with ESMTP id MAA00649; Thu, 15 Aug 1996 12:50:50 -0400 Received: from metis.milkyway.com by milkyway.com (8.6.12/BSDI-Client) id MAA12131; Thu, 15 Aug 1996 12:50:46 -0400 Message-Id: <199608151650.MAA12131@milkyway.com> X-Mailer: exmh version 1.6.7 5/3/96 X-Face: x7OynEM*dB$e.2'7pigelLk>5:Nu:%r*iV96{F2XIT.apbrc-vOFSi{yI$3=nJ-Qi)allj4 =)4cWlX@IQ1Dsmk}T4qX~{XI5Z01>PV^cYR'~cL]&ma<{rYg~Ao-:~:sM%z}^M65`;1TZ}Tze"4/=F ~o&8;"SKHwB?%"xpP/=pkhdZVP$rQQ{"{QT`#kcx7!\/y+crQa4^nLEms6_k4O*o#fo[WBs~~&.%jf |;W@E2K#{U~%vhvth^uDLWD`<OLQ;48T].laq_}3abY7nO5 X-Uri: http://www.milkyway.com/People/Michael_Richardson/Bio.html To: ipsec@TIS.COM Cc: John Gilmore <gnu@toad.com> Subject: Re: DNS? was Key Management References: <199608142356.QAA08155@toad.com> In-Reply-To: Your message of "Wed, 14 Aug 1996 16:55:59 PDT." <199608142356.QAA08155@toad.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Aug 1996 12:50:41 -0400 From: Michael Richardson <mcr@milkyway.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk In a galaxy far, far away, : Wed, 14 Aug 1996 16:55:59 PDT > However, IPSEC only authenticates to IP addresses. There's no further > identification in the IPSEC packets. Even if usernames or hostnames > are used in generating keys, there's no well-defined way to get that > information back to an application; all it has is getpeername(). Well, I'd say that is a limitation of the current APIs, not IPsec itself. > I also think we should focus on shipping standards that hit the sweet > spot (most gain for least pain), which includes securing communications > among all the hosts with fixed IP addresses. If dynamically assigned I agree here. > IP addresses are easy, throw 'em in; if not, leave them for the next > round of standards. Since everyone seems to think they're hard, In that case, you authenticate the user. You do this by having the user generate a certificate saying "Packets from a.b.c.d are from me until <time>" and provide that certificate to the "server" during the key management phase. Received: from relay.hq.tis.com by neptune.TIS.COM id aa21277; 15 Aug 96 11:53 EDT Received: by relay.hq.tis.com; id LAA25690; Thu, 15 Aug 1996 11:56:13 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma025670; Thu, 15 Aug 96 11:55:48 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA11438; Thu, 15 Aug 96 11:55:09 EDT Received: by relay.hq.tis.com; id LAA25662; Thu, 15 Aug 1996 11:55:45 -0400 Received: from pilot.is.chrysler.com(204.189.94.35) by relay.tis.com via Message-ID: <9608151342.aa22819@neptune.TIS.COM> smap (V3.1.1) id xma025630; Thu, 15 Aug 96 11:55:34 -0400 Received: by pilot.firewall.is.chrysler.com; id LAA12853; Thu, 15 Aug 1996 11:56:05 -0400 Received: from mhbclpr2-le0.is.chrysler.com(172.29.128.206) by pilot.is.chrysler.com via smap (g3.0.1) id sma012841; Thu, 15 Aug 96 11:55:56 -0400 Received: from rgm3 (rgm3.is.chrysler.com [129.9.247.160]) by mhbclpr2-nf0.is.chrysler.com (8.7.5/8.7.3) with SMTP id LAA02738; Thu, 15 Aug 1996 11:48:32 -0400 (EDT) Message-Id: <2.2.32.19960815155349.00ca03ac@pop3hub.is.chrysler.com> X-Sender: rgm3@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: Thu, 15 Aug 1996 11:53:49 -0400 To: "Mark S. Schneider" <mss@tycho.ncsc.mil>, naganand@ftp.com From: Robert Moskowitz <rgm3@chrysler.com> Subject: Re: Comments on ISAKMP/Oakley Cc: ipsec@TIS.COM, mss@tycho.ncsc.mil, wdm@tycho.ncsc.mil, sjt@tycho.ncsc.mil, mjs@terisa.com Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 07:39 AM 8/12/96 EDT, Mark S. Schneider wrote: >> From: Naganand Doraswamy <naganand@ftp.com> >> >> These are mostly implemetation type comments: >> >> 2.4.1. Security Association Payload >> Is the "Payload Length" field *really* supposed to be specified in >> four-octet units, or should it be in octets as all the other payloads >> are? >> > > I believe it should be in octets. It seems unlikely that a SA payload > will ever be large enough to require a length in 4-octet units. IPv6 jumbograms????? Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.hq.tis.com by neptune.TIS.COM id aa21225; 15 Aug 96 11:51 EDT Received: by relay.hq.tis.com; id LAA25613; Thu, 15 Aug 1996 11:54:46 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma025600; Thu, 15 Aug 96 11:54:18 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA11377; Thu, 15 Aug 96 11:53:36 EDT Received: by relay.hq.tis.com; id LAA25591; Thu, 15 Aug 1996 11:54:13 -0400 Received: from pilot.is.chrysler.com(204.189.94.35) by relay.tis.com via Message-ID: <9608151406.aa23122@neptune.TIS.COM> smap (V3.1.1) id xma025578; Thu, 15 Aug 96 11:53:52 -0400 Received: by pilot.firewall.is.chrysler.com; id LAA12855; Thu, 15 Aug 1996 11:56:04 -0400 Received: from mhbclpr2-le0.is.chrysler.com(172.29.128.206) by pilot.is.chrysler.com via smap (g3.0.1) id sma012843; Thu, 15 Aug 96 11:55:59 -0400 Received: from rgm3 (rgm3.is.chrysler.com [129.9.247.160]) by mhbclpr2-nf0.is.chrysler.com (8.7.5/8.7.3) with SMTP id LAA02752; Thu, 15 Aug 1996 11:48:35 -0400 (EDT) Message-Id: <2.2.32.19960815155352.00b5f818@pop3hub.is.chrysler.com> X-Sender: rgm3@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: Thu, 15 Aug 1996 11:53:52 -0400 To: John Gilmore <gnu@toad.com>, ipsec@TIS.COM, gnu@toad.com From: Robert Moskowitz <rgm3@chrysler.com> Subject: Re: DNS? was Key Management Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 04:55 PM 8/14/96 -0700, John Gilmore wrote: > >I also think we should focus on shipping standards that hit the sweet >spot (most gain for least pain), which includes securing communications >among all the hosts with fixed IP addresses. If dynamically assigned >IP addresses are easy, throw 'em in; if not, leave them for the next >round of standards. Since everyone seems to think they're hard, >let's leave them for next time, and secure the large fraction of >the Internet that we know how to do now. John, there are about 8,000 productive parts suppliers in the auto industry and 17 oems. Chyrsler has already deployed 5,000 notebooks. I could throw in NADA (dealers) and pick up 10,000 businesses, but then the Ford notebooks will tilt the balance. I think that dynamic addressing exceeds fix addressing unless we deal with split horizon DNS firewall traversal (with NAT thrown in for good measure). Day one, I've got lot more dynamic than I have fixed. And oh, we want to be in pilot 4Q96 :) Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.hq.tis.com by neptune.TIS.COM id aa21277; 15 Aug 96 11:53 EDT Received: by relay.hq.tis.com; id LAA25690; Thu, 15 Aug 1996 11:56:13 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma025670; Thu, 15 Aug 96 11:55:48 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA11438; Thu, 15 Aug 96 11:55:09 EDT Received: by relay.hq.tis.com; id LAA25662; Thu, 15 Aug 1996 11:55:45 -0400 Received: from pilot.is.chrysler.com(204.189.94.35) by relay.tis.com via Message-ID: <9608151408.aa23157@neptune.TIS.COM> smap (V3.1.1) id xma025630; Thu, 15 Aug 96 11:55:34 -0400 Received: by pilot.firewall.is.chrysler.com; id LAA12853; Thu, 15 Aug 1996 11:56:05 -0400 Received: from mhbclpr2-le0.is.chrysler.com(172.29.128.206) by pilot.is.chrysler.com via smap (g3.0.1) id sma012841; Thu, 15 Aug 96 11:55:56 -0400 Received: from rgm3 (rgm3.is.chrysler.com [129.9.247.160]) by mhbclpr2-nf0.is.chrysler.com (8.7.5/8.7.3) with SMTP id LAA02738; Thu, 15 Aug 1996 11:48:32 -0400 (EDT) Message-Id: <2.2.32.19960815155349.00ca03ac@pop3hub.is.chrysler.com> X-Sender: rgm3@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: Thu, 15 Aug 1996 11:53:49 -0400 To: "Mark S. Schneider" <mss@tycho.ncsc.mil>, naganand@ftp.com From: Robert Moskowitz <rgm3@chrysler.com> Subject: Re: Comments on ISAKMP/Oakley Cc: ipsec@TIS.COM, mss@tycho.ncsc.mil, wdm@tycho.ncsc.mil, sjt@tycho.ncsc.mil, mjs@terisa.com Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 07:39 AM 8/12/96 EDT, Mark S. Schneider wrote: >> From: Naganand Doraswamy <naganand@ftp.com> >> >> These are mostly implemetation type comments: >> >> 2.4.1. Security Association Payload >> Is the "Payload Length" field *really* supposed to be specified in >> four-octet units, or should it be in octets as all the other payloads >> are? >> > > I believe it should be in octets. It seems unlikely that a SA payload > will ever be large enough to require a length in 4-octet units. IPv6 jumbograms????? Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.hq.tis.com by neptune.TIS.COM id aa21226; 15 Aug 96 11:51 EDT Received: by relay.hq.tis.com; id LAA25612; Thu, 15 Aug 1996 11:54:46 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma025599; Thu, 15 Aug 96 11:54:15 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA11378; Thu, 15 Aug 96 11:53:36 EDT Received: by relay.hq.tis.com; id LAA25590; Thu, 15 Aug 1996 11:54:13 -0400 Received: from pilot.is.chrysler.com(204.189.94.35) by relay.tis.com via Message-ID: <9608151415.aa23352@neptune.TIS.COM> smap (V3.1.1) id xma025577; Thu, 15 Aug 96 11:53:52 -0400 Received: by pilot.firewall.is.chrysler.com; id LAA12854; Thu, 15 Aug 1996 11:56:04 -0400 Received: from mhbclpr2-le0.is.chrysler.com(172.29.128.206) by pilot.is.chrysler.com via smap (g3.0.1) id sma012842; Thu, 15 Aug 96 11:55:58 -0400 Received: from rgm3 (rgm3.is.chrysler.com [129.9.247.160]) by mhbclpr2-nf0.is.chrysler.com (8.7.5/8.7.3) with SMTP id LAA02750; Thu, 15 Aug 1996 11:48:35 -0400 (EDT) Message-Id: <2.2.32.19960815155352.00978dc0@pop3hub.is.chrysler.com> X-Sender: rgm3@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: Thu, 15 Aug 1996 11:53:52 -0400 To: David Wheeler-P26179 <David_Wheeler-P26179@email.mot.com>, ipsec@TIS.COM From: Robert Moskowitz <rgm3@chrysler.com> Subject: Re: "Re: DNS? was Re: Key Management, an Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 11:53 AM 8/14/96 -0500, David Wheeler-P26179 wrote: > >I have a problem with this as a basis for authentication also. If I am >"dialed-in" through my ISP, and receive a dynamic address, I don't have a DNS >entry, hostname, or otherwise. In fact, the only thing I really have is an e- >mail address. The question that really needs to be asked is: > > "What am I authenticating: > a person, > a machine/host, > or a network entrypoint? > >I can make a case for all three given different security policies, and >different security perspectives. I think I have said this a number of times. The auto industy is starting to move forward with their inter-partner security requirements. All of the above will be used. Also due to different policies and changing software, option negotiation will be very important in a key mananagement protocol. So too will RSVP and multicast support. Of course PFS will be used. ITAR and such might get very interesting. If I redefine VPN as: Privacy via a secure network protocol and Membership via secure key exchange, then the auto industry will have many VPNs working over the same infrastructure. Chyrsler might have the Catia community and Ford the CP3. Frank Nylon Bushing might be connecting their 2 plants and 2 remote sales people. And PACCAR their engine systems with Cat and Allison-Chalmers. Etc. DNSSEC can barely get me started. Only those sites with dedicated connections and then really only for tunnels. The interesting part will require something more, X.509v3 or DSS perhaps? We do have our own agency to handle our registry. Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.hq.tis.com by neptune.TIS.COM id aa24563; 15 Aug 96 15:04 EDT Received: by relay.hq.tis.com; id PAA02451; Thu, 15 Aug 1996 15:06:56 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma002439; Thu, 15 Aug 96 15:06:31 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA24555; Thu, 15 Aug 96 15:05:51 EDT Received: by relay.hq.tis.com; id PAA02432; Thu, 15 Aug 1996 15:06:25 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1) id xma002413; Thu, 15 Aug 96 15:05:41 -0400 Received: from maildig1.us.oracle.com by inet-smtp-gw-1.us.oracle.com with SMTP (8.6.12/37.7) id MAA04135; Thu, 15 Aug 1996 12:07:28 -0700 Received: by maildig1.us.oracle.com (5.65v3.2/37.8) id AA31703; Thu, 15 Aug 1996 12:07:10 -0700 Message-Id: <9608151907.AA31703@maildig1.us.oracle.com> Date: 15 Aug 96 12:04:59 -0700 From: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com> To: ipsec@TIS.COM Subject: Re: DNS? was Key Management Cc: gnu@toad.com X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-request@neptune.hq.tis.com's message of 14-Aug-96 16:55 Mime-Version: 1.0 X-Mailer: Oracle InterOffice (version 2.1.16.0.0) Content-Type: multipart/mixed; boundary="=_ORCL_23644078_0_11919608151308100" Sender: ipsec-approval@neptune.tis.com Precedence: bulk --=_ORCL_23644078_0_11919608151308100 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" John, >However, IPSEC only authenticates to IP addresses. You are wrong. IPsec provides authentication to the "owner" of the security association. This security association may be bound to one or more IP addresses, one or more DNS names, or some other named entity (like a PGP key). The implementations that you choose to field may be limited to provided IP addresses as an authentication "handle". >Even if usernames or hostnames >are used in generating keys, there's no well-defined >way to get that information back to an application; >all it has is getpeername(). Getting the name from a IPsec security association to an application is a "local issue". Some operating systems and application will not be able to support this capability. This should not prevent the access control decisions that are enforced at the network layer from being tied to a useful user oriented identity. For example, consider a dial-in host (with IPsec) connecting throught the internet to a firewall (with IPsec). The IP address for the remote host is not a useful identification mechanism since it changes. A PGP name and key would be much more useful as an entry in a Access Control List (ACL). I am not strongly advocating PGP as a certificate infrastrucuter for IPsec, but am surprized that implementations have not surfaced using this technology. >If dynamically assigned >IP addresses are easy, throw 'em in; if not, >leave them for the next round of standards. Since >everyone seems to think they're hard, let's leave >them for next time, and secure the large fraction of >the Internet that we know how to do now. Everyone? Dynamically assigned IP adresses are not a big problem for IPsec and vendors on this list already have implementions that support this feature. In our rush to field public domain code we should not throw out useful features. Paul -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com !!! Still hiring, send resumes to: palamber@us.oracle.com !!! -------------------------------------------------------------- --=_ORCL_23644078_0_11919608151308100 Content-Type:message/rfc822 Date: 14 Aug 96 16:55:59 From:"John Gilmore <gnu@toad.com>" <ipsec-request@neptune.hq.tis.com> To:ipsec@tis.com,gnu@toad.com Subject:Re: DNS? was Key Management X-Authentication-Warning:toad.com: Host localhost [127.0.0.1] didn't use HELO protocol Sender:ipsec-approval@neptune.hq.tis.com Precedence: bulk MIME-Version: 1.0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" One of the problems that has hung up all sorts of crypto protocols is getting confused about what problem you are trying to solve. Like PEM, let's not define all the packet formats and then spend three years arguing over who authenticates what to who. > Then the minimal basis for authentication is the association of a public key > with an e-mail address, a hostname, or an IP address that can be used to > support access control decisions. DNSSEC supports associating a public key (or several public keys) with each of the above. IP addresses are encoded into the domain-name space in the usual 1.2.174.140.in-addr.arpa way. Email addresses are encoded as e.g. gnu.toad.com by setting a bit in the KEY record which indicates that the first component refers to a user rather than to a host or subdomain. However, IPSEC only authenticates to IP addresses. There's no further identification in the IPSEC packets. Even if usernames or hostnames are used in generating keys, there's no well-defined way to get that information back to an application; all it has is getpeername(). > Is it sufficient to say that authentication is based on an e-mail address > (personal), hostname, OR an IP address (network entrypoint)? Then the > application/service which is accepting the authenticated identity must > determine if this binding is sufficient authentication for the particular > activity/access/application? I believe you meant "sufficient authorization". IPSEC and DNSEEC do not solve this second problem (applications deciding whether to accept authenticated identities). That's an access control question (is he allowed?) as opposed to an identity question (who is he?). IPSEC doesn't solve the global "single signon" problem; don't expect it to. I may supply information to authenticate myself to other parts of the network, and a firewall somewhere may use this information to decide whether to let my packets in the door. But IPSEC running at FOO.COM should be willing to build an encrypted tunnel to my laptop, whether or not my laptop later ends up authenticated as "the laptop that FOO.COM's system administrator borrowed while he was at a conference". I also think we should focus on shipping standards that hit the sweet spot (most gain for least pain), which includes securing communications among all the hosts with fixed IP addresses. If dynamically assigned IP addresses are easy, throw 'em in; if not, leave them for the next round of standards. Since everyone seems to think they're hard, let's leave them for next time, and secure the large fraction of the Internet that we know how to do now. John Gilmore --=_ORCL_23644078_0_11919608151308100-- Received: from ftp.com by neptune.TIS.COM id aa24610; 15 Aug 96 15:05 EDT Received: from ftp.com by ftp.com ; Thu, 15 Aug 1996 15:10:29 -0400 Received: from mailserv-2high.ftp.com by ftp.com ; Thu, 15 Aug 1996 15:10:29 -0400 Received: from fenway.ftp.com by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id PAA05631; Thu, 15 Aug 1996 15:10:17 -0400 Message-Id: <199608151910.PAA05631@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM Priority: Normal To: ipsec@neptune.tis.com X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: Frank T Solensky <solensky@ftp.com> Subject: Re: Comments on ISAKMP/Oakley Date: Thu, 15 Aug 1996 15:07:55 -0400 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: quoted-printable Sender: ipsec-approval@neptune.tis.com Precedence: bulk >>> 2.4.1. Security Association Payload >>> Is the "Payload Length" field *really* supposed to be specified = in >>> four-octet units, or should it be in octets as all the other payloads >>> are? >>> >> I believe it should be in octets. It seems unlikely that a SA payloa= d >> will ever be large enough to require a length in 4-octet units. > >IPv6 jumbograms????? Yep. -- Frank Date: Thu, 15 Aug 1996 11:53:52 -0400 To: John Gilmore <gnu@toad.com>, ipsec@TIS.COM, gnu@toad.com From: Robert Moskowitz <rgm3@chrysler.com> Subject: Re: DNS? was Key Management Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9608151650.aa26859@neptune.TIS.COM> At 04:55 PM 8/14/96 -0700, John Gilmore wrote: > >I also think we should focus on shipping standards that hit the sweet >spot (most gain for least pain), which includes securing communications >among all the hosts with fixed IP addresses. If dynamically assigned >IP addresses are easy, throw 'em in; if not, leave them for the next >round of standards. Since everyone seems to think they're hard, >let's leave them for next time, and secure the large fraction of >the Internet that we know how to do now. John, there are about 8,000 productive parts suppliers in the auto industry and 17 oems. Chyrsler has already deployed 5,000 notebooks. I could throw in NADA (dealers) and pick up 10,000 businesses, but then the Ford notebooks will tilt the balance. I think that dynamic addressing exceeds fix addressing unless we deal with split horizon DNS firewall traversal (with NAT thrown in for good measure). Day one, I've got lot more dynamic than I have fixed. And oh, we want to be in pilot 4Q96 :) Robert Moskowitz Chrysler Corporation (810) 758-8212 -- John C. Kelley System Administrator (301) 854-6889 Trusted Information Systems, Inc. (301) 854-5363 FAX 3060 Washington Road johnk@tis.com (work) Glenwood, MD 21738 johnk@radix.net (play) Date: Thu, 15 Aug 1996 11:53:49 -0400 To: "Mark S. Schneider" <mss@tycho.ncsc.mil>, naganand@ftp.com From: Robert Moskowitz <rgm3@chrysler.com> Subject: Re: Comments on ISAKMP/Oakley Cc: ipsec@TIS.COM, mss@tycho.ncsc.mil, wdm@tycho.ncsc.mil, sjt@tycho.ncsc.mil, mjs@terisa.com Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9608151701.aa27111@neptune.TIS.COM> At 07:39 AM 8/12/96 EDT, Mark S. Schneider wrote: >> From: Naganand Doraswamy <naganand@ftp.com> >> >> These are mostly implemetation type comments: >> >> 2.4.1. Security Association Payload >> Is the "Payload Length" field *really* supposed to be specified in >> four-octet units, or should it be in octets as all the other payloads >> are? >> > > I believe it should be in octets. It seems unlikely that a SA payload > will ever be large enough to require a length in 4-octet units. IPv6 jumbograms????? Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.hq.tis.com by neptune.TIS.COM id aa27172; 15 Aug 96 17:05 EDT Received: by relay.hq.tis.com; id RAA06482; Thu, 15 Aug 1996 17:08:49 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma006474; Thu, 15 Aug 96 17:08:31 -0400 Received: from outland.tis.com (outland.hq.tis.com) by tis.com (4.1/SUN-5.64) id AA03039; Thu, 15 Aug 96 17:07:52 EDT Message-Id: <2.2.32.19960815211420.00732110@pop.tis.com> X-Sender: johnk@pop.tis.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 Aug 1996 17:14:20 -0400 To: ipsec@neptune.tis.com From: "John C. Kelley" <johnk@TIS.COM> Subject: Apologies Sender: ipsec-approval@neptune.tis.com Precedence: bulk I want to apologize for the possible multiple postings of two messages from Robert Moskowitz at Chrysler Corporation. We have recently implemented a policy to moderate postings from non-members of all of our majordomo lists. This is due to the recent increase in spamming. Something threw our moderating procedure out of whack with these messages from Robert, making the first attempts to post his message have invalid headers. These should be cleaned up now. Thank you for bearing with us as we go through this change to make the lists better with hopefully a minimum of impact on you. -John Kelley -- John C. Kelley System Administrator (301) 854-6889 Trusted Information Systems, Inc. (301) 854-5363 FAX 3060 Washington Road johnk@tis.com (work) Glenwood, MD 21738 johnk@radix.net (play) Received: from relay.hq.tis.com by neptune.TIS.COM id aa14484; 16 Aug 96 7:17 EDT Received: by relay.hq.tis.com; id HAA14539; Fri, 16 Aug 1996 07:20:20 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma014532; Fri, 16 Aug 96 07:19:52 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA16278; Fri, 16 Aug 96 07:19:13 EDT Received: by relay.hq.tis.com; id HAA14528; Fri, 16 Aug 1996 07:19:51 -0400 Received: from unknown.tycho.ncsc.mil(144.51.3.1) by relay.tis.com via smap (V3.1.1) id xma014523; Fri, 16 Aug 96 07:19:40 -0400 Received: by tarius.tycho.ncsc.mil (4.1/SMI-4.1) id AA09199; Fri, 16 Aug 96 07:19:17 EDT Date: Fri, 16 Aug 96 07:19:17 EDT From: "Mark S. Schneider" <mss@tycho.ncsc.mil> Message-Id: <9608161119.AA09199@tarius.tycho.ncsc.mil> To: rgm3@chrysler.com Subject: Re: Comments on ISAKMP/Oakley Cc: mss@tycho.ncsc.mil, wdm@tycho.ncsc.mil, sjt@tycho.ncsc.mil, mjs@terisa.com, ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk > At 07:39 AM 8/12/96 EDT, Mark S. Schneider wrote: > >> From: Naganand Doraswamy <naganand@ftp.com> > >> > >> These are mostly implemetation type comments: > >> > >> 2.4.1. Security Association Payload > >> Is the "Payload Length" field *really* supposed to be specified in > >> four-octet units, or should it be in octets as all the other payloads > >> are? > >> > > > > I believe it should be in octets. It seems unlikely that a SA payload > > will ever be large enough to require a length in 4-octet units. > > IPv6 jumbograms????? > > Robert Moskowitz > Chrysler Corporation > (810) 758-8212 > Bob, Sorry for the confusion. An SA (security association) payload is an ISAKMP payload for negotiating security attributes and for indentifying the domain of interpretation (DOI) and situation under which the negotiation is taking place. So, the length field I'm referencing applies only to the contents of this payload. I don't believe the representation of security attributes supported by any one entity will exceed 64K octets. Mark Schneider Received: from relay.hq.tis.com by neptune.TIS.COM id aa19786; 16 Aug 96 10:48 EDT Received: by relay.hq.tis.com; id KAA21352; Fri, 16 Aug 1996 10:51:04 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma021324; Fri, 16 Aug 96 10:50:42 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA24956; Fri, 16 Aug 96 10:50:00 EDT Received: by relay.hq.tis.com; id KAA21313; Fri, 16 Aug 1996 10:50:34 -0400 Received: from wizard.pn.com(204.96.36.2) by relay.tis.com via smap (V3.1.1) id xma021305; Fri, 16 Aug 96 10:50:30 -0400 Received: from massey (massey.ftp.com [128.127.128.152]) by wizard.pn.com (8.6.12) with SMTP id KAA31126 for <ipsec@tis.com>; Fri, 16 Aug 1996 10:52:43 -0400 Message-Id: <199608161452.KAA31126@wizard.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 Aug 1996 10:52:23 -0400 To: ipsec@TIS.COM From: Rodney Thayer <rodney@sabletech.com> Subject: Apologies Sender: ipsec-approval@neptune.tis.com Precedence: bulk "trust but verify"? (thank you for taking such good care of the list. geting nude belly dancing advertisements on ietf was bad enough thank you...) >X-Sender: johnk@pop.tis.com >Date: Thu, 15 Aug 1996 17:14:20 -0400 >To: ipsec@neptune.hq.tis.com >From: "John C. Kelley" <johnk@TIS.COM> >Subject: Apologies >Sender: ipsec-approval@neptune.hq.tis.com > > >I want to apologize for the possible multiple postings of two messages >from Robert Moskowitz at Chrysler Corporation. We have recently implemented >a policy to moderate postings from non-members of all of our majordomo >lists. This is due to the recent increase in spamming. Something >threw our moderating procedure out of whack with these messages from >Robert, making the first attempts to post his message have invalid >headers. These should be cleaned up now. > >Thank you for bearing with us as we go through this change to make >the lists better with hopefully a minimum of impact on you. > > -John Kelley >-- >John C. Kelley >System Administrator (301) 854-6889 >Trusted Information Systems, Inc. (301) 854-5363 FAX >3060 Washington Road johnk@tis.com (work) >Glenwood, MD 21738 johnk@radix.net (play) > > > > > Rodney Thayer <rodney@sabletech.com> +1 617 332 7292 Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA Fax: +1 617 332 7970 http://www.shore.net/~sable "Developers of communications software" Received: from relay.hq.tis.com by neptune.TIS.COM id aa20217; 16 Aug 96 10:59 EDT Received: by relay.hq.tis.com; id LAA21924; Fri, 16 Aug 1996 11:02:36 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma021907; Fri, 16 Aug 96 11:02:21 -0400 Received: from london.eu.tis.com by tis.com (4.1/SUN-5.64) id AA25714; Fri, 16 Aug 96 11:01:19 EDT Received: from relay.eu.tis.com (firewall-user@relay.eu.tis.com [10.217.55.100]) by london.eu.tis.com (8.7.3/8.7.3) with ESMTP id PAA01003 for <ipsec@tis.com>; Fri, 16 Aug 1996 15:59:57 +0100 (BST) Received: by relay.eu.tis.com; id LAA27135; Fri, 16 Aug 1996 11:55:47 +0100 (BST) Received: from unknown.tycho.ncsc.mil(144.51.3.1) by relay.eu.tis.com via smap (V3.1.1) id xma027133; Fri, 16 Aug 96 11:55:25 +0100 Received: by tarius.tycho.ncsc.mil (4.1/SMI-4.1) id AA02301; Fri, 16 Aug 96 09:45:21 EDT Date: Fri, 16 Aug 96 09:45:21 EDT From: "Mark S. Schneider" <mss@tycho.ncsc.mil> Message-Id: <9608161345.AA02301@tarius.tycho.ncsc.mil> To: naganand@ftp.com Subject: Re: Comments on ISAKMP/Oakley Cc: mss.wdm@tycho.ncsc.mil, sjt@tycho.ncsc.mil, mjs@terisa.com, ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Naganand, Conversation guide: >>> and > == Naganand Doraswamy >> == Mark Schneider >>> >>> Where is "Multiple Precision Integer" specified? >>> >> >> It's defined in draft-ietf-ipsec-oakley-01.txt, Appendix D. >> > For completeness, I suggest that you atleast mention where to look for the > definition of multiple precision integer, or just add it in appendix in the > draft. Ok. >>> >>> A.7.1 The basic proposal format does has the following fields defined in the >>> header: >>> - Proposal #, Proposal Len, Protocol # and Attribute TLV's >>> However, the ESP, AH, and ISAKMP proposals have defined the >>> Transforms ID's and a reserved field. Shouldnt the basic proposal >>> format take care of this as well? >> >> Yes. I guess we intended that the TLV could be used for the Transform >> ID. Granted, that would take 8 octets. Are you suggesting adding a >> Transform ID field to the Proposal #, Proposal Len, and Protocol # >> fields? If so, how do you think this should be done? Reducing the >> size of the Protocol # field? Your thoughts are appreciated. >> > I think we could reduce the protocol field size to one octet. Almost all the > protocols I have seen have only one octet allocated for protocol ID and I > feel it is safe to allocate one byte and use the other octet for transform > ID, unless other people feel strongly against this. Now that I've had more time to think about this and have been (gently) reminded about the purpose of a *basic* proposal format, I don't think it should be changed. The basic proposal format provides the foundation from which other proposal formats can be derived. So, ESP and AH and ISAKMP proposals are derived from the basic format and happen to include transform ids. It's possible in the future (for possibly other protocols) that the things we're negotiating don't have transform ids. >>> A.7.4. Proposal Formats, ISAKMP: ??? >>> >> >>Section A.7.4. is intended to describe the confidentiality and authentication >>mechanisms that are internal to ISAKMP and used to provide Phase I security. >>Confidentiality will be provided by applying the IPsec ESP transform(s) to >>ISAKMP messages. Authentication can also use IPsec AH transforms, only if >>keys have been preplaced. This means we have to determine a public key >>mechanism for authentication. We're working on this. >> >> >How does one obtain the keys for ESP transform on Phase I ISAKMP messages? >Is it an out of band mechanism or are the keys derived based on some public >key mechanism? I really blew this one! Section A.7.4 is intended to describe the confidentiality and authentication mechanisms that are internal to ISAKMP and used to provide security *in* Phase I to protect Phase II negotiations. So, its intended to describe the mechanisms that ISAKMP uses to protect ISAKMP-ISAKMP communications. My loose use of terminology concerning ESP transforms is also a problem. I didn't intend to imply that we are letting IPsec handle Phase I confidentiality. All I'm saying is we can leverage off the work done for IPsec ESP and use the algorithms defined there in ISAKMP. Yes, I understand that the ESP transforms are tied to processing IP packets and adding an ESP header. We'll have to define how to apply the algorithms in ISAKMP. So, then the keys are obtained in the Phase I negotiation by using the Oakley key exchange. It is not until after the key exchange that confidentiality can be provided. I hope this is a little clearer. You raise some interesting points regarding Modifying SAs. Since I'm leaving early today :) I hope you don't mind if I address these issues next week. Regards, Mark Schneider Received: from relay.hq.tis.com by neptune.TIS.COM id aa24241; 16 Aug 96 13:16 EDT Received: by relay.hq.tis.com; id NAA25917; Fri, 16 Aug 1996 13:04:41 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma025909; Fri, 16 Aug 96 13:04:20 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA01897; Fri, 16 Aug 96 13:03:40 EDT Received: by relay.hq.tis.com; id NAA25896; Fri, 16 Aug 1996 13:04:16 -0400 Received: from p-spatsch.cs.arizona.edu(150.135.1.98) by relay.tis.com via smap (V3.1.1) id xma025845; Fri, 16 Aug 96 13:03:39 -0400 Received: from localhost (spatsch@localhost) by P-spatsch.cs.arizona.edu (8.6.12/8.6.9) with SMTP id KAA01205 for <ipsec@tis.com>; Fri, 16 Aug 1996 10:02:00 -0700 X-Authentication-Warning: P-spatsch.cs.arizona.edu: spatsch owned process doing -bs Date: Fri, 16 Aug 1996 10:01:56 -0700 (MST) From: Oliver Spatscheck <spatsch@cs.arizona.edu> Reply-To: Oliver Spatscheck <spatsch@cs.arizona.edu> To: ipsec@TIS.COM Subject: KEI visa XCHG (ISAKMP & OAKLEY) Message-Id: <Pine.LNX.3.94.960816095936.1186A-100000@P-spatsch.cs.arizona.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I am just implementing the ISAKMP header and realized that the xchg field has only 4 bit. This seems to small. The Oakley modes has to be handled as different exchange types as already mentioned by Mark. However counting the 4 reserved exchange types and the 4 Oakley exchange types there are only 8 other exchange types left. Considering that we are currently designing a multicast key exchange protocol using the ISAKMP framework I would strongly recommend to use 16 Bit in the xchg field of the header. Realizing this problem I was thinking about the Oakley KEI and I don't think Oakley needs it's own KEI. Oakley main mode uses regular DH key exchange or RSA encryption and the other Oakley modes don't use key exchange payload at all. Therefore a general KEI for DH, RSA encryption and a KEI for no key exchange payload should be added. The ISAKMP draft mentions Oakley multiple times as a key exchange technique identified by a KEI. This is not true Oakley is a full size exchange using sa, nonce, id, key exchange, signature and hash payloads. The combination of selected attributes and used Oakley mode defines the contents and presence of the hash, id, nonce and signature payloads. There is no such thing as ONE Oakley KEI. I forgot to mention in my last email that I am only implementing the Oakley exchanges at this point. I am establishing the Phase 1 ISAKMP SA using Oakley as I am using Oakley to establish the IPSEC SA. It would be easy for me to add the ISAKMP exchanges or CISCO exchange. However they all are less flexible than Oakley. Oliver - ----- Grad student and research assistant in computer science at the University of Arizona, Tucson, USA For my PGP public key please check my homepage URL: http://www.cs.arizona.edu/people/spatsch -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBMhSphznVPgUZ7uZJAQEywQQAiE+WqkNsyPzLI4PNpIA8wb6kuKpsBqoZ 7SNvv9AdBrKdBMVhCYScN03xnZheziU/765u+CD9nZxmBCBaseRA4wGT9sPHLku/ tE4EVIlTqmQDkrGcn/+w8K0BuJ5iroRWSiiODU+1bkXoRJtwd5m4WAeX2l/uAgMf ZqBEn4zvfK4= =a85z -----END PGP SIGNATURE----- Received: from relay.hq.tis.com by neptune.TIS.COM id aa26487; 16 Aug 96 14:46 EDT Received: by relay.hq.tis.com; id OAA00981; Fri, 16 Aug 1996 14:49:15 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma000951; Fri, 16 Aug 96 14:48:50 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA08068; Fri, 16 Aug 96 14:48:10 EDT Received: by relay.hq.tis.com; id OAA00945; Fri, 16 Aug 1996 14:48:45 -0400 Received: from ns.incog.com(199.190.177.251) by relay.tis.com via smap (V3.1.1) id xma000918; Fri, 16 Aug 96 14:48:22 -0400 Received: from osmosys.incog.com by incog.com (SMI-8.6/94082501) id LAA12540; Fri, 16 Aug 1996 11:48:50 -0700 Received: from miraj.incog.com by osmosys.incog.com (SMI-8.6/SMI-SVR4) id LAA05351; Fri, 16 Aug 1996 11:50:38 -0700 Received: by miraj.incog.com (SMI-8.6/SMI-SVR4) id LAA01604; Fri, 16 Aug 1996 11:49:48 -0700 From: Rich Skrenta <skrenta@osmosys.incog.com> Message-Id: <199608161849.LAA01604@miraj.incog.com> Subject: Re: ...draft ...*skip*... To: Rodney Thayer <rodney@sabletech.com> Date: Fri, 16 Aug 1996 11:49:47 -0700 (PDT) Cc: ipsec@TIS.COM In-Reply-To: <9608151531.AA17325@wellspring.us.dg.com> from "Rodney Thayer" at Aug 15, 96 11:31:03 am 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-approval@neptune.tis.com Precedence: bulk > Excuse me but what's the status of the "what key management scheme are we > agreeing upon" process? > > If SKIP is it than this is nice. > > IF SKIP isn't it then what is this? (I mean, it's a free internet but that > would mean the filename didn't start with "draft-ietf-...") skip-07 is mostly tightening-up of some ambiguous language in the draft, based on comments we received from the other implementors at our developer's workshop. We promised them a revised draft, and Tom Markson presented the changes at Montreal. We've finally gotten the revised draft out the door. As far as the status of the smoke-filled room discussions... we don't have an answer to give you just yet. Received: from relay.hq.tis.com by neptune.TIS.COM id aa02267; 16 Aug 96 19:30 EDT Received: by relay.hq.tis.com; id TAA10152; Fri, 16 Aug 1996 19:33:22 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma010147; Fri, 16 Aug 96 19:32:54 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA25777; Fri, 16 Aug 96 19:32:14 EDT Received: by relay.hq.tis.com; id TAA10141; Fri, 16 Aug 1996 19:32:52 -0400 Received: from atc.boeing.com(130.42.28.80) by relay.tis.com via smap (V3.1.1) id xma010136; Fri, 16 Aug 96 19:32:24 -0400 Received: by atc.boeing.com (5.65/splinter.boeing.com) id AA08673; Fri, 16 Aug 1996 16:33:50 -0700 Received: from commanche.ca.boeing.com by splinter.boeing.com with SMTP (1.37.109.16/16.2) id AA143658399; Fri, 16 Aug 1996 16:33:19 -0700 Received: by commanche.ca.boeing.com (AIX 4.1/UCB 5.64/4.03) id AA34366; Fri, 16 Aug 1996 16:34:30 -0700 Message-Id: <9608162334.AA34366@commanche.ca.boeing.com> To: Robert Moskowitz <rgm3@chrysler.com> Cc: John Gilmore <gnu@toad.com>, ipsec@TIS.COM, tld5032@commanche.ca.boeing.com Subject: Re: DNS? was Key Management In-Reply-To: (Your message of Thu, 15 Aug 96 11:53:52 -0400.) <9608151650.aa26859@neptune.TIS.COM> Date: Fri, 16 Aug 96 16:34:28 -0700 From: "Terry L. Davis, Boeing Information & Support Services, Bellevue, WA" <tld5032@commanche.ca.boeing.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 04:55 PM 8/14/96 -0700, John Gilmore wrote: > >I also think we should focus on shipping standards that hit the sweet >spot (most gain for least pain), which includes securing communications >among all the hosts with fixed IP addresses. On Thu, 15 Aug 1996 11:53:52 -0400 Robert Moskowitz responded: > >John, there are about 8,000 productive parts suppliers in the auto industry >and 17 oems. Chyrsler has already deployed 5,000 notebooks. >.... >Day one, I've got lot more dynamic than I have fixed. > Chrysler's not alone here! As of last count in May we had 104,000 active IP addresses. About 40% are now supported with DHCP. It should be well 50% by the end of 97 after we begin to get the bulk of our UNIX systems converted to DHCP. But the new installs and newer systems that would be candidates for IPSEC are already well over 50% DHCP supported. I also have heard that a number of the large ISP's are using DHCP; perhaps someone from that group could comment on the impacts? Take care | Terry L. Davis, P.E.| Boeing Information & Support Services, Bellevue, WA | | 206-957-5325 | BOEING EMAIL: tld5032@commanche.ca.boeing.com. | ----------------- Friday August 16,1996 04:32 PM PDT ---------------- Received: from relay.hq.tis.com by neptune.TIS.COM id aa03751; 16 Aug 96 20:38 EDT Received: by relay.hq.tis.com; id QAA04534; Fri, 16 Aug 1996 16:00:51 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma004519; Fri, 16 Aug 96 16:00:21 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA11240; Fri, 16 Aug 96 15:59:39 EDT Received: by relay.hq.tis.com; id QAA04508; Fri, 16 Aug 1996 16:00:16 -0400 Received: from panix.com(198.7.0.2) by relay.tis.com via smap (V3.1.1) id xma004494; Fri, 16 Aug 96 15:59:40 -0400 Received: (from netsec@localhost) by panix.com (8.7.5/8.7/PanixU1.3) id QAA14209; Fri, 16 Aug 1996 16:01:31 -0400 (EDT) Date: Fri, 16 Aug 1996 16:01:31 -0400 (EDT) From: "M.C.Nelson" <netsec@panix.com> To: ipsec@TIS.COM Subject: "user" and "network layer" security. Message-Id: <Pine.SUN.3.91.960816155715.811B-100000@panix.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk Language in the Internet draft IPSEC architecture, and in its predecessor RFC 1825, refer to "IP-layer security". This is in itself consistent with lanquage in the IPSEC charter that refers to a "security protocol in the network layer". However, several contributions to this discussion group as well other lanquage in the IPSEC docments, refer to the term "user". This is curious. There is no concept of "user" at the IP layer (i.e. the network layer). Moreover, there is no clean and reliable way to map from IP datagram to user. Any such code will be problematic unless the functionality of IP is severely altered. For example, consider a transport protocol that combines service to several users simultaneously. Perfectly legal, but problematic for a network layer mechanism that needs to know about users. The candidate network layer code would need to know all of the protocols that would be used with IP. In short, it would no longer be a true network layer mechanism, but rather a kludge. The most appropriate place to discuss and design "user" security mechanisms woud seem to be in another discussion group. It is difficult to understand how one could use the term "user" anywhere below the application layer. Mixing "user" constructs into the network layer breaks the network architecture and should be expected to lead to undesirable and probably needless consequences. "User" based security and "network layer" security can each be designed and implemented in ways that are consistent with the established network architecture. With some pro-forma cross consultation, one should expect to arrive at reasonable results that provide good security without conflict and without unduly compromising present network functionality. The alternative does not offer as much grounds for optimism. Therefore it seems that all lanquage related to "user" should be expunged from IPSEC and instead treated in a seperate discussion group. Regards to all, Mitch Nelson netsec@panix.com Date: Fri, 16 Aug 1996 16:55:16 -0400 From: "Mitchell C. Nelson" <nelson@mcn.netsec.com> Message-Id: <199608162055.QAA01070@mcn.netsec.com> To: ipsec@TIS.COM, netsec@panix.com Subject: "user" and "network layer" security mechanisms. Sender: ipsec-approval@neptune.tis.com Precedence: bulk Language in the Internet draft IPSEC architecture, and in its predecessor RFC 1825, refer to "IP-layer security". This is in itself consistent with lanquage in the IPSEC charter that refers to a "security protocol in the network layer". However, several contributions to this discussion group as well other lanquage in the IPSEC docments, refer to the term "user". This is curious. There is no concept of "user" at the IP layer (i.e. the network layer). Moreover, there is no clean and reliable way to map from IP datagram to user. Any such code will be problematic unless the functionality of IP is severely altered. For example, consider a transport protocol that combines service to several users simultaneously. Perfectly legal, but problematic for a network layer mechanism that needs to know about users. The candidate network layer code would need to know all of the protocols that would be used with IP. In short, it would no longer be a true network layer mechanism, but rather a kludge. The most appropriate place to discuss and design "user" security mechanisms woud seem to be in another discussion group. It is difficult to understand how one could use the term "user" anywhere below the application layer. Mixing "user" constructs into the network layer breaks the network architecture and should be expected to lead to undesirable and probably needless consequences. "User" based security and "network layer" security can each be designed and implemented in ways that are consistent with the established network architecture. With some pro-forma cross consultation, one should expect to arrive at reasonable results that provide good security without conflict and without unduly compromising present network functionality. The alternative does not offer as much grounds for optimism. Therefore it seems that all lanquage related to "user" should be expunged from IPSEC and instead treated in a seperate discussion group. Regards to all, Mitch Nelson netsec@panix.com Received: from relay.hq.tis.com by neptune.TIS.COM id aa04985; 16 Aug 96 22:28 EDT Received: by relay.hq.tis.com; id WAA11771; Fri, 16 Aug 1996 22:31:52 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma011769; Fri, 16 Aug 96 22:31:23 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA28587; Fri, 16 Aug 96 22:30:44 EDT Received: by relay.hq.tis.com; id WAA11766; Fri, 16 Aug 1996 22:31:22 -0400 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1.1) id xma011764; Fri, 16 Aug 96 22:31:01 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.12/8.6.5) id TAA20759; Fri, 16 Aug 1996 19:33:17 -0700 Date: Fri, 16 Aug 1996 19:33:17 -0700 From: Ran Atkinson <rja@cisco.com> Message-Id: <199608170233.TAA20759@puli.cisco.com> To: mrf@epilogue.com Subject: Re: (IPng 2039) Re: IPv6 encryption requirement In-Reply-To: <9608160932.aa23772@quern.epilogue.com> References: <199608151738.NAA01091@jekyll.piermont.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk My understanding of the IESG's decision is that both AH and ESP (and the corresponding standards-track mandatory transforms, currently 1828 and 1829 but subject to change via normal IETF process) are mandatory for all IPv6 nodes. The current RFCs and I-Ds are not sufficiently clear. I plead guilty to the lack of clarity. I plan to fix this in the next set of I-D revisions. If I don't fix it in the next set of I-D revisions, I'm sure one or more folks will send me a gentle reminder that I forgot to make those fixes. :-) Ran rja@cisco.com Received: from relay.hq.tis.com by neptune.TIS.COM id aa00969; 19 Aug 96 9:21 EDT Received: by relay.hq.tis.com; id JAA01571; Mon, 19 Aug 1996 09:24:25 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma001565; Mon, 19 Aug 96 09:23:57 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA09605; Mon, 19 Aug 96 09:23:15 EDT Received: by relay.hq.tis.com; id JAA01559; Mon, 19 Aug 1996 09:23:55 -0400 Received: from guardian.guard.ncsc.mil(144.51.52.1) by relay.tis.com via smap (V3.1.1) id xma001556; Mon, 19 Aug 96 09:23:50 -0400 Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id JAA11077 for <ipsec@TIS.COM>; Mon, 19 Aug 1996 09:26:04 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma011074; Mon Aug 19 09:25:47 1996 Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id JAA13222 for <ipsec@TIS.COM>; Mon, 19 Aug 1996 09:22:30 -0400 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id JAA14640; Mon, 19 Aug 1996 09:25:37 -0400 Date: Mon, 19 Aug 1996 09:25:37 -0400 From: "David P. Kemp" <dpkemp@missi.ncsc.mil> Message-Id: <199608191325.JAA14640@argon.ncsc.mil> To: ipsec@TIS.COM Subject: Re: "user" and "network layer" security. X-Sun-Charset: US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk > From: "M.C.Nelson" <netsec@panix.com> > > There is no concept of "user" at the IP layer (i.e. the network layer). > [A:] Moreover, there is no clean and reliable way to map from IP datagram to > user. Any such code will be problematic unless the functionality of > IP is severely altered. [B:] For example, consider a transport protocol > that combines service to several users simultaneously. IP datagrams can, however, be associated unambiguously with src and dst addresses and port numbers, which (must necessarily) map unambiguously to processes, which in turn can map to users on those systems which support the notion of users. Your example B above is proof that assertion A is incorrect. > The most appropriate place to discuss and design "user" security > mechanisms woud seem to be in another discussion group. IPSEC is designing two protocols. One of them operates at the IP layer and performs transforms on packets. The other operates at the application layer and establishes the keys for the first. It may indeed be appropriate to divide the effort into two working groups and two mailing lists. It would certainly be easier to explain what is meant for a product to be "IPSEC-compliant" if there were another label "IP-SA-MGT-compliant" to remove the overloading from the first. But the current IPSEC charter is not so divided, therefore discussions of key management, application-layer daemons, and "users" are currently appropriate for this group. > It is difficult > to understand how one could use the term "user" anywhere below the > application layer. Perhaps it would be easier to understand how the term "context" (in the sense of the X window system's "graphics context" - a pointer to a blob of data) fits in at the IP layer. IP doesn't need to interpret the entire contents of the blob, just the parts it's interested in. To: "Mitchell C. Nelson" <nelson@mcn.netsec.com> Cc: ipsec@TIS.COM, netsec@panix.com Subject: Re: "user" and "network layer" security mechanisms. In-Reply-To: Your message of "Fri, 16 Aug 1996 16:55:16 EDT." <199608162055.QAA01070@mcn.netsec.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 19 Aug 1996 11:02:16 -0400 From: "Perry E. Metzger" <perry@piermont.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9608191101.aa03898@neptune.TIS.COM> "Mitchell C. Nelson" writes: > Language in the Internet draft IPSEC architecture, and in its predecessor > RFC 1825, refer to "IP-layer security". This is in itself consistent with > lanquage in the IPSEC charter that refers to a "security protocol in the > network layer". However, several contributions to this discussion group > as well other lanquage in the IPSEC docments, refer to the term "user". > This is curious. > > There is no concept of "user" at the IP layer (i.e. the network layer). You seem to have missed the point, which is that IPSEC has this notion of "security association" (actually, now its called "Security Parameters" and has the associated "Security Parameters Index"). Why don't you go through the archives instead of making guesses about what you think IPSEC does? Perry Received: from relay.hq.tis.com by neptune.TIS.COM id aa03743; 19 Aug 96 10:57 EDT Received: by relay.hq.tis.com; id LAA04675; Mon, 19 Aug 1996 11:01:00 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma004654; Mon, 19 Aug 96 11:00:32 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA17033; Mon, 19 Aug 96 10:59:50 EDT Received: by relay.hq.tis.com; id LAA04646; Mon, 19 Aug 1996 11:00:30 -0400 Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap Message-ID: <9608191107.aa04103@neptune.TIS.COM> (V3.1.1) id xma004641; Mon, 19 Aug 96 11:00:18 -0400 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.5/8.6.12) with SMTP id LAA11313; Mon, 19 Aug 1996 11:02:21 -0400 (EDT) Message-Id: <199608191502.LAA11313@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: "Mitchell C. Nelson" <nelson@mcn.netsec.com> Cc: ipsec@TIS.COM, netsec@panix.com Subject: Re: "user" and "network layer" security mechanisms. In-Reply-To: Your message of "Fri, 16 Aug 1996 16:55:16 EDT." <199608162055.QAA01070@mcn.netsec.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 19 Aug 1996 11:02:16 -0400 From: "Perry E. Metzger" <perry@piermont.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk "Mitchell C. Nelson" writes: > Language in the Internet draft IPSEC architecture, and in its predecessor > RFC 1825, refer to "IP-layer security". This is in itself consistent with > lanquage in the IPSEC charter that refers to a "security protocol in the > network layer". However, several contributions to this discussion group > as well other lanquage in the IPSEC docments, refer to the term "user". > This is curious. > > There is no concept of "user" at the IP layer (i.e. the network layer). You seem to have missed the point, which is that IPSEC has this notion of "security association" (actually, now its called "Security Parameters" and has the associated "Security Parameters Index"). Why don't you go through the archives instead of making guesses about what you think IPSEC does? Perry Received: from relay.hq.tis.com by neptune.TIS.COM id aa06155; 19 Aug 96 12:27 EDT Received: by relay.hq.tis.com; id MAA07209; Mon, 19 Aug 1996 12:30:28 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma007194; Mon, 19 Aug 96 12:30:05 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA21984; Mon, 19 Aug 96 12:29:19 EDT Received: by relay.hq.tis.com; id MAA07188; Mon, 19 Aug 1996 12:29:58 -0400 Received: from copilot.is.chrysler.com(204.189.94.36) by relay.tis.com via smap (V3.1.1) id xma007179; Mon, 19 Aug 96 12:29:31 -0400 Received: by pilotx.firewall.is.chrysler.com; id MAA06449; Mon, 19 Aug 1996 12:31:36 -0400 Received: from mhbclpr2-le0.is.chrysler.com(172.29.128.206) by pilotx.is.chrysler.com via smap (g3.0.1) id sma006441; Mon, 19 Aug 96 12:31:31 -0400 Received: from rgm3 (rgm3.is.chrysler.com [129.9.247.160]) by mhbclpr2-nf0.is.chrysler.com (8.7.5/8.7.3) with SMTP id MAA22114 for <ipsec@tis.com>; Mon, 19 Aug 1996 12:23:57 -0400 (EDT) Message-Id: <2.2.32.19960819162829.00bd8840@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@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: Mon, 19 Aug 1996 12:28:29 -0400 To: ipsec@TIS.COM From: Robert Moskowitz <rgm3@chrysler.com> Subject: Re: Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 12:12 PM 8/19/96 -0400, ipsec-request@neptune.tis.com wrote: >To: "Mitchell C. Nelson" <nelson@mcn.netsec.com> I'm getting these messages rather wierdly this morning, is anyone else??? >Date: Mon, 19 Aug 1996 11:02:16 -0400 >From: "Perry E. Metzger" <perry@piermont.com> >> >> There is no concept of "user" at the IP layer (i.e. the network layer). > >You seem to have missed the point, which is that IPSEC has this notion >of "security association" (actually, now its called "Security >Parameters" and has the associated "Security Parameters Index"). > >Why don't you go through the archives instead of making guesses about >what you think IPSEC does? Perry, people should not have to 'read the archives' for so basic a concept. Maybe it really is too obscure in the architecture RFC. Going to have to reread it :( Yes, Mitchell, IPsec has a concept of a user. This is for setting up security associations between two IP addresses, potentially at the transport layer (rather than as a tunnel). Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.hq.tis.com by neptune.TIS.COM id aa19856; 20 Aug 96 1:25 EDT Received: by relay.hq.tis.com; id BAA24187; Tue, 20 Aug 1996 01:28:36 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma024184; Tue, 20 Aug 96 01:28:08 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA22270; Tue, 20 Aug 96 01:27:27 EDT Received: by relay.hq.tis.com; id BAA24175; Tue, 20 Aug 1996 01:28:07 -0400 Received: from austria-c.it.earthlink.net(206.85.92.44) by relay.tis.com via smap (V3.1.1) id xma024168; Tue, 20 Aug 96 01:27:45 -0400 Received: from rmonsour (max1-wc-ca-40.earthlink.net [206.149.198.90]) by austria.it.earthlink.net (8.7.5/8.7.3) with SMTP id WAA24373; Mon, 19 Aug 1996 22:29:34 -0700 (PDT) Message-Id: <2.2.32.19960820053051.007412f4@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 19 Aug 1996 22:30:51 -0700 To: Stephen Kent <kent@bbn.com>, Marcel Waldvogel <mwa@tik.ee.ethz.ch> From: Bob Monsour <rmonsour@earthlink.net> Subject: Re: I-D ACTION:draft-thayer-seccomp-00.txt Cc: Naganand Doraswamy <naganand@ftp.com>, ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 07:07 PM 8/12/96 -0400, Stephen Kent wrote: >Marcel, > > Our plans for re-writing the ESP and AH specs will avoid the need >to document the combinatorial set of transforms. Instead, it will be >possible to define the algorithms or transform elements via distinct RFCs. >The ESP and AH specs will be upgraded to define formats for all of the >optional fields required by the different transforms. Steve, Are you anticipating that the revised ESP spec will define formats for the optional fields necessary to support lossless data compression? We are planning a proposal along the lines of a combined compression/encryption transform. I worry that your plans make it difficult to 'predict' "all of the optional fields required by the different transforms". Did I misunderstand what you meant? Bob Monsour Bob Monsour rmonsour@earthlink.net From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Message-Id: <199608200611.PAA07631@necom830.hpcl.titech.ac.jp> Subject: Re: "user" and "network layer" security. To: "David P. Kemp" <dpkemp@missi.ncsc.mil> Date: Tue, 20 Aug 96 15:10:50 JST Cc: ipsec@TIS.COM X-Mailer: ELM [version 2.3 PL11] Sender: ipsec-approval@neptune.tis.com Precedence: bulk > > The most appropriate place to discuss and design "user" security > > mechanisms woud seem to be in another discussion group. > > IPSEC is designing two protocols. One of them operates at the IP layer > and performs transforms on packets. The other operates at the application > layer and establishes the keys for the first. Agreed. "user" gives information to establish appropriate "network" layer security. The problem is that the required security varies application by application. Thus, neither secure "network" layer nor SECDNS can give "user" appropriate security. For example, even if your mail address is "name@provider.com", you don't want your provider have control on your keys to decrypt your mail. > > It is difficult > > to understand how one could use the term "user" anywhere below the > > application layer. It's an API issue, I think. Masataka Ohta Received: from relay.hq.tis.com by neptune.TIS.COM id aa03258; 20 Aug 96 10:12 EDT Received: by relay.hq.tis.com; id KAA00896; Tue, 20 Aug 1996 10:15:28 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma000883; Tue, 20 Aug 96 10:15:04 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA07471; Tue, 20 Aug 96 10:14:20 EDT Received: by relay.hq.tis.com; id KAA00873; Tue, 20 Aug 1996 10:14:58 -0400 Received: from bastion.sware.com(139.131.15.2) by relay.tis.com via smap (V3.1.1) id xma000869; Tue, 20 Aug 96 10:14:50 -0400 Received: from zeus.sware.com (zeus.sware.com [139.131.1.166]) by bastion.sware.com (8.6.12/8.6.5) with ESMTP id KAA28323; Tue, 20 Aug 1996 10:16:42 -0400 Received: by zeus.sware.com (1.39.111.2/2.0) from mordred.sware.com id AA247460617; Tue, 20 Aug 1996 10:16:57 -0400 Received: by mordred.sware.com (5.65/2.1) id AA00964; Tue, 20 Aug 96 10:09:03 -0400 Message-Id: <9608201409.AA00964@mordred.sware.com> Subject: Re: "user" and "network layer" security mechanisms. To: perry@piermont.com Date: Tue, 20 Aug 1996 10:09:03 -0400 (EDT) From: Charles Watt <watt@sware.com> Cc: nelson@mcn.netsec.com, ipsec@TIS.COM, netsec@panix.com In-Reply-To: <9608191101.aa03898@neptune.TIS.COM> from "Perry E. Metzger" at Aug 19, 96 11:02:16 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 3627 Sender: ipsec-approval@neptune.tis.com Precedence: bulk -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-Certificate: MIIBvzCCAWkCEFmOln6ip0w49CuyWr9vDVUwDQYJKoZIhvcNAQECBQAwWTELMAkG A1UEBhMCVVMxGDAWBgNVBAoTD1NlY3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2Vj dXJlV2FyZSBQQ0ExFzAVBgNVBAsTDkVuZ2luZWVyaW5nIENBMB4XDTk1MDUwODIw MjMzNVoXDTk3MDUwNzIwMjMzNVowcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1Nl Y3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2VjdXJlV2FyZSBQQ0ExFzAVBgNVBAsT DkVuZ2luZWVyaW5nIENBMRUwEwYDVQQDEwxDaGFybGVzIFdhdHQwWTAKBgRVCAEB AgICBANLADBIAkEM2ZSp7b6eqDqK5RbPFpd6DGSLjbpHOZU07pUcdgJXiduj9Ytf 1rsmf/adaplQr+X5FeoIdT/bVSv2MUi3gY0eFwIDAQABMA0GCSqGSIb3DQEBAgUA A0EApEjzeBjiSnGImJXgeY1K8HWSufpJ2DpLBF7DYqqIVAX9H7gmfOJhfeGEYVjK aTxjgASxqHhzkx7PkOnL4JrN+Q== MIC-Info: RSA-MD5,RSA, BVIkGz4BmKij6ZtnUyFpDF6s9eXCX+6ZtMa+5csK4aBxc0BXSfEnQm2Racglqkav c4vxdH4Iyt7nYMMSrkkgtxw= > > M.C.Nelson <netsec@panix.com> wrote: > > > > There is no concept of "user" at the IP layer (i.e. the network layer). > > [A:] Moreover, there is no clean and reliable way to map from IP datagram to > > user. Any such code will be problematic unless the functionality of > > IP is severely altered. [B:] For example, consider a transport protocol > > that combines service to several users simultaneously. > > David Kemp wrote: > > IP datagrams can, however, be associated unambiguously with src and dst > addresses and port numbers, which (must necessarily) map unambiguously to > processes, which in turn can map to users on those systems which support > the notion of users. Your example B above is proof that assertion > A is incorrect. > > > Perry E. Metzger wrote: > > You seem to have missed the point, which is that IPSEC has this notion > of "security association" (actually, now its called "Security > Parameters" and has the associated "Security Parameters Index"). > > Why don't you go through the archives instead of making guesses about > what you think IPSEC does? Mr. Nelson is quite correct, in spite of the assertions otherwise. Yes IPSEC has a concept of a security association, which could conceivably be linked to individual users rather than hosts. But in order for such a mechanism to be useful for user-level authentication with an IP security protocol, there must be an unambiguous way to link each IP datagram protected by the security protocol to a specific user-level security association. Mr. Nelson's point was simply that UDP and TCP port numbers are not a sufficient mechanism to make this link, unless you are willing to limit the set of applications that you plan to support. As he stated quite clearly, the Internet protocol stack permits higher layer protocols to multiplex multiple logical channels across a single IP:port # association. Two very specific examples where the proposed mechanisms fail: 1) Implementations of RFC 1006 - ISO transport on top of TCP. This is heavily used within the DMS infrastructure. It allows multiple users of an OSI application, such as X.500 or X.400, to make OSI transport connections over TCP. For efficiency, most implementations of this service will multiplex all concurrent sessions over a single TCP connection, so there is no way to tell which IP datagram corresponds to which user-level "security association" of the service. 2) NFS. Most implementations of the NFS client operate with a fixed pool of endpoints dedicated to the service. As a further complication, for efficiency, most implementations support read-ahead and write-behind, implemented as a daemon process on behalf of the actual user. Once again it is not possible at the IP layer to determine which user-level security association is responsible for a specific datagram. There are many more examples where Internet services multiplex data from several users across a single IP:port # association. As Perry would say, read the RFCs. Perhaps some of them can be ignored as "not mainstream". Attempts can be made to explain away others, such as the argument that NFS really only works when the client system is fully trusted as part of the same distributed system as the server, so just do host-host authentication and trust the client system to get the user. But in total, all of this ignoring and explaining away greatly limits the set of services that you can offer over a secure IP that supports user-level associations. These quite rightly belong at a higher layer. Charlie Watt SecureWare, Inc. -----END PRIVACY-ENHANCED MESSAGE----- Date: Tue, 20 Aug 1996 11:52:42 -0400 From: "Mitchell C. Nelson" <nelson@mcn.netsec.com> Message-Id: <199608201552.LAA00215@mcn.netsec.com> To: ipsec@TIS.COM Subject: "user" and "network layer", continuation and reply. Sender: ipsec-approval@neptune.tis.com Precedence: bulk Continuing and responding to comments on my email `"user" and "network layer" security': The IP layer as presently defined, is not conditionalized to any next or higher layer protocol. It is defined to provide "connectionless", "unreliable", service between Internet hosts identified by IP address, with fragmentation of datagrams as needed, unless otherwise flagged. These are the basic facts of IP architecture. Most of the discussion group seems to understand the significance of these facts very well. At present (i.e. absent IPSEC), an IP datagram is defined only in terms of src and dst IP addresses, a number representating a next layer protocol, parameters for fragmentation, and a data payload. There is nothing in the definition of the IP layer that is conditionalized to the next layer protocol or to the contents of the data payload. IPSEC deviates from the present network architecture by requiring the IP layer to deal with an additional parameter, the security parameters index (SPI) (more precisely, security parameters and headers principally characterized by an SPI). The extent and consequences of this deviation are related to the extent to which the SPI deviates from directly mapping onto the values already available at the network layer, i.e. <src,dst,prot>. If SPI does not map onto <src,dst,prot>, there are three general types of implementations. The cleanest, and closest to present architecture is that the protocol layer at which the SPI is mapped passes the SPI downward through the stack, to the IP layer. The IP layer then processes the packet using the parameters indicated by the SPI. (As consequences go, this might seem manageable. The basic packet format can still be consistent with much of the presently installed network infrastructure. However, one is entitled to question a network layer security scheme that requires the participation of upper layer entities (other than a key mgt daemon). For example, what security services or benefits can be provided by such a scheme that could not be provided by upper-layer code directly?) To the point at hand, nothing in the network layer architecture even with the added SPI, requires the network layer to deal in the parameters of upper layer protocols. The extension simply requires upper layer protocols to specify an SPI along with addresses, numeric protocol, fragmentation flags, and data. What upper layer parameters the SPI maps to is not information that is needed or dealt with by the network layer. We do not deal with "user" at the network layer. "User" is the business of upper layer protocols. ------------- The following is offered by way of response to some specific points contained in the replies to my posting. (1) From mcr@milkyway.com: "I can see several ways to discuss user based security within current stacks." Evidently, I failed to convey the point in an adequately clear way. (2) From dpkemp@missi.ncsc.mil "IP datagrams can, however, be associated unambiguously with src and dst addresses and port numbers" and, "... IP doesn't need to interpret the entire contents of the blob, just the parts it's interested in." IP doesn't know anything about a "port". "Port" is a parameter defined within *some* transport protocol headers. Regarding the "blob", IP doesn't process the "blob" at all, except to copy it to/from the datagram. (3) xxx@xxx.com writes: "You seem to have missed the point, which is that IPSEC has this notion of "security association" (actually, now its called "Security Parameters" and has the associated "Security Parameters Index"). Why don't you go through the archives instead of making guesses about what you think IPSEC does?" My coments are based on familiarity with the archives, documents, current discussions, and experience. (4) Robert Moskowitz writes: "xxx, people should not have to 'read the archives' for so basic a concept. Maybe it really is too obscure in the architecture RFC. Going to have to reread it :( Yes, Mitchell, IPsec has a concept of a user. This is for setting up security associations between two IP addresses, potentially at the transport layer (rather than as a tunnel). The description of the security association in the RFC documents seems very clear. My point is that the term "user" does not belong in a discussion of network layer security mechanisms. If the SPI is to relate to parameters outside of the network layer, the details of that relationship should still be irrelevant to network layer mechanisms. (The merit of supporting SPI = SPI(...,upper-layer-parameter) in network layer mechanisms, is a related but seperate question.) Regards, Mitch Nelson netsec@panix.com Received: from relay.hq.tis.com by neptune.TIS.COM id aa07576; 20 Aug 96 12:32 EDT Received: by relay.hq.tis.com; id MAA04687; Tue, 20 Aug 1996 12:35:29 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma004665; Tue, 20 Aug 96 12:35:00 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA24725; Tue, 20 Aug 96 12:34:18 EDT Received: by relay.hq.tis.com; id MAA04662; Tue, 20 Aug 1996 12:34:59 -0400 Received: from milkyway.com(198.53.167.2) by relay.tis.com via smap (V3.1.1) id xma004655; Tue, 20 Aug 96 12:34:41 -0400 Received: from jupiter.milkyway.com (jupiter.milkyway.com [192.168.77.9]) by internet with ESMTP (DuhMail/3.0) id MAA21415; Tue, 20 Aug 1996 12:36:10 -0400 Received: from milkyway.com (root@metis.milkyway.com [192.168.77.21]) by jupiter.milkyway.com (8.6.12/8.6.12) with ESMTP id MAA22279 for <ipsec@tis.com>; Tue, 20 Aug 1996 12:34:08 -0400 Received: from metis.milkyway.com by milkyway.com (8.6.12/BSDI-Client) id MAA22626; Tue, 20 Aug 1996 12:33:48 -0400 Message-Id: <199608201633.MAA22626@milkyway.com> X-Mailer: exmh version 1.6.7 5/3/96 X-Face: x7OynEM*dB$e.2'7pigelLk>5:Nu:%r*iV96{F2XIT.apbrc-vOFSi{yI$3=nJ-Qi)allj4 =)4cWlX@IQ1Dsmk}T4qX~{XI5Z01>PV^cYR'~cL]&ma<{rYg~Ao-:~:sM%z}^M65`;1TZ}Tze"4/=F ~o&8;"SKHwB?%"xpP/=pkhdZVP$rQQ{"{QT`#kcx7!\/y+crQa4^nLEms6_k4O*o#fo[WBs~~&.%jf |;W@E2K#{U~%vhvth^uDLWD`<OLQ;48T].laq_}3abY7nO5 X-Uri: http://www.milkyway.com/People/Michael_Richardson/Bio.html To: ipsec@TIS.COM Subject: Re: "user" and "network layer" security mechanisms. References: <9608201409.AA00964@mordred.sware.com> In-Reply-To: Your message of "Tue, 20 Aug 1996 10:09:03 EDT." <9608201409.AA00964@mordred.sware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Aug 1996 12:33:48 -0400 From: Michael Richardson <mcr@milkyway.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk In a galaxy far, far away, Charles Watt <watt@sware.com> says: > Mr. Nelson is quite correct, in spite of the assertions otherwise. > Yes IPSEC has a concept of a security association, which could > conceivably be linked to individual users rather than hosts. But in > order for such a mechanism to be useful for user-level authentication > with an IP security protocol, there must be an unambiguous way to link > each IP datagram protected by the security protocol to a specific user-level > security association. Mr. Nelson's point was simply that UDP and TCP port > numbers are not a sufficient mechanism to make this link, unless you are > willing to limit the set of applications that you plan to support. As he Huh? Who said anything about UDP or TCP? IPsec has an SPI. *That* is the unambiguous link between packets and *all* security associations, whether they be user or node ones. One of my major problems with SKIP is that it effectively kills the SPI as a useful concept. > Two very specific examples where the proposed mechanisms fail: > > 1) Implementations of RFC 1006 - ISO transport on top of TCP. This is > heavily used within the DMS infrastructure. It allows multiple users > of an OSI application, such as X.500 or X.400, to make OSI transport > connections over TCP. For efficiency, most implementations of this > service will multiplex all concurrent sessions over a single TCP > connection, so there is no way to tell which IP datagram corresponds > to which user-level "security association" of the service. I see. This sounds like an application problem. Why is it more efficient to multiplex all sessions over a single TCP session? You've built a tunnel with TCP. Thus, you are reimplementing the network layer, and you will have to implement security there. > 2) NFS. Most implementations of the NFS client operate with a fixed pool > of endpoints dedicated to the service. As a further complication, for NFS is inherently node-to-node as currently *implemented*, not user-to-server. You can not do user level security associations with currently implemented NFS. I suggest you look at AFS. I do not know enough about Sprite's file sharing to comment where it would stand. I wish NFS would go away, but I do not have a better solution yet. Further, NFS doesn't have be implemented the way it is: we *could* push a user-server SA down the through the vnode interface. The write-behind/read-ahead is implemented by "processes" because of the way Unix works. It is implemented as kernel threads on many systems. To: Charles Watt <watt@sware.com> Cc: ipsec@TIS.COM Subject: Re: "user" and "network layer" security mechanisms. Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 20 Aug 1996 12:13:41 -0400 From: "Perry E. Metzger" <perry@piermont.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9608201241.aa07866@neptune.TIS.COM> Charles Watt writes: > Yes IPSEC has a concept of a security association, which could > conceivably be linked to individual users rather than hosts. But in > order for such a mechanism to be useful for user-level authentication > with an IP security protocol, there must be an unambiguous way to link > each IP datagram protected by the security protocol to a specific user-level > security association. The SPI number in the packet is perfectly suitable for this purpose. The real issue is being able to negotiate the use of a particular SPI for a particular connection -- thats a Photuris/Oakley/ISAKMP/Whatever issue. > 2) NFS. Most implementations of the NFS client operate with a fixed pool > of endpoints dedicated to the service. As a further complication, for > efficiency, most implementations support read-ahead and write-behind, > implemented as a daemon process on behalf of the actual user. Once > again it is not possible at the IP layer to determine which user-level > security association is responsible for a specific datagram. NFS is a protocol that isn't suited to securing things on a per-user basis, but the key problem is that all NFS authentication is done (for practical purposes) by the client, with the server trusting that a client that has a file handle is allowed to claim to have any user credential it wants. There is no way, in NFS, to do the "logical thing" and check cryptographic credentials on a per file basis. Perry Date: Tue, 20 Aug 1996 09:00:24 -0700 From: "Michael R. Eisler" <Michael.Eisler@eng.sun.com> Message-Id: <199608201600.JAA28800@dfs-1.eng.sun.com> To: perry@piermont.com, watt@sware.com Subject: Re: "user" and "network layer" security mechanisms. Cc: nelson@mcn.netsec.com, ipsec@TIS.COM, netsec@panix.com X-Sun-Charset: US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk > From watt@sware.com Tue Aug 20 08:07:17 1996 > > > M.C.Nelson <netsec@panix.com> wrote: > > > > > > There is no concept of "user" at the IP layer (i.e. the network layer). > > > [A:] Moreover, there is no clean and reliable way to map from IP datagram to > > > user. Any such code will be problematic unless the functionality of > > > IP is severely altered. [B:] For example, consider a transport protocol > > > that combines service to several users simultaneously. > Mr. Nelson is quite correct, in spite of the assertions otherwise. > Yes IPSEC has a concept of a security association, which could > conceivably be linked to individual users rather than hosts. But in > order for such a mechanism to be useful for user-level authentication > with an IP security protocol, there must be an unambiguous way to link > each IP datagram protected by the security protocol to a specific user-level > security association. Mr. Nelson's point was simply that UDP and TCP port > numbers are not a sufficient mechanism to make this link, unless you are > willing to limit the set of applications that you plan to support. As he > stated quite clearly, the Internet protocol stack permits higher layer > protocols to multiplex multiple logical channels across a single IP:port # > association. > > Two very specific examples where the proposed mechanisms fail: > > 1) Implementations of RFC 1006 - ISO transport on top of TCP. This is > heavily used within the DMS infrastructure. It allows multiple users > of an OSI application, such as X.500 or X.400, to make OSI transport > connections over TCP. For efficiency, most implementations of this > service will multiplex all concurrent sessions over a single TCP > connection, so there is no way to tell which IP datagram corresponds > to which user-level "security association" of the service. > > 2) NFS. Most implementations of the NFS client operate with a fixed pool > of endpoints dedicated to the service. As a further complication, for > efficiency, most implementations support read-ahead and write-behind, > implemented as a daemon process on behalf of the actual user. Once > again it is not possible at the IP layer to determine which user-level > security association is responsible for a specific datagram. Note that even with connection-oriented NFS (NFS on TCP), NFS client implementations typically multiplex traffic from diffrent users to the over the same connection to an NFS server. Some implementations go further and multiplex all traffic, regardless of the number of mounted file systems between a client/server pair over the same connection. Moreover when using TCP, it is possible for the same *datagram* to contain multiple NFS requests, each from different users. > There are many more examples where Internet services multiplex data from > several users across a single IP:port # association. As Perry would say, > read the RFCs. Perhaps some of them can be ignored as "not mainstream". > Attempts can be made to explain away others, such as the argument that NFS ^^^^ > really only works when the client system is fully trusted as part of the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > same distributed system as the server, so just do host-host authentication ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > and trust the client system to get the user. But in total, all of this ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is the case when NFS operates over the AUTH_SYS oncrpc authentication flavor. However, nothing in the NFS architecture precludes a using a flavor that supports a user security association that does not depend on trusting the client host. The ID draft-oncrpc-rpcsec_gss-00.txt proposes a new onc rpc security flavor that uses GSS-API security associations ("contexts" in the parlance used by the CAT working group). > ignoring and explaining away greatly limits the set of services that you can ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I agree, especially after thinking about how to actually implement support for all services, including the two you list. In thinking about how to implement user security associations on operation systems that use asynchronous network I/O, such as Streams, I realize that it introduces several implementation difficulties. Considering the Streams model, one would have to tag each Streams buffer (an mblk) with an identifier that is unique to each user security association. This in theory could be done automatically at the Stream head. I am ignoring the issue of multiple security associations per mblk or what ahppens when one wishes to link mlbks with different tags together for the purpose of transnsmission as one IP datagram. Streams supports a dynamic plumbing model ... applications are free to push and pop modules and link streams at will. Each Streams module would have to agree to copy security association the tag whenever they copy data from one mblk to another. If the modules used Streams APIs like copyb(), and copymsg(), this would not be an issue. But it is not infrequent for modules to allocate mblks and copy them using methods outside the Streams API. One could certainly extend the Streams framework such that it could be sure that all modules on the stack apprehend the notions of the security association tag. But then there is a binary compatibility issue whenever an application pushes a module that hasn't been "IPSECized". Either the framework allows the push, and risks untagged mblks be generated, or it refuses the push. Either way, the application stops working. I am curious if anyone has implemented IPSEC with user-level security associations, and whether the associations are bound at the time the end-point is open or if they are switchable with each outgoing datagram. If the latter, is the I/O framework asynchronous or not? An existance proof might make me less pessimistic about end-user IPSEC. > offer over a secure IP that supports user-level associations. These quite > rightly belong at a higher layer. > > Charlie Watt > SecureWare, Inc. Mike Eisler SunSoft, Inc. Received: from relay.hq.tis.com by neptune.TIS.COM id aa09227; 20 Aug 96 13:27 EDT Received: by relay.hq.tis.com; id NAA06826; Tue, 20 Aug 1996 13:30:29 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma006822; Tue, 20 Aug 96 13:30:22 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA28505; Tue, 20 Aug 96 13:29:24 EDT Received: by relay.hq.tis.com; id NAA06804; Tue, 20 Aug 1996 13:30:03 -0400 Received: from relay.hp.com(15.255.152.2) by relay.tis.com via smap (V3.1.1) id xma006792; Tue, 20 Aug 96 13:29:50 -0400 Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA032122323; Tue, 20 Aug 1996 10:32:04 -0700 Message-Id: <199608201732.AA032122323@relay.hp.com> Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com id AA188112322; Tue, 20 Aug 1996 13:32:02 -0400 To: Michael Richardson <mcr@milkyway.com> Cc: ipsec@TIS.COM Subject: Re: "user" and "network layer" security mechanisms. In-Reply-To: mcr's message of Tue, 20 Aug 1996 12:33:48 -0400. <199608201633.MAA22626@milkyway.com> Date: Tue, 20 Aug 1996 13:32:01 -0400 From: Bill Sommerfeld <sommerfeld@apollo.hp.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk > > 2) NFS. Most implementations of the NFS client operate with a fixed pool > > of endpoints dedicated to the service. As a further complication, for > > NFS is inherently node-to-node as currently *implemented*, not > user-to-server. You can not do user level security associations with currently > implemented NFS. I suggest you look at AFS. I do not know enough about > Sprite's file sharing to comment where it would stand. > I wish NFS would go away, but I do not have a better solution yet. Further, > NFS doesn't have be implemented the way it is: we *could* push a user-server > SA down the through the vnode interface. Actually, you don't need to change the vnode interface at all. All the hair lives below the vnode layer, either in the transport layer (which needs to carry around security associations in about the same way that carries around IP addresses), in the filesystem itself, and in the interfaces between the filesystem, the transport, and the IP layer. To nitpick (I have substantial familiarity with the innards of AFS and DCE/DFS, and once had similar familiarity with NFS): There's already a "credentials" structure pointer in the vnode interface; traditionally, this contains just the effective, real, and saved user-id and group-id set. AFS extends this to also include a "pointer" of sorts to the user's cryptographic credentials. This cred structure can be passed around within the kernel between different kernel threads/processes; in fact, it has to be, because of UNIX permission semantics... file descriptors are capabilities, and the credentials you use for I/O are the ones which were effective at the time open() was called, not the ones which are currently in effect in the current process. Under the vnode layer, this cred pointer can find its way to your "RPC" layer, which can use it to pick the outgoing SA and thus the outbound SPI to use for the request. While SPI's are unidirectional, the key management protocols tend to create them in pairs. A security association thus has *two* SPI's: one inbound, and one outbound. On the server end, the inbound SPI can be used to look up the "real" credentials to use; those credentials are then passed to the vnode ops on the server. The response to the client is sent using the outbound SPI which is paired with the inbound SPI over which the request was received. If you're operating over TCP, this *probably* means that you need separate connection for each user -- but doing this will be a relatively simple change considering the magnitude of other changes needed. If you're operating over UDP, you can probably continue to use the same endpoint for all users, but you need to make sure that the inbound SPI's are carried along with each packet and checked by the receiver. - Bill Received: from relay.hq.tis.com by neptune.TIS.COM id aa09957; 20 Aug 96 13:57 EDT Received: by relay.hq.tis.com; id OAA07611; Tue, 20 Aug 1996 14:00:29 -0400 From: pau@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma007607; Tue, 20 Aug 96 14:00:02 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA00336; Tue, 20 Aug 96 13:59:20 EDT Received: by relay.hq.tis.com; id NAA07596; Tue, 20 Aug 1996 14:00:00 -0400 Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1.1) id xma007587; Tue, 20 Aug 96 13:59:51 -0400 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id OAA18256; Tue, 20 Aug 1996 14:02:41 -0400 Received: from secpwr.watson.ibm.com (secpwr.watson.ibm.com [9.2.24.17]) by mailhub1.watson.ibm.com (8.7.1/08-13-96) with SMTP id OAA15313; Tue, 20 Aug 1996 14:01:56 -0400 Received: by secpwr.watson.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA23236; Tue, 20 Aug 1996 14:02:46 -0400 Date: Tue, 20 Aug 1996 14:02:46 -0400 Message-Id: <9608201802.AA23236@secpwr.watson.ibm.com> To: ipsec@TIS.COM, spatsch@cs.arizona.edu Subject: Re: KEI visa XCHG (ISAKMP & OAKLEY) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Md5: oG0PLyNwqw32iCSOZ+PxDw== Sender: ipsec-approval@neptune.tis.com Precedence: bulk Oliver, how about treating OAKLEY as a "security" protocol" under ISAKMP (like ESP is a "security protocol" for IP.) and treating differnet modes of OAKLEY as the attributes of OAKLEY. In othwer words, we can construct OAKLEY, or any other KEP, and its mode(s) as a ISAKMP proposal. Theefore a KEP can be negotiated just like ESP and its transform. Regards, Pau-Chen > From ipsec-request@neptune.hq.tis.com Fri Aug 16 15:56:26 1996 > X-Authentication-Warning: P-spatsch.cs.arizona.edu: spatsch owned = process doing -bs > Date: Fri, 16 Aug 1996 10:01:56 -0700 (MST) > From: Oliver Spatscheck <spatsch@cs.arizona.edu> > Reply-To: Oliver Spatscheck <spatsch@cs.arizona.edu> > To: ipsec@TIS.COM > Subject: KEI visa XCHG (ISAKMP & OAKLEY) > Message-Id: = <Pine.LNX.3.94.960816095936.1186A-100000@P-spatsch.cs.arizona.edu> > Mime-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=3DUS-ASCII > Sender: ipsec-approval@neptune.hq.tis.com > Precedence: bulk > Content-Length: 2120 > Status: RO >=20 > -----BEGIN PGP SIGNED MESSAGE----- >=20 >=20 > I am just implementing the ISAKMP header and realized that the xchg > field has only 4 bit. This seems to small. The Oakley modes has to be > handled as different exchange types as already mentioned by Mark. >=20 > However counting the 4 reserved exchange types and the 4 Oakley > exchange types there are only 8 other exchange types left. Considering > that we are currently designing a multicast key exchange protocol > using the ISAKMP framework I would strongly recommend to use 16 Bit in > the xchg field of the header. >=20 > Realizing this problem I was thinking about the Oakley KEI and > I don't think Oakley needs it's own KEI. Oakley main mode uses regular > DH key exchange or RSA encryption and the other Oakley modes don't use > key exchange payload at all. >=20 > Therefore a general KEI for DH, RSA encryption and a KEI for no key > exchange payload should be added. >=20 > The ISAKMP draft mentions Oakley multiple times as a key exchange > technique identified by a KEI. This is not true Oakley is a full size > exchange using sa, nonce, id, key exchange, signature and hash > payloads. The combination of selected attributes and used Oakley > mode defines the contents and presence of the hash, id, nonce and > signature payloads. There is no such thing as ONE Oakley KEI. >=20 > I forgot to mention in my last email that I am only implementing the > Oakley exchanges at this point. I am establishing the Phase 1 ISAKMP > SA using Oakley as I am using Oakley to establish the IPSEC SA. >=20 > It would be easy for me to add the ISAKMP exchanges or CISCO exchange. > However they all are less flexible than Oakley. >=20 > Oliver >=20 > - ----- >=20 > Grad student and research assistant in computer science at the = University of Arizona, Tucson, USA > For my PGP public key please check my homepage URL: = http://www.cs.arizona.edu/people/spatsch >=20 >=20 >=20 >=20 >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: 2.6.3i > Charset: noconv >=20 > iQCVAwUBMhSphznVPgUZ7uZJAQEywQQAiE+WqkNsyPzLI4PNpIA8wb6kuKpsBqoZ > 7SNvv9AdBrKdBMVhCYScN03xnZheziU/765u+CD9nZxmBCBaseRA4wGT9sPHLku/ > tE4EVIlTqmQDkrGcn/+w8K0BuJ5iroRWSiiODU+1bkXoRJtwd5m4WAeX2l/uAgMf > ZqBEn4zvfK4=3D > =3Da85z > -----END PGP SIGNATURE----- >=20 >=20 Received: from relay.hq.tis.com by neptune.TIS.COM id aa10418; 20 Aug 96 14:11 EDT Received: by relay.hq.tis.com; id OAA07974; Tue, 20 Aug 1996 14:14:32 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma007959; Tue, 20 Aug 96 14:14:02 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA01391; Tue, 20 Aug 96 14:13:19 EDT Received: by relay.hq.tis.com; id OAA07955; Tue, 20 Aug 1996 14:13:59 -0400 Received: from toxicwaste.mit.edu(18.85.0.40) by relay.tis.com via smap (V3.1.1) id xma007948; Tue, 20 Aug 96 14:13:29 -0400 Received: (from warlord@localhost) by toxicwaste.media.mit.edu (8.6.10/8.6.10) id OAA09658; Tue, 20 Aug 1996 14:15:35 -0400 Message-Id: <199608201815.OAA09658@toxicwaste.media.mit.edu> To: perry@piermont.com Cc: Charles Watt <watt@sware.com>, ipsec@TIS.COM Subject: Re: "user" and "network layer" security mechanisms. In-Reply-To: Your message of "Tue, 20 Aug 1996 12:13:41 EDT." <9608201241.aa07866@neptune.TIS.COM> Date: Tue, 20 Aug 1996 14:15:34 EDT From: Derek Atkins <warlord@mit.edu> Sender: ipsec-approval@neptune.tis.com Precedence: bulk > NFS is a protocol that isn't suited to securing things on a per-user > basis, but the key problem is that all NFS authentication is done (for > practical purposes) by the client, with the server trusting that a > client that has a file handle is allowed to claim to have any user > credential it wants. There is no way, in NFS, to do the "logical > thing" and check cryptographic credentials on a per file basis. Huh? The fact that authentication is done at the client is an implementation detail. It is implement that way, IMHO, because there is no "secure" way for the server to know what access rights the client has. However, that is in no way a requirement of the NFS protocol. You could easily change the RPC Security flavor to do something different and implement the server such that access checks are performed there as well. So, your statement about there being "no way" is just plain wrong. OTOH, it would take a lot of programming to change the implementation to "do the logical thing". But I believe it is possible. -derek Received: from relay.hq.tis.com by neptune.TIS.COM id aa10774; 20 Aug 96 14:22 EDT Received: by relay.hq.tis.com; id OAA08319; Tue, 20 Aug 1996 14:25:32 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma008295; Tue, 20 Aug 96 14:25:02 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA02767; Tue, 20 Aug 96 14:24:19 EDT Received: by relay.hq.tis.com; id OAA08289; Tue, 20 Aug 1996 14:25:00 -0400 Received: from bastion.sware.com(139.131.15.2) by relay.tis.com via smap (V3.1.1) id xma008282; Tue, 20 Aug 96 14:24:53 -0400 Received: from zeus.sware.com (zeus.sware.com [139.131.1.166]) by bastion.sware.com (8.6.12/8.6.5) with ESMTP id OAA29619; Tue, 20 Aug 1996 14:26:51 -0401 Received: by zeus.sware.com (1.39.111.2/2.0) from mordred.sware.com id AA029595386; Tue, 20 Aug 1996 14:23:06 -0400 Received: by mordred.sware.com (5.65/2.1) id AA01416; Tue, 20 Aug 96 14:14:09 -0400 Message-Id: <9608201814.AA01416@mordred.sware.com> Subject: Re: "user" and "network layer" security mechanisms. To: perry@piermont.com Date: Tue, 20 Aug 1996 14:14:08 -0400 (EDT) From: Charles Watt <watt@sware.com> Cc: watt@sware.com, ipsec@TIS.COM In-Reply-To: <199608201613.MAA13992@jekyll.piermont.com> from "Perry E. Metzger" at Aug 20, 96 12:13:41 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 5284 Sender: ipsec-approval@neptune.tis.com Precedence: bulk -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-Certificate: MIIBvzCCAWkCEFmOln6ip0w49CuyWr9vDVUwDQYJKoZIhvcNAQECBQAwWTELMAkG A1UEBhMCVVMxGDAWBgNVBAoTD1NlY3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2Vj dXJlV2FyZSBQQ0ExFzAVBgNVBAsTDkVuZ2luZWVyaW5nIENBMB4XDTk1MDUwODIw MjMzNVoXDTk3MDUwNzIwMjMzNVowcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1Nl Y3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2VjdXJlV2FyZSBQQ0ExFzAVBgNVBAsT DkVuZ2luZWVyaW5nIENBMRUwEwYDVQQDEwxDaGFybGVzIFdhdHQwWTAKBgRVCAEB AgICBANLADBIAkEM2ZSp7b6eqDqK5RbPFpd6DGSLjbpHOZU07pUcdgJXiduj9Ytf 1rsmf/adaplQr+X5FeoIdT/bVSv2MUi3gY0eFwIDAQABMA0GCSqGSIb3DQEBAgUA A0EApEjzeBjiSnGImJXgeY1K8HWSufpJ2DpLBF7DYqqIVAX9H7gmfOJhfeGEYVjK aTxjgASxqHhzkx7PkOnL4JrN+Q== MIC-Info: RSA-MD5,RSA, AsSicdunBDB1fTEjL203HnnGkWbgyYoI8agZmpGNJme1A5ggVXQAlW24/YM2OhTs LU82juyKTXVcoAPbaCHXrE8= >Perry E. Metzger wrote: >> Charles Watt writes: >> Yes IPSEC has a concept of a security association, which could >> conceivably be linked to individual users rather than hosts. But in >> order for such a mechanism to be useful for user-level authentication >> with an IP security protocol, there must be an unambiguous way to link >> each IP datagram protected by the security protocol to a specific user-level >> security association. > >The SPI number in the packet is perfectly suitable for this >purpose. The real issue is being able to negotiate the use of a >particular SPI for a particular connection -- thats a >Photuris/Oakley/ISAKMP/Whatever issue. I think you are missing the point Perry. For example, if you have six concurrent users of an X.400 product that makes use of an RFC 1006 convergence module for its OSI "transport connections", you wind up with user data from six user-level security associations multiplexed over a single TCP connection. Your IPSEC implementation is sitting at the network level to secure outgoing data. It will see a datagram with source address X.X.X.X:1014 (or some other dynamic port number chosen by the local TSAP module for ALL data to destination host's TSAP module) and a destination address of Y.Y.Y.Y:102 (officially assigned tsap port number). This same pair of addresses is the same for all six X.400 users. So which of the six SPI numbers do you put in the IPSEC header??? You don't know at the IP level. Worse yet, what if the data segment contains several TP0 segments from different users? What SPI do you use when the user level data belongs to multiple users? I have been involved with this ongoing problem for five years now, and have only found three solutions: 1) Modify the operating system, protocol stack, and TSAP convergence module to propagate user identity information to the network security layer. This was the wrong choice. It cost too much. 2) Use a higher layer security protocol that has access to user identity. We got it right the second time. 3) Don't use TSAP. This wasn't an option for the billion+ dollar procurement. > >> 2) NFS. Most implementations of the NFS client operate with a fixed pool >> of endpoints dedicated to the service. As a further complication, for >> efficiency, most implementations support read-ahead and write-behind, >> implemented as a daemon process on behalf of the actual user. Once >> again it is not possible at the IP layer to determine which user-level >> security association is responsible for a specific datagram. > >NFS is a protocol that isn't suited to securing things on a per-user >basis, but the key problem is that all NFS authentication is done (for >practical purposes) by the client, with the server trusting that a >client that has a file handle is allowed to claim to have any user >credential it wants. There is no way, in NFS, to do the "logical >thing" and check cryptographic credentials on a per file basis. > And how do you get the file handle? (rhetorical question) The client passes the user's UID and GID in an NFS_LOOKUP (in most cases) request. Should we just believe the offered ids? Or should a reasonable user-level security protocol allow us to cryptographically verify this identity? >Michael.Eisler wrote: > >> From watt@sware.com Tue Aug 20 08:07:17 1996 >> > > M.C.Nelson <netsec@panix.com> wrote: > >> ignoring and explaining away greatly limits the set of services that you can > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >I agree, especially after thinking about how to actually implement >support for all services, including the two you list... ... >I am curious if anyone has implemented IPSEC with user-level security >associations, and whether the associations are bound at the time the >end-point is open or if they are switchable with each outgoing >datagram. If the latter, is the I/O framework asynchronous or not? An >existance proof might make me less pessimistic about end-user IPSEC. I have done something similar. I designed SecureWare's various versions of MaxSix software for multilevel secure networking. The single most costly mistake I have ever made was to include user-level information into the 1.0 MaxSix network layer security protocol. The implications were enormous. Tracking user level information for ALL applications required tremendous modifications to the operating system and protocol stack. This was the primary reason we appended our original design to include two layers of security -- at the network layer we enforced mandatory access control (being data driven a MAC label could be passed without much effort between user process and network layer), with all user-level information, such as authenticated identity, added to a second layer that effectively sat on top of the transport much like the OSI TLSP. This was MUCH cleaner. The bottom line: if you use a network layer security protocol to propagate user-level information, you can cover perhaps 95% of current use (you can invent a number just as easily as I) easily, but you will not be able to cover everything. How critical is this shortfall? Well that's rather dependent upon what you are doing, isn't it? Charles Watt SecureWare -----END PRIVACY-ENHANCED MESSAGE----- Received: from relay.hq.tis.com by neptune.TIS.COM id aa11105; 20 Aug 96 14:34 EDT Received: by relay.hq.tis.com; id OAA08717; Tue, 20 Aug 1996 14:37:30 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma008707; Tue, 20 Aug 96 14:37:01 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA03432; Tue, 20 Aug 96 14:36:19 EDT Received: by relay.hq.tis.com; id OAA08701; Tue, 20 Aug 1996 14:37:00 -0400 Received: from ftp.com(128.127.2.122) by relay.tis.com via smap (V3.1.1) id xma008691; Tue, 20 Aug 96 14:36:30 -0400 Received: from ftp.com by ftp.com ; Tue, 20 Aug 1996 14:38:40 -0400 Received: from athena.ftp.com by ftp.com ; Tue, 20 Aug 1996 14:38:40 -0400 Message-Id: <2.2.32.19960820184342.00ab80cc@mailserv-H.ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 20 Aug 1996 14:43:42 -0400 To: ipsec@TIS.COM From: Naganand Doraswamy <naganand@ftp.com> Subject: AH in tunnel mode Sender: ipsec-approval@neptune.tis.com Precedence: bulk I would like to know what people think about AH in tunnel mode. Ran suggested that I post this to the list to evoke some discussion and then add the following text either in the AH spec or write an informational document on using IPSec to build VPN's. ------------------------------------------------------------------------------ Tunnled AH is useful in a couple of scenarious - Virtual Private Networks: If an organization is geographically separated and all the packets going from one subnet to the other needs to be authencticated, then the packets can be authenticated by the border gateways(routers). This is of value if and only if the border gateways dont accept any unauthenticated packets. The border gateways (routers) MUST NOT be willing to do key management or IPsec with nodes that are not authorised to participate in the VPN. - Road Warrior: If a mobile user is sending packets to the host net, then the user can send authenticated packets tunneled to the border gateway, which can then foward the packets to the hosts behind it. Using AH in tunnel mode has the same security implications as using ESP in tunneled mode (refer to Ran's comments on this). ------------------------------------------------------------------------------ --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) Received: from relay.hq.tis.com by neptune.TIS.COM id aa11654; 20 Aug 96 14:56 EDT Received: by relay.hq.tis.com; id PAA09700; Tue, 20 Aug 1996 15:00:00 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma009692; Tue, 20 Aug 96 14:59:32 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA05378; Tue, 20 Aug 96 14:58:50 EDT Received: by relay.hq.tis.com; id OAA09683; Tue, 20 Aug 1996 14:59:30 -0400 Received: from bastion.sware.com(139.131.15.2) by relay.tis.com via smap (V3.1.1) id xma009676; Tue, 20 Aug 96 14:59:25 -0400 Received: from zeus.sware.com (zeus.sware.com [139.131.1.166]) by bastion.sware.com (8.6.12/8.6.5) with ESMTP id OAA29775; Tue, 20 Aug 1996 14:55:25 -0400 Received: by zeus.sware.com (1.39.111.2/2.0) from mordred.sware.com id AA035367308; Tue, 20 Aug 1996 14:55:09 -0400 Received: by mordred.sware.com (5.65/2.1) id AA01510; Tue, 20 Aug 96 14:46:43 -0400 Message-Id: <9608201846.AA01510@mordred.sware.com> Subject: Re: "user" and "network layer" security mechanisms. To: Michael Richardson <mcr@milkyway.com> Date: Tue, 20 Aug 1996 14:46:43 -0400 (EDT) From: Charles Watt <watt@sware.com> Cc: ipsec@TIS.COM In-Reply-To: <199608201633.MAA22626@milkyway.com> from "Michael Richardson" at Aug 20, 96 12:33:48 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1932 Sender: ipsec-approval@neptune.tis.com Precedence: bulk -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-Certificate: MIIBvzCCAWkCEFmOln6ip0w49CuyWr9vDVUwDQYJKoZIhvcNAQECBQAwWTELMAkG A1UEBhMCVVMxGDAWBgNVBAoTD1NlY3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2Vj dXJlV2FyZSBQQ0ExFzAVBgNVBAsTDkVuZ2luZWVyaW5nIENBMB4XDTk1MDUwODIw MjMzNVoXDTk3MDUwNzIwMjMzNVowcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1Nl Y3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2VjdXJlV2FyZSBQQ0ExFzAVBgNVBAsT DkVuZ2luZWVyaW5nIENBMRUwEwYDVQQDEwxDaGFybGVzIFdhdHQwWTAKBgRVCAEB AgICBANLADBIAkEM2ZSp7b6eqDqK5RbPFpd6DGSLjbpHOZU07pUcdgJXiduj9Ytf 1rsmf/adaplQr+X5FeoIdT/bVSv2MUi3gY0eFwIDAQABMA0GCSqGSIb3DQEBAgUA A0EApEjzeBjiSnGImJXgeY1K8HWSufpJ2DpLBF7DYqqIVAX9H7gmfOJhfeGEYVjK aTxjgASxqHhzkx7PkOnL4JrN+Q== MIC-Info: RSA-MD5,RSA, DKm25f1Al+YilzR4LegqMJhKKvS2GDQEJho8nsyZe59nLzoXodExIBdSFE6cKv9/ pf6m22/3zeAMzU063W96d8Q= > Michael Richardson wrote: > NFS is inherently node-to-node as currently *implemented*, not > user-to-server. You can not do user level security associations with currently > implemented NFS. I suggest you look at AFS. I do not know enough about > Sprite's file sharing to comment where it would stand. > I wish NFS would go away, but I do not have a better solution yet. Further, > NFS doesn't have be implemented the way it is: we *could* push a user-server > SA down the through the vnode interface. The write-behind/read-ahead is > implemented by "processes" because of the way Unix works. It is implemented > as kernel threads on many systems. I play in the NFS source code all the time. You have simply restated my first point -- user level authentication within a network layer security protocol doesn't work with all applications. Point number two: you cannot realistically design a security protocol and expect installed sites to rewrite their applications or move to applications that Michael Richardson considers to be a better solution. The market dynamics are such that if your security solution does not provide adequate security for a customer's network and INSTALLED applications, they will keep their installed applications and get rid of your security solution. I am merely stating observations made over the past seven years of implementing similar network security protocols. If you expect a network layer security protocol to supply user-level authentication, most large sites will not accept the limitations required by the solution. We have sold such a product in the past. Market requirements forced us to a two-layer approach. I don't see the mix of applications being substantially different today. Feel free to disagree and implement user-level security associations within IPSEC. Good luck. Luckily the spec won't force the rest of us into doing so. Charlie Watt SecureWare. -----END PRIVACY-ENHANCED MESSAGE----- Received: from relay.hq.tis.com by neptune.TIS.COM id aa12714; 20 Aug 96 15:34 EDT Received: by relay.hq.tis.com; id PAA10559; Tue, 20 Aug 1996 15:37:30 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma010528; Tue, 20 Aug 96 15:37:03 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA07875; Tue, 20 Aug 96 15:36:20 EDT Received: by relay.hq.tis.com; id PAA10522; Tue, 20 Aug 1996 15:37:00 -0400 Received: from www.borderware.com(199.71.190.98) by relay.tis.com via smap (V3.1.1) id xma010508; Tue, 20 Aug 96 15:36:33 -0400 Received: by janus.border.com id <18474-2>; Tue, 20 Aug 1996 15:38:28 -0400 Message-Id: <96Aug20.153828edt.18474-2@janus.border.com> To: ipsec@TIS.COM Subject: Re: AH in tunnel mode References: <2.2.32.19960820184342.00ab80cc@mailserv-H.ftp.com> In-Reply-To: Your message of "Tue, 20 Aug 1996 14:43:42 -0400". <2.2.32.19960820184342.00ab80cc@mailserv-H.ftp.com> From: "C. Harald Koch" <chk@border.com> Organization: Border Network Technologies Inc. Phone: +1 416 368 7157 X-Uri: <URL:http://www.border.com/homes/chk/> X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Tue, 20 Aug 1996 15:38:19 -0400 Sender: ipsec-approval@neptune.tis.com Precedence: bulk > I would like to know what people think about AH in tunnel mode. Ran > suggested that I post this to the list to evoke some discussion and then add > the following text either in the AH spec or write an informational document > on using IPSec to build VPN's. Is tunnelled AH prohibited anywhere? i.e.: IP[fw1,fw2] | AH | IP[src,dst] | ULP Since AH has a "next hop protocol" field, and a valid protocol is IP (protocol #4), this should work fine (It does in my code :-). Personally, I've *never* understood the emphasis placed on "Transport mode" v.s. "Tunnel mode". There already exists a separate IP in IP document; adding AH and/or ESP between the two IP headers was obvious to me. I understand that specific security issues arise with this configuration, but those should be listed, IMHO, as an implementation note, instead of separating out IP from every other possible "next hop" protocol in the standards. Maybe I'm just missing something obvious. If so, I beg enlightenment... -- C. Harald Koch | Border Network Technologies Inc. chk@border.com | Senior System Developer +1 416 368 7157 (voice) | 20 Toronto Street, Suite 400, Toronto ON M5C 2B8 +1 416 368 7789 (fax) | Madness takes its toll. Please have exact change. Received: from relay.hq.tis.com by neptune.TIS.COM id aa13436; 20 Aug 96 16:09 EDT Received: by relay.hq.tis.com; id QAA11644; Tue, 20 Aug 1996 16:12:30 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma011627; Tue, 20 Aug 96 16:12:03 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA11580; Tue, 20 Aug 96 16:11:21 EDT Received: by relay.hq.tis.com; id QAA11622; Tue, 20 Aug 1996 16:12:00 -0400 Received: from dg-rtp.rtp.dg.com(128.222.1.2) by relay.tis.com via smap (V3.1.1) id xma011617; Tue, 20 Aug 96 16:11:52 -0400 Received: from splinter.rtp.dg.com by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA29013; Tue, 20 Aug 1996 16:14:02 -0400 Received: by splinter.rtp.dg.com (8.6.10/200.15.1.2) id QAA05657; Tue, 20 Aug 1996 16:12:14 -0400 From: Jon Spencer <spencerj@dg-rtp.dg.com> Message-Id: <199608202012.QAA05657@splinter.rtp.dg.com> Subject: Re: "user" and "network layer" security mechanisms. To: Bill Sommerfeld <sommerfeld@apollo.hp.com> Date: Tue, 20 Aug 1996 16:12:11 -0400 (EDT) Cc: mcr@milkyway.com, ipsec@TIS.COM In-Reply-To: <199608201732.AA032122323@relay.hp.com> from "Bill Sommerfeld" at Aug 20, 96 01:32:01 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2203 Sender: ipsec-approval@neptune.tis.com Precedence: bulk > > Actually, you don't need to change the vnode interface at all. All > the hair lives below the vnode layer, either in the transport layer > (which needs to carry around security associations in about the same > way that carries around IP addresses), in the filesystem itself, and > in the interfaces between the filesystem, the transport, and the IP > layer. > > To nitpick (I have substantial familiarity with the innards of AFS and > DCE/DFS, and once had similar familiarity with NFS): > > There's already a "credentials" structure pointer in the vnode > interface; traditionally, this contains just the effective, real, and > saved user-id and group-id set. AFS extends this to also include a > "pointer" of sorts to the user's cryptographic credentials. > > This cred structure can be passed around within the kernel between > different kernel threads/processes; in fact, it has to be, because of > UNIX permission semantics... file descriptors are capabilities, and > the credentials you use for I/O are the ones which were effective at > the time open() was called, not the ones which are currently in effect > in the current process. And what do you do with third party streams multiplexers and/or SMP? Trying to carry around extra credentials, either as an extension to the credentials packet or as a separate structure pointer to by the credentials packet falls apart in this scenario, I do think. As for using the credentials which were effective at open time, this is fine for standard Unix security policies, but as soon as you attempt to deal with the more common current threats such as viruses, administrative threats, internet access to systems with organizational confidential data, then those policies are woefully insufficient, and some current credentials are necessary. -- Jon F. Spencer spencerj@rtp.dg.com (uunet!rtp.dg.com!spencerj) Data General Corp. Phone : (919)248-6246 62 T.W. Alexander Dr, MS #119 FAX : (919)248-6108 Research Triangle Park, NC 27709 Office RTP 121/9 Reality is an illusion - perception is what counts. No success can compensate for failure at home. President David O. McKay ***** UCC 1-207 ******** Received: from relay.hq.tis.com by neptune.TIS.COM id aa13592; 20 Aug 96 16:14 EDT Received: by relay.hq.tis.com; id QAA11817; Tue, 20 Aug 1996 16:18:00 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma011811; Tue, 20 Aug 96 16:17:44 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA12113; Tue, 20 Aug 96 16:16:56 EDT Received: by relay.hq.tis.com; id QAA11798; Tue, 20 Aug 1996 16:17:30 -0400 Received: from p-spatsch.cs.arizona.edu(150.135.1.98) by relay.tis.com via smap (V3.1.1) id xma011788; Tue, 20 Aug 96 16:17:13 -0400 Received: from localhost (spatsch@localhost) by P-spatsch.cs.arizona.edu (8.6.12/8.6.9) with SMTP id KAA04774; Tue, 20 Aug 1996 10:45:27 -0700 X-Authentication-Warning: P-spatsch.cs.arizona.edu: spatsch owned process doing -bs Date: Tue, 20 Aug 1996 10:45:23 -0700 (MST) From: Oliver Spatscheck <spatsch@cs.arizona.edu> To: pau@watson.ibm.com Cc: ipsec@TIS.COM Subject: Re: KEI visa XCHG (ISAKMP & OAKLEY) In-Reply-To: <9608201802.AA23236@secpwr.watson.ibm.com> Message-Id: <Pine.LNX.3.94.960820102744.4155B-100000@P-spatsch.cs.arizona.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Tue, 20 Aug 1996 pau@watson.ibm.com wrote: >Oliver, how about treating OAKLEY as a "security" protocol" under ISAKMP >(like ESP is a "security protocol" for IP.) and treating differnet modes >of OAKLEY as the attributes of OAKLEY. > >In othwer words, we can construct OAKLEY, or any other KEP, >and its mode(s) as a ISAKMP proposal. Theefore a KEP can be negotiated >just like ESP and its transform. > > >Regards, Pau-Chen > If you define the progress of an exchange using the security protocol instead of the xchng field then why should there be an exchange field at all? ISAKMP Base, Identity and Auth only Exchanges could also be defined via the security protocol or as attributes to the ISAKMP proposal. To avoid confusion I would like to mention that Oakley specifies when which payload has to be exchanged. It not only specifies the contents of the payloads. I have a few reasons to oppose this concept. 1. You have to negotiate a proposal before you can start up an exchange adding one message exchange (send/receive SA payload). Otherwise you won't know how to generate/process the other payloads. 2. You allays have to pass the SA payload in clear. (OAKLEY or ISAKMP don't encrypt the FIRST SA payload, but a key exchange framework shouldn't prevent a key exchange protocol from doing so.) 3. You can't demultiplex early by only reading the header to the right state machine for processing. This is an implementation issue but I think an important one. Oliver -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBMhn5tjnVPgUZ7uZJAQFqqAP/VqkRDN0f4bfLk7qP3J86tiXdLflyiY0R K94OuySyCEOOSKTbKPx4H/qzhCrCVLOYEdP0n5/MqNQQjyN3j/y5jZZIsWk8r5tF ml/BtgjDDen/jMSiIXzjf6AYTUregRM0FHNmqZxZd8YGJkJ0AMLvvy/JytrAX2LC RnB6fO+NHc0= =VioU -----END PGP SIGNATURE----- Received: from relay.hq.tis.com by neptune.TIS.COM id aa13591; 20 Aug 96 16:14 EDT Received: by relay.hq.tis.com; id QAA11816; Tue, 20 Aug 1996 16:18:00 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma011810; Tue, 20 Aug 96 16:17:43 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA12111; Tue, 20 Aug 96 16:16:52 EDT Received: by relay.hq.tis.com; id QAA11799; Tue, 20 Aug 1996 16:17:30 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1) id xma011786; Tue, 20 Aug 96 16:16:58 -0400 Received: from maildig1.us.oracle.com by inet-smtp-gw-1.us.oracle.com with SMTP (8.6.12/37.7) id NAA24613; Tue, 20 Aug 1996 13:18:41 -0700 Received: by maildig1.us.oracle.com (5.65v3.2/37.8) id AA03144; Tue, 20 Aug 1996 13:18:33 -0700 Message-Id: <9608202018.AA03144@maildig1.us.oracle.com> Date: 20 Aug 96 13:17:08 -0700 From: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com> To: ipsec@TIS.COM Subject: Re: "user" and "network layer", continuation and reply. X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-request@neptune.hq.tis.com's message of 20-Aug-96 08:52 Mime-Version: 1.0 X-Mailer: Oracle InterOffice (version 2.1.16.0.0) Content-Type: multipart/mixed; boundary="=_ORCL_23978113_0_11919608201419330" Sender: ipsec-approval@neptune.tis.com Precedence: bulk --=_ORCL_23978113_0_11919608201419330 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" On the subject of Ipsec "users: >From: "Mitchell C. Nelson" <nelson@mcn.netsec.com> >... > Evidently, I failed to convey the point in an adequately clear way. I agree. I hope it is clear now that - IPsec processing binds an authenticated packet to a Security Association (SA). The information contained in the SA may provide additional authentication information corresponding to one or more IP addresses, one or more DNS names, or one or more "users". I agree that "user" does not cover this felxibilty well and is confusing ... perhaps the documentation could refer to something obtuse like principles or authenticated entities. Paul -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com !!! Still hiring, send resumes to: palamber@us.oracle.com !!! -------------------------------------------------------------- --=_ORCL_23978113_0_11919608201419330 Content-Type:message/rfc822 Date: 20 Aug 96 08:52:42 From:"Mitchell C. Nelson <nelson@mcn.netsec.com>" <ipsec-request@neptune.hq.tis.com> To:ipsec@tis.com Subject:"user" and "network layer", continuation and reply. Sender:ipsec-approval@neptune.hq.tis.com Precedence: bulk MIME-Version: 1.0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" Continuing and responding to comments on my email `"user" and "network layer" security': The IP layer as presently defined, is not conditionalized to any next or higher layer protocol. It is defined to provide "connectionless", "unreliable", service between Internet hosts identified by IP address, with fragmentation of datagrams as needed, unless otherwise flagged. These are the basic facts of IP architecture. Most of the discussion group seems to understand the significance of these facts very well. At present (i.e. absent IPSEC), an IP datagram is defined only in terms of src and dst IP addresses, a number representating a next layer protocol, parameters for fragmentation, and a data payload. There is nothing in the definition of the IP layer that is conditionalized to the next layer protocol or to the contents of the data payload. IPSEC deviates from the present network architecture by requiring the IP layer to deal with an additional parameter, the security parameters index (SPI) (more precisely, security parameters and headers principally characterized by an SPI). The extent and consequences of this deviation are related to the extent to which the SPI deviates from directly mapping onto the values already available at the network layer, i.e. <src,dst,prot>. If SPI does not map onto <src,dst,prot>, there are three general types of implementations. The cleanest, and closest to present architecture is that the protocol layer at which the SPI is mapped passes the SPI downward through the stack, to the IP layer. The IP layer then processes the packet using the parameters indicated by the SPI. (As consequences go, this might seem manageable. The basic packet format can still be consistent with much of the presently installed network infrastructure. However, one is entitled to question a network layer security scheme that requires the participation of upper layer entities (other than a key mgt daemon). For example, what security services or benefits can be provided by such a scheme that could not be provided by upper-layer code directly?) To the point at hand, nothing in the network layer architecture even with the added SPI, requires the network layer to deal in the parameters of upper layer protocols. The extension simply requires upper layer protocols to specify an SPI along with addresses, numeric protocol, fragmentation flags, and data. What upper layer parameters the SPI maps to is not information that is needed or dealt with by the network layer. We do not deal with "user" at the network layer. "User" is the business of upper layer protocols. ------------- The following is offered by way of response to some specific points contained in the replies to my posting. (1) From mcr@milkyway.com: "I can see several ways to discuss user based security within current stacks." Evidently, I failed to convey the point in an adequately clear way. (2) From dpkemp@missi.ncsc.mil "IP datagrams can, however, be associated unambiguously with src and dst addresses and port numbers" and, "... IP doesn't need to interpret the entire contents of the blob, just the parts it's interested in." IP doesn't know anything about a "port". "Port" is a parameter defined within *some* transport protocol headers. Regarding the "blob", IP doesn't process the "blob" at all, except to copy it to/from the datagram. (3) xxx@xxx.com writes: "You seem to have missed the point, which is that IPSEC has this notion of "security association" (actually, now its called "Security Parameters" and has the associated "Security Parameters Index"). Why don't you go through the archives instead of making guesses about what you think IPSEC does?" My coments are based on familiarity with the archives, documents, current discussions, and experience. (4) Robert Moskowitz writes: "xxx, people should not have to 'read the archives' for so basic a concept. Maybe it really is too obscure in the architecture RFC. Going to have to reread it :( Yes, Mitchell, IPsec has a concept of a user. This is for setting up security associations between two IP addresses, potentially at the transport layer (rather than as a tunnel). The description of the security association in the RFC documents seems very clear. My point is that the term "user" does not belong in a discussion of network layer security mechanisms. If the SPI is to relate to parameters outside of the network layer, the details of that relationship should still be irrelevant to network layer mechanisms. (The merit of supporting SPI = SPI(...,upper-layer-parameter) in network layer mechanisms, is a related but seperate question.) Regards, Mitch Nelson netsec@panix.com --=_ORCL_23978113_0_11919608201419330-- Received: from relay.hq.tis.com by neptune.TIS.COM id aa14021; 20 Aug 96 16:27 EDT Received: by relay.hq.tis.com; id QAA12249; Tue, 20 Aug 1996 16:30:05 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma012233; Tue, 20 Aug 96 16:29:38 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA13217; Tue, 20 Aug 96 16:28:54 EDT Received: by relay.hq.tis.com; id QAA12224; Tue, 20 Aug 1996 16:29:33 -0400 Received: from relay.hp.com(15.255.152.2) by relay.tis.com via smap (V3.1.1) id xma012215; Tue, 20 Aug 96 16:29:13 -0400 Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA221773087; Tue, 20 Aug 1996 13:31:29 -0700 Message-Id: <199608202031.AA221773087@relay.hp.com> Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com id AA225123086; Tue, 20 Aug 1996 16:31:26 -0400 To: Jon Spencer <spencerj@dg-rtp.dg.com> Cc: mcr@milkyway.com, ipsec@TIS.COM Subject: Re: "user" and "network layer" security mechanisms. In-Reply-To: spencerj's message of Tue, 20 Aug 1996 16:12:11 -0400. <199608202012.QAA05657@splinter.rtp.dg.com> Date: Tue, 20 Aug 1996 16:31:25 -0400 From: Bill Sommerfeld <sommerfeld@apollo.hp.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk > And what do you do with third party streams multiplexers and/or SMP? > Trying to carry around extra credentials, either as an extension to the > credentials packet or as a separate structure pointer to by the credentials > packet falls apart in this scenario, I do think. I plead ignorance to the fine implementation details of STREAMS -- there may well need to be an API bump to pass the SA information through. At the worst case, third-party STREAMS modules would lose SA info (and thus wouldn't be able to play nice with user-oriented keying) until they had been tweaked for the new regime. > As for using the credentials which were effective at open time, this is > fine for standard Unix security policies, but as soon as you attempt to > deal with the more common current threats such as viruses, administrative > threats, internet access to systems with organizational confidential data, > then those policies are woefully insufficient, and some current credentials > are necessary. Probably correct, but completely irrelevant to the discussion; the distributed filesystem client can use the ambient credentials as well as the open-time creds to choose the SA to use if it really is relevant.. - Bill Received: from relay.hq.tis.com by neptune.TIS.COM id aa14117; 20 Aug 96 16:30 EDT Received: by relay.hq.tis.com; id QAA12388; Tue, 20 Aug 1996 16:33:33 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma012370; Tue, 20 Aug 96 16:33:10 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA13557; Tue, 20 Aug 96 16:32:23 EDT Received: by relay.hq.tis.com; id QAA12356; Tue, 20 Aug 1996 16:33:03 -0400 Received: from mail11.digital.com(192.208.46.10) by relay.tis.com via smap (V3.1.1) id xma012350; Tue, 20 Aug 96 16:32:56 -0400 Received: from muggsy.lkg.dec.com by mail11.digital.com (8.7.5/UNX 1.2/1.0/WV) id QAA27248; Tue, 20 Aug 1996 16:21:36 -0400 (EDT) Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA07437; Tue, 20 Aug 1996 16:21:33 -0400 Received: from localhost.lkg.dec.com (localhost.lkg.dec.com [127.0.0.1]) by whydos.lkg.dec.com (8.6.12/8.6.12) with SMTP id QAA12066; Tue, 20 Aug 1996 16:25:59 GMT Message-Id: <199608201625.QAA12066@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost.lkg.dec.com didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 To: Charles Watt <watt@sware.com> Cc: ipsec@TIS.COM Subject: Re: "user" and "network layer" security mechanisms. In-Reply-To: Your message of "Tue, 20 Aug 1996 14:14:08 -0400." <9608201814.AA01416@mordred.sware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Aug 1996 16:25:57 +0000 From: Matt Thomas <matt@lkg.dec.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk > I think you are missing the point Perry. For example, if you have six > concurrent users of an X.400 product that makes use of an RFC 1006 > convergence module for its OSI "transport connections", you wind up with > user data from six user-level security associations multiplexed over a > single TCP connection. Sorry, that's impossible. RFC 1006 (and RFC 1859) only allows one OSI transport connection per TCP connection; multiplexing multiple connections is specificly not allowed. Therefore there is always a one-to-one mapping. -- Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. Received: from relay.hq.tis.com by neptune.TIS.COM id aa15310; 20 Aug 96 17:10 EDT Received: by relay.hq.tis.com; id RAA13918; Tue, 20 Aug 1996 17:13:33 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma013908; Tue, 20 Aug 96 17:13:05 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA15667; Tue, 20 Aug 96 17:12:22 EDT Received: by relay.hq.tis.com; id RAA13904; Tue, 20 Aug 1996 17:13:03 -0400 Received: from bastion.sware.com(139.131.15.2) by relay.tis.com via smap (V3.1.1) id xma013898; Tue, 20 Aug 96 17:12:44 -0400 Received: from zeus.sware.com (zeus.sware.com [139.131.1.166]) by bastion.sware.com (8.6.12/8.6.5) with ESMTP id RAA00742; Tue, 20 Aug 1996 17:13:21 -0400 Received: by zeus.sware.com (1.39.111.2/2.0) from mordred.sware.com id AA085655616; Tue, 20 Aug 1996 17:13:36 -0400 Received: by mordred.sware.com (5.65/2.1) id AA01723; Tue, 20 Aug 96 17:05:43 -0400 Message-Id: <9608202105.AA01723@mordred.sware.com> Subject: Re: "user" and "network layer" security mechanisms. To: Matt Thomas <matt@lkg.dec.com> Date: Tue, 20 Aug 1996 17:05:42 -0400 (EDT) From: Charles Watt <watt@sware.com> Cc: watt@sware.com, ipsec@TIS.COM In-Reply-To: <199608201625.QAA12066@whydos.lkg.dec.com> from "Matt Thomas" at Aug 20, 96 04:25:57 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1511 Sender: ipsec-approval@neptune.tis.com Precedence: bulk -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-Certificate: MIIBvzCCAWkCEFmOln6ip0w49CuyWr9vDVUwDQYJKoZIhvcNAQECBQAwWTELMAkG A1UEBhMCVVMxGDAWBgNVBAoTD1NlY3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2Vj dXJlV2FyZSBQQ0ExFzAVBgNVBAsTDkVuZ2luZWVyaW5nIENBMB4XDTk1MDUwODIw MjMzNVoXDTk3MDUwNzIwMjMzNVowcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1Nl Y3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2VjdXJlV2FyZSBQQ0ExFzAVBgNVBAsT DkVuZ2luZWVyaW5nIENBMRUwEwYDVQQDEwxDaGFybGVzIFdhdHQwWTAKBgRVCAEB AgICBANLADBIAkEM2ZSp7b6eqDqK5RbPFpd6DGSLjbpHOZU07pUcdgJXiduj9Ytf 1rsmf/adaplQr+X5FeoIdT/bVSv2MUi3gY0eFwIDAQABMA0GCSqGSIb3DQEBAgUA A0EApEjzeBjiSnGImJXgeY1K8HWSufpJ2DpLBF7DYqqIVAX9H7gmfOJhfeGEYVjK aTxjgASxqHhzkx7PkOnL4JrN+Q== MIC-Info: RSA-MD5,RSA, AVo1Xh4yR+G5j3ixIrot6HfjbqBQoset/frbmjzM2IWwJfxzlUMIisGqa5NoiXnt eaEHfx630VXVlY0KLEun+V8= > Matt Thomas wrote: > > > I think you are missing the point Perry. For example, if you have six > > concurrent users of an X.400 product that makes use of an RFC 1006 > > convergence module for its OSI "transport connections", you wind up with > > user data from six user-level security associations multiplexed over a > > single TCP connection. > > Sorry, that's impossible. RFC 1006 (and RFC 1859) only allows one OSI > transport connection per TCP connection; multiplexing multiple connections > is specificly not allowed. Therefore there is always a one-to-one mapping. Upon review of the spec, you are correct. It appears that my memory is not immune to age afterall. However, I've looked at the source to our vendor's RFC 1006 streams module and the basic problem remains. It internally manages a pool of TCP endpoints, maintaining its own internal binding between TP0 connection and TCP connection. There is no way software at the IP layer can correlate the TCP connection back to the originating process without substantial modification to this product. This renders user-level authentication within IPSEC useless for any application running upon this transport. Pick at the specifics all you want, the basic point remains valid. The Internet stack was designed to permit multiplexing above IP. There are several things out there that do this. User-level authentication within IPSEC cannot work for these products unless they are substantially modified. Charlie Watt SecureWare -----END PRIVACY-ENHANCED MESSAGE----- Received: from relay.hq.tis.com by neptune.TIS.COM id aa15700; 20 Aug 96 17:22 EDT Received: by relay.hq.tis.com; id RAA14285; Tue, 20 Aug 1996 17:26:03 -0400 From: wobber@pa.dec.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma014265; Tue, 20 Aug 96 17:25:34 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA16294; Tue, 20 Aug 96 17:24:52 EDT Received: by relay.hq.tis.com; id RAA14261; Tue, 20 Aug 1996 17:25:33 -0400 Received: from mail1.digital.com(204.123.2.50) by relay.tis.com via smap (V3.1.1) id xma014251; Tue, 20 Aug 96 17:25:23 -0400 Received: from hickory.pa.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA00870; Tue, 20 Aug 1996 14:11:09 -0700 Received: by hickory.pa.dec.com; id AA25177; Tue, 20 Aug 1996 14:11:00 -0700 Message-Id: <9608202111.AA25177@hickory.pa.dec.com> To: Charles Watt <watt@sware.com> Cc: perry@piermont.com, ipsec@TIS.COM Subject: Re: "user" and "network layer" security mechanisms. In-Reply-To: Message of Tue, 20 Aug 1996 14:14:08 -0400 (EDT) from Charles Watt <watt@sware.com> <9608201814.AA01416@mordred.sware.com> Date: Tue, 20 Aug 96 14:11:00 -0700 X-Mts: smtp Sender: ipsec-approval@neptune.tis.com Precedence: bulk Charles Watt says: >> The bottom line: if you use a network layer security protocol to >> propagate user-level information, you can cover perhaps 95% of current >> use (you can invent a number just as easily as I) easily, but you will not >> be able to cover everything. How critical is this shortfall? Well that's >> rather dependent upon what you are doing, isn't it? In a Mandatory Access Control world, perhaps this 5% shortfall is a significant problem. However, in less-rigorous environments it would seem a Good Thing to offer user-level security to a broad majority of applications without inventing yet another security infrastructure at application level. As long as IPSec enables security policies that restrict the form of acceptable SA identities (e.g. to IP addresses), I can see little reason to enforce such a limit by mandate. However, I am concerned about your comments on the cost of "propagating" user-level identity within the network code. How much of this cost do you attribute to the nature of your MAC environment? I imagine that for some protocol elements the job might have been straightforward, and for others not. Does the majority of the cost come from fitting square pegs into round holes? Regards, Ted Wobber DEC Systems Research Center Received: from relay.hq.tis.com by neptune.TIS.COM id aa21910; 20 Aug 96 21:06 EDT Received: by relay.hq.tis.com; id VAA18377; Tue, 20 Aug 1996 21:09:32 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma018375; Tue, 20 Aug 96 21:09:03 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA23224; Tue, 20 Aug 96 21:08:21 EDT Received: by relay.hq.tis.com; id VAA18372; Tue, 20 Aug 1996 21:09:02 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1) id xma018369; Tue, 20 Aug 96 21:08:40 -0400 Received: from maildig1.us.oracle.com by inet-smtp-gw-1.us.oracle.com with SMTP (8.6.12/37.7) id SAA27944; Tue, 20 Aug 1996 18:10:55 -0700 Received: by maildig1.us.oracle.com (5.65v3.2/37.8) id AA16039; Tue, 20 Aug 1996 18:10:48 -0700 Message-Id: <9608210110.AA16039@maildig1.us.oracle.com> Date: 20 Aug 96 18:11:05 -0700 From: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com> To: ipsec@TIS.COM Subject: Re: AH in tunnel mode X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-request@neptune.hq.tis.com's message of 20-Aug-96 12:38 Mime-Version: 1.0 X-Mailer: Oracle InterOffice (version 2.1.16.0.0) Content-Type: multipart/mixed; boundary="=_ORCL_24000549_0_11919608201911480" Sender: ipsec-approval@neptune.tis.com Precedence: bulk --=_ORCL_24000549_0_11919608201911480 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" >Personally, I've *never* understood the emphasis >placed on "Transport mode"v.s. "Tunnel mode". The distinctions came from discussions on the interoperability of "end system" implementations and "intermediate system" implementations. It seems reasonable to require support of a "tunnel mode" in an end system to ensure interoperability of the two types of implementations. End system implementations (aka transport mode) are easily developed that do not support the tunnel mode. Paul -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com !!! Still hiring, send resumes to: palamber@us.oracle.com !!! -------------------------------------------------------------- --=_ORCL_24000549_0_11919608201911480 Content-Type:message/rfc822 Date: 20 Aug 96 12:38:19 From:"C. Harald Koch <chk@border.com>" <ipsec-request@neptune.hq.tis.com> To:ipsec@tis.com Subject:Re: AH in tunnel mode References:<2.2.32.19960820184342.00ab80cc@mailserv-H.ftp.com> In-Reply-To:Your message of "Tue, 20 Aug 1996 14:43:42 -0400". <2.2.32.19960820184342.00ab80cc@mailserv-H.ftp.com> Organization:Border Network Technologies Inc. Phone:+1 416 368 7157 X-Uri:<URL:http://www.border.com/homes/chk/> X-Face:)@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Sender:ipsec-approval@neptune.hq.tis.com Precedence: bulk MIME-Version: 1.0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" > I would like to know what people think about AH in tunnel mode. Ran > suggested that I post this to the list to evoke some discussion and then add > the following text either in the AH spec or write an informational document > on using IPSec to build VPN's. Is tunnelled AH prohibited anywhere? i.e.: IP[fw1,fw2] | AH | IP[src,dst] | ULP Since AH has a "next hop protocol" field, and a valid protocol is IP (protocol #4), this should work fine (It does in my code :-). Personally, I've *never* understood the emphasis placed on "Transport mode" v.s. "Tunnel mode". There already exists a separate IP in IP document; adding AH and/or ESP between the two IP headers was obvious to me. I understand that specific security issues arise with this configuration, but those should be listed, IMHO, as an implementation note, instead of separating out IP from every other possible "next hop" protocol in the standards. Maybe I'm just missing something obvious. If so, I beg enlightenment... -- C. Harald Koch | Border Network Technologies Inc. chk@border.com | Senior System Developer +1 416 368 7157 (voice) | 20 Toronto Street, Suite 400, Toronto ON M5C 2B8 +1 416 368 7789 (fax) | Madness takes its toll. Please have exact change. --=_ORCL_24000549_0_11919608201911480-- Received: from relay.hq.tis.com by neptune.TIS.COM id aa14604; 20 Aug 96 16:46 EDT Received: by relay.hq.tis.com; id QAA13297; Tue, 20 Aug 1996 16:49:03 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma013291; Tue, 20 Aug 96 16:48:52 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA14478; Tue, 20 Aug 96 16:47:58 EDT Received: by relay.hq.tis.com; id QAA13278; Tue, 20 Aug 1996 16:48:36 -0400 Received: from mercury.sun.com(192.9.25.1) by relay.tis.com via smap (V3.1.1) id xma013272; Tue, 20 Aug 96 16:48:19 -0400 Received: by mercury.Sun.COM (Sun.COM) id NAA24093; Tue, 20 Aug 1996 13:50:34 -0700 Received: from pacific.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA24557; Tue, 20 Aug 1996 13:50:11 -0700 Received: from dfs-1.eng.sun.com by pacific.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA17085; Tue, 20 Aug 1996 13:49:52 -0700 Received: by dfs-1.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA29148; Tue, 20 Aug 1996 13:48:08 -0700 Date: Tue, 20 Aug 1996 13:48:08 -0700 From: "Michael R. Eisler" <Michael.Eisler@eng.sun.com> Message-Id: <199608202048.NAA29148@dfs-1.eng.sun.com> To: watt@sware.com, perry@piermont.com, mcr@milkyway.com Subject: Re: "user" and "network layer" security mechanisms. Cc: ipsec@TIS.COM X-Sun-Charset: US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk > From perry@piermont.com Tue Aug 20 10:31:38 1996 > NFS is a protocol that isn't suited to securing things on a per-user > basis, but the key problem is that all NFS authentication is done (for > practical purposes) by the client, with the server trusting that a > client that has a file handle is allowed to claim to have any user > credential it wants. There is no way, in NFS, to do the "logical > thing" and check cryptographic credentials on a per file basis. NFS implementations have been checking cryptographic credentials a per file, user, and NFS request basis for nearly 10 years. That is what NFS on AUTH_DES (rechristened AUTH_DH in a oncrpc wg draft of an informational RFC) does. Ditto NFS on AUTH_KERB (Kerberos v4), since 1992. > From mcr@milkyway.com Tue Aug 20 10:16:17 1996 >> Two very specific examples where the proposed mechanisms fail: >> >> 1) Implementations of RFC 1006 - ISO transport on top of TCP. This is >> heavily used within the DMS infrastructure. It allows multiple users >> of an OSI application, such as X.500 or X.400, to make OSI transport >> connections over TCP. For efficiency, most implementations of this >> service will multiplex all concurrent sessions over a single TCP >> connection, so there is no way to tell which IP datagram corresponds >> to which user-level "security association" of the service. > I see. This sounds like an application problem. Why is it more efficient > to multiplex all sessions over a single TCP session? You've built a tunnel > with TCP. Thus, you are reimplementing the network layer, and you will > have to implement security there. It is more efficient because additional TCP connections take up more resources. Multiple TCP connections between the same client and server will unnecessarily introduce scalability problems. For example, in a multithreaded environment, where creating a new connection may require getting the write side of a multi-reader/single write lock. As the # of connections grows, so does the latency for creating the connection. Finally, using a single TCP connection reduces congestion over slow/lossy routes. > > 2) NFS. Most implementations of the NFS client operate with a fixed pool > > of endpoints dedicated to the service. As a further complication, for > > NFS is inherently node-to-node as currently *implemented*, not > user-to-server. You can not do user level security associations with currently see my previous comments on AUTH_DH and AUTH_KERB. > implemented NFS. I suggest you look at AFS. I do not know enough about > Sprite's file sharing to comment where it would stand. > I wish NFS would go away, but I do not have a better solution yet. Further, > NFS doesn't have be implemented the way it is: we *could* push a user-server NFS and AFS make use of the same vnode interfaces to access security associations. The vnode interfaces all take a credential pointer that has UNIX uid, gid, gid array etc. information. When NFS uses AUTH_DES and AUTH_KERB, it simply takes the UNIX uid and maps to the security association via one stored in an in-kernel cache, or if not cached, via an upcall to the user-level helper daemon. AFS implementations go one step futher to note that a particular UNIX user may want to assume more than one "role". So the cred is either extended to contain the role identfier, or a gid array entry is overloaded to contain the role identifier. > SA down the through the vnode interface. The write-behind/read-ahead is > implemented by "processes" because of the way Unix works. It is implemented > as kernel threads on many systems. Simply attaching the UNIX credential or the security association to each enqueued asynchornous NFS read-ahead or write-behind solves this, regardless whether one uses threads or processes. -mre Received: from relay.hq.tis.com by neptune.TIS.COM id aa17024; 20 Aug 96 18:14 EDT Received: by relay.hq.tis.com; id SAA15806; Tue, 20 Aug 1996 18:17:30 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma015802; Tue, 20 Aug 96 18:17:06 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA19610; Tue, 20 Aug 96 18:16:19 EDT Received: by relay.hq.tis.com; id SAA15798; Tue, 20 Aug 1996 18:16:59 -0400 Received: from soscorp.soscorp.com(204.52.248.130) by relay.tis.com via smap (V3.1.1) id xma015791; Tue, 20 Aug 96 18:16:31 -0400 Received: from fearless.soscorp.com (fearless.soscorp.com [204.52.249.130]) by brimstone.soscorp.com ($Revision: 2.30 $/8.6.12/8.6.4.287) with BSMTP id BS0025775/SAA25778; Tue, 20 Aug 1996 18:18:44 -0400 Received: from fearless.soscorp.com (aggelos@localhost) by fearless.soscorp.com (8.6.12/8.6.4.287) with ESMTP id SAA29981; Tue, 20 Aug 1996 18:18:11 -0400 Message-Id: <199608202218.SAA29981@fearless.soscorp.com> To: Charles Watt <watt@sware.com> Cc: Matt Thomas <matt@lkg.dec.com>, ipsec@TIS.COM Subject: Re: "user" and "network layer" security mechanisms. In-Reply-To: Your message of "Tue, 20 Aug 1996 17:05:42 EDT." <9608202105.AA01723@mordred.sware.com> Date: Tue, 20 Aug 1996 18:18:05 -0400 From: "Angelos D. Keromytis" <aggelos@soscorp.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In message <9608202105.AA01723@mordred.sware.com>, Charles Watt writes: > >Pick at the specifics all you want, the basic point remains valid. The >Internet stack was designed to permit multiplexing above IP. There are >several things out there that do this. User-level authentication within >IPSEC cannot work for these products unless they are substantially >modified. > But what you're talking about is multiplexing above TCP. In any case, i think user-level authentication will require specially modified/writen applications, but that's no reason not to support it. - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBMho5mb0pBjh2h1kFAQEdrwP9GTeRv02XaY5Jj5Gujnn7Y8QAXM2zhtku 6vrBiVJO09nWkf8pKAYjidXflSA+zxKnJjGJ6u+kr9Dgo9l3bmt31wtVzryam93E RGjgkjapceBj0Mc5smYVPR70rP66TWtlgb8hyIcNW8gLKGlLYzv5tNL6zH5NDz3K LM8A52b4vyk= =eA5h -----END PGP SIGNATURE----- Received: from relay.hq.tis.com by neptune.TIS.COM id aa21044; 20 Aug 96 20:34 EDT Received: by relay.hq.tis.com; id UAA18060; Tue, 20 Aug 1996 20:38:02 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma018055; Tue, 20 Aug 96 20:37:33 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA22717; Tue, 20 Aug 96 20:36:51 EDT Received: by relay.hq.tis.com; id UAA18048; Tue, 20 Aug 1996 20:37:32 -0400 Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1.1) id xma018044; Tue, 20 Aug 96 20:37:13 -0400 Received: (rja@localhost) by puli.cisco.com (8.6.12/8.6.5) id RAA01482; Tue, 20 Aug 1996 17:38:14 -0700 Date: Tue, 20 Aug 1996 17:38:14 -0700 From: Ran Atkinson <rja@cisco.com> Message-Id: <199608210038.RAA01482@puli.cisco.com> To: wobber@pa.dec.com Subject: Re: "user" and "network layer" security mechanisms. In-Reply-To: <9608202111.AA25177@hickory.pa.dec.com> References: <watt@sware.com> <9608201814.AA01416@mordred.sware.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk In article <9608202111.AA25177@hickory.pa.dec.com> Ted Wobber wrote: >In a Mandatory Access Control world, perhaps this 5% shortfall is >a significant problem. In a MAC environment, such as a CMW, it is a hard requirement in the TCSEC (including derivatives such as Red Book and equivalent specifications) that the security attributes of objects be dependably propogated to all the legitimately communicating endpoints. Identity of the SA is just another security attribute to propogate. MAC controls already require significant changes deep inside TCP/IP stacks. (e.g. so that IP packets get correctly labeled using IPSO). Those changes are so significant that it shouldn't be much additional work to add IPsec with user-oriented keying as well. As one of the few people on this list who have actually written both IPsec code and MLS OS code, this is not idle speculation on my part. I'm pretty sure that I could implement it inside BLS 8.09, for example, (if I had access to BLS source code). It is possible to design an MLS OS that makes IPsec difficult, but the problem there is poor OS design not the IPsec per se. It is similarly possible to design an OS that makes networking protocols difficult, but that doesn't mean the TCP/IP specs are bad. Now in non-MLS systems, unique SAs are also not very hard to implement. The NRL IPsec code has always supported them, by way of providing an existence proof. >However, I am concerned about your comments on the cost of "propagating" >user-level identity within the network code. How much of this cost >do you attribute to the nature of your MAC environment? I imagine >that for some protocol elements the job might have been straightforward, >and for others not. Does the majority of the cost come from fitting >square pegs into round holes? Using BSD as an example, the kernel knows which process opened a socket and also can dependably determine which uid owns that process, thereby determining which uid should be associated with that socket. A privileged process can fork/exec and change its identity after the socket has opened, but this is not necessarily a security problem since it is a _privileged_ process. If an unprivileged process can change its identity at will, then there are bigger security problems within that system than IPsec could hope to help with. In the BSD code, one can store security information about a socket inside socket state. A pointer to that socket state can be added to the mbuf chain that travels downward through the system. At points where the per-socket security information needs to be checked, the backpointer can be used to read it from socket state. Inbound data first gets checked against the minimum system security level roughly during ip input processing. It gets checked a second time, now against the security information stored in the destination socket state, just before its handed up to the application. Adding identity information to the security information associated with a socket is straight-forward. Ran rja@cisco.com Received: from relay.hq.tis.com by neptune.TIS.COM id aa01273; 21 Aug 96 2:51 EDT Received: by relay.hq.tis.com; id CAA21186; Wed, 21 Aug 1996 02:54:50 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma021181; Wed, 21 Aug 96 02:54:23 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA28668; Wed, 21 Aug 96 02:53:39 EDT Received: by relay.hq.tis.com; id CAA21176; Wed, 21 Aug 1996 02:54:20 -0400 Received: from radmail.rad.co.il(192.114.26.219) by relay.tis.com via smap (V3.1.1) id xma021172; Wed, 21 Aug 96 02:54:04 -0400 Received: from radguard.com ([192.114.26.210]) by radmail.rad.co.il (post.office MTA v1.9.3 ID# 0-12126) with SMTP id AAA29053; Wed, 21 Aug 1996 09:58:09 +0300 Received: by radguard.com (4.1/SMI-4.1) id AA01075; Wed, 21 Aug 96 09:56:45 IDT Received: from elgamal.radguard.co.il(192.114.33.2) by gatekeeper.radguard.com via smap (V1.3) id sma001073; Wed Aug 21 09:56:43 1996 Received: by elgamal.radguard.com (4.1/SMI-4.1) id AA12071; Wed, 21 Aug 96 09:56:54 IDT Date: Wed, 21 Aug 1996 09:56:54 +0300 (IDT) From: Dan Frommer <dan@radguard.com> To: Naganand Doraswamy <naganand@ftp.com> Cc: ipsec@TIS.COM Subject: Re: AH in tunnel mode In-Reply-To: <2.2.32.19960820184342.00ab80cc@mailserv-H.ftp.com> Message-Id: <Pine.SUN.3.91.960821092245.11256D-100000@elgamal.radguard.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk On Tue, 20 Aug 1996, Naganand Doraswamy wrote: > I would like to know what people think about AH in tunnel mode. Ran > suggested that I post this to the list to evoke some discussion and then add > the following text either in the AH spec or write an informational document > on using IPSec to build VPN's. > I believe tunnel mode in AH should be supported for the same reasons it is supported in ESP. However, the existing drafts/RFCs should be made clear in this area. Specifically, the following should be removed from the architecture draft: "While the Authentication Header might be implemented by a security gateway on behalf of hosts on a trusted network behind that security gateway, this mode of operation is not encouraged." Tunnel mode in ESP is explicitly discussed in the drafts while the AH documents seem to focus on "upper protocols". I vote for changing this. Dan Dan Frommer | Voice: +972-3-645-5396 | Email: dan@radguard.com RADGUARD, Ltd. | Fax: +972-3-648-0859 | Received: from relay.hq.tis.com by neptune.TIS.COM id aa03901; 21 Aug 96 4:21 EDT Received: by relay.hq.tis.com; id EAA21560; Wed, 21 Aug 1996 04:04:50 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma021558; Wed, 21 Aug 96 04:04:22 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA29585; Wed, 21 Aug 96 04:03:39 EDT Received: by relay.hq.tis.com; id EAA21555; Wed, 21 Aug 1996 04:04:20 -0400 Received: from grosses-raetsel-tor.genua.de(193.141.169.26) by relay.tis.com via smap (V3.1.1) id xma021545; Wed, 21 Aug 96 04:03:59 -0400 Received: (from smap@localhost) by Grosses-Raetsel-Tor.GeNUA.DE (8.6.12/8.6.12) id KAA26901; Wed, 21 Aug 1996 10:06:08 +0200 Received: from auryn.genua.de(192.109.217.42) by Grosses-Raetsel-Tor.GeNUA.DE via smap (V1.3) id sma026897; Wed Aug 21 10:05:58 1996 Received: from auryn.genua.de (localhost [127.0.0.1]) by auryn.genua.de (8.7.4/8.7.3) with ESMTP id KAA23262; Wed, 21 Aug 1996 10:05:47 +0200 (MET DST) Message-Id: <199608210805.KAA23262@auryn.genua.de> To: Naganand Doraswamy <naganand@ftp.com> Cc: ipsec@TIS.COM Subject: Re: AH in tunnel mode In-Reply-To: Your message of Tue, 20 Aug 1996 14:43:42 -0400. <2.2.32.19960820184342.00ab80cc@mailserv-H.ftp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <23259.840614746.1@auryn.genua.de> Date: Wed, 21 Aug 1996 10:05:46 +0200 From: Bernhard Schneck <Bernhard_Schneck@genua.de> MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk In message <2.2.32.19960820184342.00ab80cc@mailserv-H.ftp.com>you write: > - Virtual Private Networks: If an organization is geographically separated > and all the packets going from one subnet to the other needs to be > authencticated, then the packets can be authenticated by the border > gateways(routers). This is of value if and only if the border gateways dont > accept any unauthenticated packets. The border gateways (routers) MUST NOT > be willing to do key management or IPsec with nodes that are not authorised > to participate in the VPN. I assume if a filtering component supports tunnel mode AH, it will have the capability to distinguish between packets received with and without AH and combine this with IP filtering. Eg: allow from <remote subnet> to <local subnet> if AH deny from <remote subnet> to <local subnet> without AH Anyone trying to spoof remote subnet addresses would have to spoof AH. This should provide sufficient protection (IMHO, iff we trust AH). As to doing key management with other entities, if you want to do that you'll have to include filtering capabilities on SAs/SPIs (``I'll do AH with anyone, but they won't be able use <remote subent> adresses unless they use the SPI associated with that net''). \Bernhard. Received: from relay.hq.tis.com by neptune.TIS.COM id aa12879; 21 Aug 96 9:41 EDT Received: by relay.hq.tis.com; id JAA26585; Wed, 21 Aug 1996 09:44:51 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma026578; Wed, 21 Aug 96 09:44:23 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA10586; Wed, 21 Aug 96 09:43:40 EDT Received: by relay.hq.tis.com; id JAA26569; Wed, 21 Aug 1996 09:44:21 -0400 Received: from guardian.guard.ncsc.mil(144.51.52.1) by relay.tis.com via smap (V3.1.1) id xma026556; Wed, 21 Aug 96 09:43:53 -0400 Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id JAA19359 for <ipsec@TIS.COM>; Wed, 21 Aug 1996 09:46:06 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma019355; Wed Aug 21 09:45:52 1996 Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id JAA21082 for <ipsec@TIS.COM>; Wed, 21 Aug 1996 09:42:35 -0400 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id JAA16060; Wed, 21 Aug 1996 09:45:42 -0400 Date: Wed, 21 Aug 1996 09:45:42 -0400 From: "David P. Kemp" <dpkemp@missi.ncsc.mil> Message-Id: <199608211345.JAA16060@argon.ncsc.mil> To: ipsec@TIS.COM Subject: Re: "user" and "network layer" security mechanisms. X-Sun-Charset: US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk > From: Charles Watt <watt@sware.com> > > Pick at the specifics all you want, the basic point remains valid. The > Internet stack was designed to permit multiplexing above IP. There are > several things out there that do this. User-level authentication within > IPSEC cannot work for these products unless they are substantially > modified. That point is not specific to IP, and no "additional restrictions" you could place on IP or IPX or any other layer 3 protocol can prevent tunnelling (and therefore multiplexing) through it - all communication channels are equivalent. If you have a hypothetical "secure" system that permits only bidirectional SMTP email, you can still establish IP dataflow through it, and (with appropriate adjustment of timeouts), TCP connections as well :-). Stick a PPP connection on top of that, and you've got a layer 2 link running over a layer 7 protocol. The nesting could continue ad infinitum. So what? The discussion seems to be motivated from two different viewpoints: Mitch and Charlie say that there is no way to attach contexts or SPIs to IP packets in a manner that will guarantee 100% MAC-grade cryptographic separation based on anything other than IP addresses. This is correct - there is only one SPI per IP packet, and if data from two different "users" is placed into the packet, it must be separated using some other mechanism. They then argue that because IP-layer mechanisms cannot in general do MAC based on anything other than IP addresses (a correct assertion), that the IP protocol should not be permitted to use SPIs based on "users" or "authenticated entities" or anything other than src and dst IP addresses. That is the bottom-up view: design IP so that it advertises a simple capability, and provides near-100% assurance that it does what it claims to do. The other viewpoint is top-down: there is a huge universe of applications running on real customer networks that need to be "secured". We could do it by modifying every single application and every application protocol to provide security services at the highest layer, or we could recognize that application protocols fall into classes, and that for some classes (those that don't multiplex services for multiple "users" through a single connection or process), a common IP-layer mechanism can be used without modifying the higher layer protocols. Therefore it is reasonable to provide the mechanism (an SPI field in the IP packet) that can in some cases be used to achieve separation between "users" at the network layer. There is a unique window of opportunity where the entire industry will replace their IP stacks and kernel code to accommodate IPv4/IPsec or IPv6. It makes sense to make the kernel-level code as general as possible while that window is open. If we later find that nearly all applications have become RPC-based and subject to RPC security mechanisms, and user-based IP keying is not worth the effort, then the key management daemons can be yanked and replaced with something trivial that does keying based on IP addresses. In that case the SPI becomes redundant but harmless (and it still provides an efficiency benefit over using IP addresses directly to look up SAs for each packet). Received: from relay.hq.tis.com by neptune.TIS.COM id aa13869; 21 Aug 96 10:23 EDT Received: by relay.hq.tis.com; id KAA28145; Wed, 21 Aug 1996 10:26:54 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma028139; Wed, 21 Aug 96 10:26:23 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA13398; Wed, 21 Aug 96 10:25:40 EDT Received: by relay.hq.tis.com; id KAA28136; Wed, 21 Aug 1996 10:26:21 -0400 Received: from ftp.com(128.127.2.122) by relay.tis.com via smap (V3.1.1) id xma028130; Wed, 21 Aug 96 10:26:01 -0400 Received: from ftp.com by ftp.com ; Wed, 21 Aug 1996 10:28:09 -0400 Received: from athena.ftp.com by ftp.com ; Wed, 21 Aug 1996 10:28:09 -0400 Message-Id: <2.2.32.19960821143312.00afc928@mailserv-H.ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 Aug 1996 10:33:12 -0400 To: "C. Harald Koch" <chk@border.com> From: Naganand Doraswamy <naganand@ftp.com> Subject: Re: AH in tunnel mode Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk >Is tunnelled AH prohibited anywhere? i.e.: > > IP[fw1,fw2] | AH | IP[src,dst] | ULP > >Since AH has a "next hop protocol" field, and a valid protocol is IP >(protocol #4), this should work fine (It does in my code :-). > No, it is not prohibited anywhere. Just that it is not specificed anywhere! --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) To: "Mitchell C. Nelson" <nelson@mcn.netsec.com> Cc: ipsec@TIS.COM Subject: Re: "user" and "network layer", continuation and reply. Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 21 Aug 1996 10:26:31 -0400 From: "Perry E. Metzger" <perry@piermont.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9608211033.aa14042@neptune.TIS.COM> "Mitchell C. Nelson" writes: > My point is that the term "user" does not belong in a discussion > of network layer security mechanisms. I'm afraid it does, because security models have to deal with the notion of user. See, for example, the entire issue of mutually hostile users (and cut and paste attacks). Discussion of the security properties of the system under such circumstances mandates the inclusion of a notion of the user. It is impossible to discuss the question of a cryptographic system's security absent a discussion of which entities are doing the encrypting and holding the keys. As it stands, IPSEC has been engineered so that a key management protocol (like Photuris or Oakley) may exchange keys that are assigned TO USERS, and use them to set up SPIs for use with specific machine-to-machine connections. You may feel that "this does not belong" or some such, but I'm afraid its what we are doing, and frankly I don't understand whats wrong with it. Perry Received: from relay.hq.tis.com by neptune.TIS.COM id aa14307; 21 Aug 96 10:43 EDT Received: by relay.hq.tis.com; id KAA29087; Wed, 21 Aug 1996 10:46:52 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma029063; Wed, 21 Aug 96 10:46:26 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA14718; Wed, 21 Aug 96 10:45:41 EDT Received: by relay.hq.tis.com; id KAA29051; Wed, 21 Aug 1996 10:46:22 -0400 Received: from bastion.sware.com(139.131.15.2) by relay.tis.com via smap (V3.1.1) id xma029041; Wed, 21 Aug 96 10:45:53 -0400 Received: from zeus.sware.com (zeus.sware.com [139.131.1.166]) by bastion.sware.com (8.6.12/8.6.5) with ESMTP id KAA03560; Wed, 21 Aug 1996 10:45:26 -0400 Received: by zeus.sware.com (1.39.111.2/2.0) from mordred.sware.com id AA063608741; Wed, 21 Aug 1996 10:45:41 -0400 Received: by mordred.sware.com (5.65/2.1) id AA03215; Wed, 21 Aug 96 10:37:31 -0400 Message-Id: <9608211437.AA03215@mordred.sware.com> Subject: Re: "user" and "network layer" security mechanisms. To: Ran Atkinson <rja@cisco.com> Date: Wed, 21 Aug 1996 10:37:30 -0400 (EDT) From: Charles Watt <watt@sware.com> Cc: wobber@pa.dec.com, ipsec@TIS.COM In-Reply-To: <199608210038.RAA01482@puli.cisco.com> from "Ran Atkinson" at Aug 20, 96 05:38:14 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 3846 Sender: ipsec-approval@neptune.tis.com Precedence: bulk -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-Certificate: MIIBvzCCAWkCEFmOln6ip0w49CuyWr9vDVUwDQYJKoZIhvcNAQECBQAwWTELMAkG A1UEBhMCVVMxGDAWBgNVBAoTD1NlY3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2Vj dXJlV2FyZSBQQ0ExFzAVBgNVBAsTDkVuZ2luZWVyaW5nIENBMB4XDTk1MDUwODIw MjMzNVoXDTk3MDUwNzIwMjMzNVowcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1Nl Y3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2VjdXJlV2FyZSBQQ0ExFzAVBgNVBAsT DkVuZ2luZWVyaW5nIENBMRUwEwYDVQQDEwxDaGFybGVzIFdhdHQwWTAKBgRVCAEB AgICBANLADBIAkEM2ZSp7b6eqDqK5RbPFpd6DGSLjbpHOZU07pUcdgJXiduj9Ytf 1rsmf/adaplQr+X5FeoIdT/bVSv2MUi3gY0eFwIDAQABMA0GCSqGSIb3DQEBAgUA A0EApEjzeBjiSnGImJXgeY1K8HWSufpJ2DpLBF7DYqqIVAX9H7gmfOJhfeGEYVjK aTxjgASxqHhzkx7PkOnL4JrN+Q== MIC-Info: RSA-MD5,RSA, AWd7XZSqrLcfeKkY0N7/FKl/aheROPx38aIYGK+TN5naLv38zvqbH8Ofrk22FKtZ BqqzUxt2qwYySKMBl7zz42U= >Ran Atkinson wrote: > >In article <9608202111.AA25177@hickory.pa.dec.com> Ted Wobber wrote: >>In a Mandatory Access Control world, perhaps this 5% shortfall is >>a significant problem. > >In a MAC environment, such as a CMW, it is a hard requirement in the TCSEC >(including derivatives such as Red Book and equivalent specifications) that >the security attributes of objects be dependably propogated to all the >legitimately communicating endpoints. > >Identity of the SA is just another security attribute to propogate. MAC >controls already require significant changes deep inside TCP/IP stacks. >(e.g. so that IP packets get correctly labeled using IPSO). Those changes are >so significant that it shouldn't be much additional work to add IPsec with >user-oriented keying as well. > >As one of the few people on this list who have actually written both >IPsec code and MLS OS code, this is not idle speculation on my part. >I'm pretty sure that I could implement it inside BLS 8.09, for example, >(if I had access to BLS source code). So have I. I also wrote most of the BLS 8.09 networking code. It is precisely this experience that makes me rather insistent on this issue. Adding user-level SA tracking as another security attribute within an MLS stack would be easy -- only because they have invested tremendously in building an infrastructure to pass such attributes up and down the stack. >Now in non-MLS systems, unique SAs are also not very hard to implement. The >NRL IPsec code has always supported them, by way of providing an existence >proof. > >>However, I am concerned about your comments on the cost of "propagating" >>user-level identity within the network code. How much of this cost >>do you attribute to the nature of your MAC environment? I imagine >>that for some protocol elements the job might have been straightforward, >>and for others not. Does the majority of the cost come from fitting >>square pegs into round holes? > >Using BSD as an example, the kernel knows which process opened a socket and >also can dependably determine which uid owns that process, thereby determining >which uid should be associated with that socket. A privileged process can >fork/exec and change its identity after the socket has opened, but this is not >necessarily a security problem since it is a _privileged_ process. If an >unprivileged process can change its identity at will, then there are bigger >security problems within that system than IPsec could hope to help with. > >In the BSD code, one can store security information about a socket inside >socket state. A pointer to that socket state can be added to the mbuf chain >that travels downward through the system. At points where the per-socket >security information needs to be checked, the backpointer can be used to read >it from socket state. Inbound data first gets checked against the minimum >system security level roughly during ip input processing. It gets checked a >second time, now against the security information stored in the destination >socket state, just before its handed up to the application. Adding identity >information to the security information associated with a socket is >straight-forward. And then again, there are services that manage a pool of sockets within the kernel, such as any kernel RPC service and many implementations of the TSAP. These sockets are opened and initialized by daemon helpers when the service is initialized. They are used by whichever process requests access to the service. The approach Ran gives above will authenticate the user of the service as if he/she were the daemon process, unless, of course, the application is modified to understand the kernel hacks required for IPSEC user authentication. The question remains, is 95% coverage sufficient? Charlie Watt SecureWare, Inc. -----END PRIVACY-ENHANCED MESSAGE----- Received: from relay.hq.tis.com by neptune.TIS.COM id aa14341; 21 Aug 96 10:45 EDT Received: by relay.hq.tis.com; id KAA29170; Wed, 21 Aug 1996 10:48:22 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma029164; Wed, 21 Aug 96 10:48:02 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA14931; Wed, 21 Aug 96 10:47:14 EDT Received: by relay.hq.tis.com; id KAA29150; Wed, 21 Aug 1996 10:47:52 -0400 Received: from sdnhq.undp.org(192.124.42.79) by relay.tis.com via smap (V3.1.1) id xma029144; Wed, 21 Aug 96 10:47:50 -0400 Received: (from uucp@localhost) by sdnhq.undp.org (8.7.5/8.6.9) with UUCP id JAA12228 for ipsec@tis.com; Wed, 21 Aug 1996 09:17:35 -0400 Received: from sunpak.UUCP by sdnpk.undp.org (8.6.12/8.6.12) with UUCP id QAA28678 for ipsec@tis.com; Wed, 21 Aug 1996 16:50:05 +0500 Message-Id: <199608211150.QAA28678@sdnpk.undp.org> Received: from ashar@sunpak by sunpak.sdnpk.undp.org (PMail+UDG PegWaf v0.26 93.04.04) id 2044 for ipsec@tis.com; Wed, 21 Aug 1996 12:42:27 PST +0500 From: Ashar Aziz <ashar@sunpak.sdnpk.undp.org> To: mcr@milkyway.com Date: Wed, 21 Aug 1996 12:42:25 +0000 Subject: Re: SPIs and SKIP (was "user" and "network" ..) Cc: ipsec@TIS.COM X-Confirm-Reading-To: ashar@sunpak.sdnpk.undp.org (Ashar Aziz) X-Pmrqc: 1 Priority: normal X-Mailer: Pegasus Mail for Windows (v2.01) Sender: ipsec-approval@neptune.tis.com Precedence: bulk >From: Michael Richardson <mcr@milkyway.com> > To: ipsec@TIS.COM > Subject: Re: "user" and "network layer" security mechanisms. > Huh? > Who said anything about UDP or TCP? > IPsec has an SPI. *That* is the unambiguous link between packets and > *all* security associations, whether they be user or node ones. > One of my major problems with SKIP is that it effectively kills the SPI > as a useful concept. An SPI essentially provides the implementation with a handle to process an ipsec packet. Conceptually, one can visualize this as a table, indexed by the SPI, where the table entry contains the attributes (crypto variables like keys, algorithms, principal ids, etc.) for processing the packet. There is no constraint on what this table entry can contain. With SKIP, one can visualize the table entry for the SKIP SPI to essentially say: look in another place for some of the attributes you need; namely the buffer that contains the received packet. Essentially, all the same information that one obtains directly from the contents of the table entry can be obtained from this other location in system memory. Keep in mind that some of the crypto-variables are contained in the packet header, even with alternative approaches (e.g. IVs). The distinction then essentially becomes which part of memory some of the attribute information is obtained from. I don't view this as killing the SPI as a useful concept. This is merely another (legitimate) way of using the SPI in order to get different, and in certain important application scenarious, highly desirable protocol properties both from a cryptographic and a network point of view. Ashar. To: Derek Atkins <warlord@mit.edu> Cc: Charles Watt <watt@sware.com>, ipsec@TIS.COM Subject: Re: "user" and "network layer" security mechanisms. Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 21 Aug 1996 10:58:25 -0400 From: "Perry E. Metzger" <perry@piermont.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9608211058.aa14732@neptune.TIS.COM> Derek Atkins writes: > Huh? The fact that authentication is done at the client is an > implementation detail. It is implement that way, IMHO, because there > is no "secure" way for the server to know what access rights the > client has. However, that is in no way a requirement of the NFS > protocol. You could, of course, change that, but then it wouldn't be NFS, it would be a new protocol. > You could easily change the RPC Security flavor to do something > different and implement the server such that access checks are > performed there as well. However, the complexity you would have to add to the RPC Security flavor would be sufficient that you really wouldn't have a right to call it NFS any more -- it would be "NFS plus a whole lot of extra stuff". You need more than IPSEC -- you end up needing a fairly complex security handshake on top, and THEN your NFS stuff would be secured. > So, your statement about there being "no way" is just plain wrong. > OTOH, it would take a lot of programming to change the > implementation to "do the logical thing". But I believe it is > possible. I'm not saying that you can't build secure file systems, or that they can't even look nearly like NFS. However, when you are done, it isn't going to be NFS any longer. This is very much unlike, say, Telnet, where just by making the server understand SPIs a bit you could implement per user authentication. Perry To: Charles Watt <watt@sware.com> Cc: ipsec@TIS.COM Subject: Re: "user" and "network layer" security mechanisms. In-Reply-To: Your message of "Tue, 20 Aug 1996 14:14:08 EDT." <9608201814.AA01416@mordred.sware.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 21 Aug 1996 11:03:26 -0400 From: "Perry E. Metzger" <perry@piermont.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9608211104.aa14983@neptune.TIS.COM> Charles Watt writes: > >The SPI number in the packet is perfectly suitable for this > >purpose. The real issue is being able to negotiate the use of a > >particular SPI for a particular connection -- thats a > >Photuris/Oakley/ISAKMP/Whatever issue. > > I think you are missing the point Perry. For example, if you have six > concurrent users of an X.400 product that makes use of an RFC 1006 Ah, unless I've lost my brain this week, X.400 is a mail protocol. Mail systems need to secure the messages, not the links. You could argue that IPSEC is unsuitable for the user level securing of SMTP transmissions, and I'd agree. Protocols like that need to have the underlying messages encrypted -- the transport doesn't matter. No need to couch this in complex OSI protocol terms. People often miss this point. Securing the link is suitable for protocols like Telnet. Protocols like SMTP need the DATA secured, not the link, although to add some traffic analysis protection one might want to secure the link too. Protocols like FTP fall somewhere in between, where one often has a desire to get a signature on the DATA, but in which there will probably be benefits to assuring that the control link has been kept secure. Perry Date: Wed, 21 Aug 1996 09:27:59 -0700 From: "Michael R. Eisler" <Michael.Eisler@eng.sun.com> Message-Id: <199608211627.JAA29477@dfs-1.eng.sun.com> To: warlord@mit.edu, perry@piermont.com Subject: Re: "user" and "network layer" security mechanisms. Cc: watt@sware.com, ipsec@TIS.COM X-Sun-Charset: US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk > From perry@piermont.com Wed Aug 21 08:40:30 1996 > Derek Atkins writes: > > Huh? The fact that authentication is done at the client is an > > implementation detail. It is implement that way, IMHO, because there > > is no "secure" way for the server to know what access rights the > > client has. However, that is in no way a requirement of the NFS > > protocol. > > You could, of course, change that, but then it wouldn't be NFS, it > would be a new protocol. The NFS protocol speciification doesn't mandate host-centric security and access control. > > You could easily change the RPC Security flavor to do something > > different and implement the server such that access checks are > > performed there as well. > > However, the complexity you would have to add to the RPC Security > flavor would be sufficient that you really wouldn't have a right to > call it NFS any more -- it would be "NFS plus a whole lot of extra huh? Have you been paying attention to my earlier e-mail message on AUTH_DH, and AUTH_KERB. Are you claiming that people who run NFS over either of those two RPC security flavors are in fact not running NFS? A brief lesson: NFS runs on onc rpc. rpc headers contain (among other things), a flavor # following by credential information that can used for crypto authentication. NFS (and other onc applications) treats RPC security as a protocol layer. Claiming that NFS on on flavor other than AUTH_SYS is no longer NFS would be like saying that NFS on a transport other UDP, a network other than IP, or a media other than 10baseT, is no longer NFS. > stuff". You need more than IPSEC -- you end up needing a fairly > complex security handshake on top, and THEN your NFS stuff would be > secured. Proven wrong by existance proof. -mre To: Charles Watt <watt@sware.com> Cc: ipsec@TIS.COM Subject: Re: "user" and "network layer" security mechanisms. Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 21 Aug 1996 11:57:18 -0400 From: "Perry E. Metzger" <perry@piermont.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9608211227.aa17069@neptune.TIS.COM> Charles Watt writes: > Upon review of the spec, you are correct. It appears that my memory is not > immune to age afterall. However, I've looked at the source to our vendor's > RFC 1006 streams module and the basic problem remains. It internally > manages a pool of TCP endpoints, maintaining its own internal binding Thats an implementation issue, not a problem in the spec. > Pick at the specifics all you want, the basic point remains valid. The > Internet stack was designed to permit multiplexing above IP. There are > several things out there that do this. User-level authentication within > IPSEC cannot work for these products unless they are substantially > modified. Look, the fact that you have to store SPIs in the TCBs of most implementations makes for a significant change. No one said this was painless. It is, however, a pretty good solution, architecturally. Perry Message-Id: <199608211640.JAA27077@puli.cisco.com> From: Ran Atkinson <rja@cisco.com> Date: Wed, 21 Aug 1996 09:40:02 PDT X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipsec@TIS.COM Subject: Re: "user" and "network layer" security mechanisms. Sender: ipsec-approval@neptune.tis.com Precedence: bulk I'm glad there is now general agreement that user-oriented keying is not particularly hard to implement in an MLS system and that folks understand the practicality of implementing this inside BSD. I've never worked inside STREAMS, but people with STREAMS clue tell me it can also be done there, albeit using different implementation strategies. On Aug 21, 10:37am, Charles Watt wrote: % And then again, there are services that manage a pool of sockets within the % kernel, such as any kernel RPC service and many implementations of the TSAP. % These sockets are opened and initialized by daemon helpers when the service % is initialized. They are used by whichever process requests access to the % service. The approach Ran gives above will authenticate the user of the % service as if he/she were the daemon process, unless, of course, the % application is modified to understand the kernel hacks required for IPSEC % user authentication. There are a relatively small number of such cases in a typical UNIX system. The needed modifications are, IMO, not terribly difficult or terribly time-consuming to make, based on my examination of ONC RPC specifications and the freely distributable TI-RPC sources a bit over a year ago. Had I remained at my previous job, I would have been building this sometime in 1997 because it was in my Statement of Work from ARPA to do precisely that. As it happens, I think the big hurdle here would be agreement on what the appropriate API extensions would look like. I suspect that GSS-API could be used, though some might argue that is too heavyweight an API for this purpose. I suspect that API extensions based on BSD Sockets would be most widely useful. Ran rja@cisco.com -- To: "Michael R. Eisler" <Michael.Eisler@eng.sun.com> Cc: warlord@mit.edu, perry@piermont.com, watt@sware.com, ipsec@TIS.COM Subject: Re: "user" and "network layer" security mechanisms. Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 21 Aug 1996 13:54:28 -0400 From: "Perry E. Metzger" <perry@piermont.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9608211358.aa19218@neptune.TIS.COM> Michael R. Eisler writes: > huh? Have you been paying attention to my earlier e-mail message on AUTH_DH, > and AUTH_KERB. Are you claiming that people who run NFS over either of > those two RPC security flavors are in fact not running NFS? A brief lesson: > NFS runs on onc rpc. rpc headers contain (among other things), a flavor # > following by credential information that can used for crypto authentication. I think we are having a semantic argument. I believe we both agree on what the NFS spec contains and how NFS gets transported. I believe the difference of opinion is about what we are calling things. Yes, there are hooks in NFS that let you do lots of stuff that would let you secure file access with various flavors of secure RPC. However, I think of ONC RPC as being part and parcel of NFS -- it is the major application of ONC RPC -- and a secure RPC that hooks into the IPSEC stuff and provides user granularity file access is nontrivial. Therefore, permit me to say that within these semantic constraints NFS *as it stands* could not be made user granularity secure using IPSEC in the trivial manner that, say, Telnet can (that is, with no protocol additions other than IPSEC and Photuris or Oakley or what have you, and with minimal source changes to the server). However, certainly you could extend the secure RPC mechanisms do things analagous to the AUTH_KERB hacks with IPSEC. I'm just arguing that this is no longer NFS in the sense that a machine that had IPSEC and a key management system added to it is still going to require extensive hacking to get the NFS security working. Its not "vanilla NFS". Perry Date: Wed, 21 Aug 1996 10:27:54 -0700 From: "Michael R. Eisler" <Michael.Eisler@eng.sun.com> Message-Id: <199608211727.KAA29531@dfs-1.eng.sun.com> To: ipsec@TIS.COM, dpkemp@missi.ncsc.mil Subject: Re: "user" and "network layer" security mechanisms. X-Sun-Charset: US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk > From dpkemp@missi.ncsc.mil Wed Aug 21 07:37:18 1996 > The other viewpoint is top-down: there is a huge universe of applications > running on real customer networks that need to be "secured". We could do > it by modifying every single application and every application protocol to > provide security services at the highest layer, or we could recognize that > application protocols fall into classes, and that for some classes (those > that don't multiplex services for multiple "users" through a single > connection or process), a common IP-layer mechanism can be used without > modifying the higher layer protocols. Therefore it is reasonable to > provide the mechanism (an SPI field in the IP packet) that can in some > cases be used to achieve separation between "users" at the network layer. Seems reasonable to me. For those of us who are "securing" application protocols that aren't members of the class that can use IP-layer user-oriented security, it would be most helpful to have IPSEC "officially" recognize the position that David succinctly stated above. -mre Received: from relay.hq.tis.com by neptune.TIS.COM id aa23596; 21 Aug 96 16:43 EDT Received: by relay.hq.tis.com; id QAA09646; Wed, 21 Aug 1996 16:46:36 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma009638; Wed, 21 Aug 96 16:46:12 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA08771; Wed, 21 Aug 96 16:45:25 EDT Received: by relay.hq.tis.com; id QAA09629; Wed, 21 Aug 1996 16:46:06 -0400 Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1) id xma009598; Wed, 21 Aug 96 16:45:35 -0400 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id NAA28222; Wed, 21 Aug 1996 13:47:47 -0700 Received: by mailsun2.us.oracle.com (SMI-8.6/37.8) id NAA23019; Wed, 21 Aug 1996 13:39:57 -0700 Message-Id: <199608212039.NAA23019@mailsun2.us.oracle.com> Date: 21 Aug 96 13:34:02 -0700 From: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com> To: ipsec@TIS.COM Subject: Re: "user" and "network layer" security mechanisms. X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-request@neptune.hq.tis.com's message of 21-Aug-96 08:57 Mime-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.0.2.1.40) Content-Type: multipart/mixed; boundary="=_ORCL_6749253_0_11919608211440570" Sender: ipsec-approval@neptune.tis.com Precedence: bulk --=_ORCL_6749253_0_11919608211440570 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" >Charles Watt writes: > Internet stack was designed to permit multiplexing above IP. There are > several things out there that do this. User-level authentication within > IPSEC cannot work for these products unless they are substantially > modified. No. Most computers today are single user. Multiplexing above IP does not matter for authentication purposes when all the applications above IP are owned by the same "user". The issues of a "user oriented" IPsec in a compartmentalized workstation is difficult. The CMW market is very different from the "real" world and we should be careful not mix the requirements of the two environments. Paul -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com !!! Last chance, send resumes to: palamber@us.oracle.com !!! -------------------------------------------------------------- --=_ORCL_6749253_0_11919608211440570 Content-Type:message/rfc822 Date: 21 Aug 96 08:57:18 From:"Perry E. Metzger <perry@piermont.com>" <ipsec-request@neptune.hq.tis.com> To:Charles,Watt,<watt@sware.com> Subject:Re: "user" and "network layer" security mechanisms. Cc:ipsec@tis.com Reply-to:perry@piermont.com X-Reposting-Policy:redistribute only with permission Sender:ipsec-approval@neptune.hq.tis.com Precedence: bulk MIME-Version: 1.0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" Charles Watt writes: > Upon review of the spec, you are correct. It appears that my memory is not > immune to age afterall. However, I've looked at the source to our vendor's > RFC 1006 streams module and the basic problem remains. It internally > manages a pool of TCP endpoints, maintaining its own internal binding Thats an implementation issue, not a problem in the spec. > Pick at the specifics all you want, the basic point remains valid. The > Internet stack was designed to permit multiplexing above IP. There are > several things out there that do this. User-level authentication within > IPSEC cannot work for these products unless they are substantially > modified. Look, the fact that you have to store SPIs in the TCBs of most implementations makes for a significant change. No one said this was painless. It is, however, a pretty good solution, architecturally. Perry --=_ORCL_6749253_0_11919608211440570-- Message-Id: <2.2.32.19960821203151.009bce18@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@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, 21 Aug 1996 16:31:51 -0400 To: Michael Richardson <mcr@milkyway.com>, ipsec@TIS.COM From: Robert Moskowitz <rgm3@chrysler.com> Subject: Re: "user" and "network layer" security mechanisms. Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 12:33 PM 8/20/96 -0400, Michael Richardson wrote: > > I see. This sounds like an application problem. Why is it more efficient >to multiplex all sessions over a single TCP session? You've built a tunnel >with TCP. Thus, you are reimplementing the network layer, and you will >have to implement security there. there are many good arguments for where it makes sense to multiplex over TCP. A terminal server to a specific server is an excellent example where multiplexing reduced network traffic 90%. This only proves that there are scope limits on IPsec, where special cases make life interesting. Robert Moskowitz Chrysler Corporation (810) 758-8212 Message-Id: <2.2.32.19960821203154.009c5fb0@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@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, 21 Aug 1996 16:31:54 -0400 To: Michael.Eisler@eng.sun.com, perry@piermont.com, watt@sware.com From: Robert Moskowitz <rgm3@chrysler.com> Subject: Re: "user" and "network layer" security mechanisms. Cc: nelson@mcn.netsec.com, ipsec@TIS.COM, netsec@panix.com Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 09:00 AM 8/20/96 -0700, Michael R. Eisler wrote: > >I am curious if anyone has implemented IPSEC with user-level security >associations, and whether the associations are bound at the time the >end-point is open or if they are switchable with each outgoing >datagram. If the latter, is the I/O framework asynchronous or not? An >existance proof might make me less pessimistic about end-user IPSEC. For me my view is end-user IPsec occurs for mobile notebooks. It is the user of the notebook cert that gets used in setting up the SPI, not the notebooks. After all, I have my own security card that I would plug into the PCMCIA card. Robert Moskowitz Chrysler Corporation (810) 758-8212 Message-Id: <2.2.32.19960821204459.009a98ec@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@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, 21 Aug 1996 16:44:59 -0400 To: Naganand Doraswamy <naganand@ftp.com>, ipsec@TIS.COM From: Robert Moskowitz <rgm3@chrysler.com> Subject: Re: AH in tunnel mode Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 02:43 PM 8/20/96 -0400, Naganand Doraswamy wrote: > >Using AH in tunnel mode has the same security implications as using ESP in >tunneled mode (refer to Ran's comments on this). But how do you distiguish when AH is enough? The answer is when it covers an ESP for end-to-end. Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.hq.tis.com by neptune.TIS.COM id aa26246; 21 Aug 96 18:44 EDT Received: by relay.hq.tis.com; id SAA12353; Wed, 21 Aug 1996 18:48:06 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma012351; Wed, 21 Aug 96 18:47:38 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA15089; Wed, 21 Aug 96 18:46:55 EDT Received: by relay.hq.tis.com; id SAA12348; Wed, 21 Aug 1996 18:47:36 -0400 Received: from toad.com(140.174.2.1) by relay.tis.com via smap (V3.1.1) id xma012346; Wed, 21 Aug 96 18:47:28 -0400 Received: from localhost (localhost [127.0.0.1]) by toad.com (8.7.5/8.7.3) with SMTP id PAA02328; Wed, 21 Aug 1996 15:49:43 -0700 (PDT) Message-Id: <199608212249.PAA02328@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: ipsec@TIS.COM, gnu@toad.com Subject: Idea: Prizes for protocol problems in key agreement Date: Wed, 21 Aug 1996 15:49:42 -0700 From: John Gilmore <gnu@toad.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk Cliff Stoll's talk here at Crypto '96 mentioned that crypto is all about trust, and that trust comes from a process of suspicion, followed by scrutiny, followed by trust if no problems are found. You can also see this as a Quality Assurance procedure. Given the current state of IPSEC key agreement protocols, I am thinking it would be prudent to run a competition for people to scrutinize some candidate key agreement protocols (e.g. Photuris, SKIP, ISAKMP/Oakley, and whatever comes out of the smoke-filled room). I have a serious concern that we'll end up standardizing on a protocol that has not had the scrutiny required to validate its security. For this audience I need not point out that if the key agreement protocol is insecure or subvertible, it doesn't matter how strong our packet encryption is, nor how solid our public-key infrastructure is. I'm particularly concerned that Photuris has not had recent scrutiny, that ISAKMP/Oakley is sufficiently complex and new that it has not been fully defined or analyzed, and that the smoke-filled protocol, if any, will of course be new and need critical examination. EFF has recently decided that they want to help my S/WAN efforts to deploy IPSEC technology widely and rapidly. I'm thinking of funding prizes that EFF would offer for protocol problems found and posted to the IPSEC mailing list. The kinds of things that would qualify as "problems" include: * Revealing session keys or parts thereof to observers or attackers * Revealing private keys or parts thereof to observers or attackers * Enabling session keys to be forced to known or partly-known values * Inability to scale to daily use on the entire Internet * Revealing user identities to observers (if user keying is involved) * Failure to provide perfect forward secrecy for packet traffic * Enabling traffic to move in the clear which should be encrypted * Designs that are trivial to circumvent or bypass My current thought is that the "best" problems will win more money and glory, but that everyone who finds a legitimate problem (in the judges' opinion) will get some money and glory out of it. I hope that we can do something similar for some of the reference implementations, once the protocols are nailed down. There might be big money for the protocol authors here -- they can define buggy protocols and then collect by pointing out the problems! But I think the increased general scrutiny is worth that risk. Does anyone have objections to this kind of quality assurance process? Please give me your reactions and suggestions about this idea. Suggestions for a set of standards to judge the protocols against would be particularly useful. Also suggestions on the appropriate sizes, numbers, and categories of prizes, and potential judges. John Gilmore 'an equal opportunistic encryptor' Received: from relay.hq.tis.com by neptune.TIS.COM id aa03633; 22 Aug 96 1:50 EDT Received: by relay.hq.tis.com; id BAA17724; Thu, 22 Aug 1996 01:17:58 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma017715; Thu, 22 Aug 96 01:17:28 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA20956; Thu, 22 Aug 96 01:16:45 EDT Received: by relay.hq.tis.com; id BAA17712; Thu, 22 Aug 1996 01:17:27 -0400 Received: from necom830.hpcl.titech.ac.jp(131.112.32.132) by relay.tis.com via smap (V3.1.1) id xma017708; Thu, 22 Aug 96 01:17:17 -0400 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Message-Id: <199608220519.OAA13272@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id OAA13272; Thu, 22 Aug 1996 14:18:50 +0859 Subject: Re: "user" and "network layer" security mechanisms. To: Ran Atkinson <rja@cisco.com> Date: Thu, 22 Aug 96 14:18:50 JST Cc: wobber@pa.dec.com, ipsec@TIS.COM In-Reply-To: <199608210038.RAA01482@puli.cisco.com>; from "Ran Atkinson" at Aug 20, 96 5:38 pm X-Mailer: ELM [version 2.3 PL11] Sender: ipsec-approval@neptune.tis.com Precedence: bulk In article <9608202111.AA25177@hickory.pa.dec.com> Ted Wobber wrote: >In a Mandatory Access Control world, perhaps this 5% shortfall is >a significant problem. What many people are using today is weak security. With network layer real security, we can make weak security secured, but nothing more than that. Network layer security may satisfy 95% of today's case, only because they are using weak security today. But, secured weak security is not real security. Masataka Ohta Received: from relay.hq.tis.com by neptune.TIS.COM id aa13656; 22 Aug 96 12:56 EDT Received: by relay.hq.tis.com; id MAA00679; Thu, 22 Aug 1996 12:59:33 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma000652; Thu, 22 Aug 96 12:59:05 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA14450; Thu, 22 Aug 96 12:58:21 EDT Received: by relay.hq.tis.com; id MAA00645; Thu, 22 Aug 1996 12:59:03 -0400 Received: from mercury.sun.com(192.9.25.1) by relay.tis.com via smap (V3.1.1) id xma000628; Thu, 22 Aug 96 12:58:43 -0400 Received: by mercury.Sun.COM (Sun.COM) id KAA11027; Thu, 22 Aug 1996 10:00:52 -0700 Received: from packmind.Corp.Sun.COM by Corp.Sun.COM (5.x/SMI-5.3) id AA29366; Thu, 22 Aug 1996 10:00:46 -0700 Received: by packmind.Corp.Sun.COM (SMI-8.6/SMI-SVR4) id KAA08761; Thu, 22 Aug 1996 10:00:10 -0700 Date: Thu, 22 Aug 1996 10:00:10 -0700 From: Alan Monday-Internet Commerce Group <Alan.Monday@corp.sun.com> Message-Id: <199608221700.KAA08761@packmind.Corp.Sun.COM> To: ipsec@TIS.COM, gnu@toad.com Subject: Re: Idea: Prizes for protocol problems in key agreement X-Sun-Charset: US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk I like this idea. I would add to the "problems" list: * Designs that can't be used for secure multicast applications * Designs that support Key Escrow * Designs that have only partial implementation Alan > From gnu@toad.com Thu Aug 22 05:50:04 1996 > X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol > To: ipsec@TIS.COM, gnu@toad.com > Subject: Idea: Prizes for protocol problems in key agreement > From: John Gilmore <gnu@toad.com> > Sender: ipsec-approval@neptune.tis.com > Precedence: bulk > Content-Length: 2851 > X-Lines: 55 > > Cliff Stoll's talk here at Crypto '96 mentioned that crypto is all > about trust, and that trust comes from a process of suspicion, > followed by scrutiny, followed by trust if no problems are found. You > can also see this as a Quality Assurance procedure. > > Given the current state of IPSEC key agreement protocols, I am > thinking it would be prudent to run a competition for people to > scrutinize some candidate key agreement protocols (e.g. Photuris, > SKIP, ISAKMP/Oakley, and whatever comes out of the smoke-filled room). > I have a serious concern that we'll end up standardizing on a protocol > that has not had the scrutiny required to validate its security. For > this audience I need not point out that if the key agreement protocol > is insecure or subvertible, it doesn't matter how strong our packet > encryption is, nor how solid our public-key infrastructure is. > > I'm particularly concerned that Photuris has not had recent scrutiny, > that ISAKMP/Oakley is sufficiently complex and new that it has not > been fully defined or analyzed, and that the smoke-filled protocol, if > any, will of course be new and need critical examination. > > EFF has recently decided that they want to help my S/WAN efforts to > deploy IPSEC technology widely and rapidly. I'm thinking of funding > prizes that EFF would offer for protocol problems found and posted to > the IPSEC mailing list. The kinds of things that would qualify as > "problems" include: > > * Revealing session keys or parts thereof to observers or attackers > * Revealing private keys or parts thereof to observers or attackers > * Enabling session keys to be forced to known or partly-known values > * Inability to scale to daily use on the entire Internet > * Revealing user identities to observers (if user keying is involved) > * Failure to provide perfect forward secrecy for packet traffic > * Enabling traffic to move in the clear which should be encrypted > * Designs that are trivial to circumvent or bypass > > My current thought is that the "best" problems will win more money and > glory, but that everyone who finds a legitimate problem (in the > judges' opinion) will get some money and glory out of it. > > I hope that we can do something similar for some of the reference > implementations, once the protocols are nailed down. > > There might be big money for the protocol authors here -- they can > define buggy protocols and then collect by pointing out the problems! > But I think the increased general scrutiny is worth that risk. > > Does anyone have objections to this kind of quality assurance process? > > Please give me your reactions and suggestions about this idea. > Suggestions for a set of standards to judge the protocols against would > be particularly useful. Also suggestions on the appropriate sizes, > numbers, and categories of prizes, and potential judges. > > John Gilmore > 'an equal opportunistic encryptor' > Message-Id: <3.0b11.32.19960823114911.00a68238@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0b11 (32) Date: Fri, 23 Aug 1996 11:58:14 -0400 To: Alan.Monday@corp.sun.com, ipsec@TIS.COM, gnu@toad.com From: Robert Moskowitz <rgm3@chrysler.com> Subject: Re: Idea: Prizes for protocol problems in key agreement Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 10:00 AM 8/22/96 -0700, Alan Monday-Internet Commerce Group wrote: >I like this idea. I would add to the "problems" list: > > * Designs that can't be used for secure multicast applications > * Designs that support Key Escrow > * Designs that have only partial implementation Designs that invalidate Key Escrow (in otherwords, escrow me all you want, it does no good)? Is this possible? It seems that man in the middle attacks are all that is left to Key Escrow for some of these? Is that adequate? If the key escrowers see that they have to launch man in the middle attacks to see anything is this raising the cost enough to vastly limit its use? Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.hq.tis.com by neptune.TIS.COM id aa00390; 23 Aug 96 15:29 EDT Received: by relay.hq.tis.com; id PAA00466; Fri, 23 Aug 1996 15:32:38 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma000440; Fri, 23 Aug 96 15:32:15 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA18018; Fri, 23 Aug 96 15:31:27 EDT Received: by relay.hq.tis.com; id PAA00428; Fri, 23 Aug 1996 15:32:08 -0400 Received: from relay.hp.com(15.255.152.2) by relay.tis.com via smap (V3.1.1) id xma000426; Fri, 23 Aug 96 15:31:55 -0400 Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA099578841; Fri, 23 Aug 1996 12:34:02 -0700 Message-Id: <199608231934.AA099578841@relay.hp.com> Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com id AA209918840; Fri, 23 Aug 1996 15:34:01 -0400 To: rgm3@chrysler.com Cc: Alan.Monday@corp.sun.com, ipsec@TIS.COM, gnu@toad.com Subject: Re: Idea: Prizes for protocol problems in key agreement In-Reply-To: rgm3's message of Fri, 23 Aug 1996 11:58:14 -0400. <3.0b11.32.19960823114911.00a68238@pop3hub.is.chrysler.com> Date: Fri, 23 Aug 1996 15:34:00 -0400 From: Bill Sommerfeld <sommerfeld@apollo.hp.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk > Designs that invalidate Key Escrow (in otherwords, escrow me all you want, > it does no good)? I'm not sure what you mean by this.. (use of ephemeral unescrowed DH keys and session keys along with escrowed long-term signature keys?) > Is this possible? It seems that man in the middle attacks are all that is > left to Key Escrow for some of these? Either that, or individual transforms which escrow the session key actually used.. > Is that adequate? If the key escrowers see that they have to launch man in > the middle attacks to see anything is this raising the cost enough to vastly > limit its use? Well, the protocol had better be immune to MITM attacks, at least assuming there's a trustable certification path between the parties.. I see that as being covered by several of the problems in John's original list. "Revealing session keys or parts thereof to observers or attackers" "Designs that are trivial to circumvent or bypass" "Enabling session keys to be forced to known or partly-known values" I'll add one more of my own: "Failure to provide perfect forward secrecy for user identities (if user keying is involved)". which is, of course, a slightly stronger form of the existing: "Revealing user identities to observers (if user keying is involved)" - Bill From: William Allen Simpson <wsimpson@greendragon.com> Message-Id: <5476.wsimpson@greendragon.com> To: ipsec@TIS.COM Subject: Re: "user" and "network layer" security mechanisms. Sender: ipsec-approval@neptune.tis.com Precedence: bulk Date: Mon, 26 Aug 96 7:16:18 EDT Seems reasonable to me, too. I remember Phil Karn espousing this view repeatedly over the past years, whenever user-oriented keying came up.... I thought that we had general consensus on this (except for our WG chairs). I wish that we could get "official" recognition of this position, too. For the great class of usage, firewall to firewall tunnels (where only network origination is authenticated), or laptop to firewall, IP "network-layer" security easily handles those needs. The "user" or "principle" or "party" maps nicely to the IP address. For single-user laptop to multi-user host, the host software can avoid application and API changes if the admittance can be managed by the host kernel. The "user" maps nicely to the IP address plus SPI combination. For multi-user host to multi-user host, with mutually suspicious users, and/or multi-level security handled in a single session, and/or firewalls attempting to authenticate user origination, major changes are needed to the applications, APIs and to the internal segregation and management of system security. But then, that's the domain of the "transport-layer" security WG.... > From: "Michael R. Eisler" <Michael.Eisler@eng.sun.com> > > From dpkemp@missi.ncsc.mil Wed Aug 21 07:37:18 1996 > > The other viewpoint is top-down: there is a huge universe of applications > > running on real customer networks that need to be "secured". We could do > > it by modifying every single application and every application protocol to > > provide security services at the highest layer, or we could recognize that > > application protocols fall into classes, and that for some classes (those > > that don't multiplex services for multiple "users" through a single > > connection or process), a common IP-layer mechanism can be used without > > modifying the higher layer protocols. Therefore it is reasonable to > > provide the mechanism (an SPI field in the IP packet) that can in some > > cases be used to achieve separation between "users" at the network layer. > > Seems reasonable to me. > > For those of us who are "securing" application protocols that aren't > members of the class that can use IP-layer user-oriented security, it > would be most helpful to have IPSEC "officially" recognize the position > that David succinctly stated above. > WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From: William Allen Simpson <wsimpson@greendragon.com> Message-Id: <5475.wsimpson@greendragon.com> To: ipsec@TIS.COM Subject: Re: Idea: Prizes for protocol problems in key agreement Sender: ipsec-approval@neptune.tis.com Precedence: bulk Date: Mon, 26 Aug 96 7:17:18 EDT > From: John Gilmore <gnu@toad.com> > I have a serious concern that we'll end up standardizing on a protocol > that has not had the scrutiny required to validate its security. For > this audience I need not point out that if the key agreement protocol > is insecure or subvertible, it doesn't matter how strong our packet > encryption is, nor how solid our public-key infrastructure is. > > I hope that we can do something similar for some of the reference > implementations, once the protocols are nailed down. > I like both ideas very much! > There might be big money for the protocol authors here -- they can > define buggy protocols and then collect by pointing out the problems! > But I think the increased general scrutiny is worth that risk. > Phooey, too late for Phil and I. :-( Do we get prizes for finding and fixing past holes in the _original_ specifications? We already had some help from reviewers, of course.... And what about holes that the WG review process forced us to add into the protocol? Such as: > * Revealing user identities to observers (if user keying is involved) (As folks may remember, the change of Photuris privacy protection from mandatory to optional, which was the only recent change to Photuris, was the result of a nearly unanamiously straw poll instigated by Hugo at LA. Negative prizes -- perhaps future prize disqualification -- for entire groups of people?) > Please give me your reactions and suggestions about this idea. > Suggestions for a set of standards to judge the protocols against would > be particularly useful. Also suggestions on the appropriate sizes, > numbers, and categories of prizes, and potential judges. > The categories you listed seem to cover most of my concerns, as specifics such as anti-clogging and key escrow fit under the more general: > * Inability to scale to daily use on the entire Internet > * Failure to provide perfect forward secrecy for packet traffic I suggest that, as in the Nobel prizes, the prize funders be the sole determiner of categories, sizes, and judges. You might want to find protocol "customers" like Moskowitz to be on the panel of judges, rather than potential contributor/recipients like cryptographers or IETF'ers. And worldwide geographic coverage, rather than US centric. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 Date: Mon, 26 Aug 1996 02:09:58 -0400 From: "Mitchell C. Nelson" <nelson@mcn.netsec.com> Message-Id: <199608260609.CAA00246@mcn.netsec.com> To: ipsec@TIS.COM Subject: "user" and "network layer" security. reply to respondents. Sender: ipsec-approval@neptune.tis.com Precedence: bulk The term "user" is undefined in the network layer of IP. It has no sensible context in a discussion of *network layer* security mechanisms. Moreover, introducing a parameter to the network layer that corresponds to "user", breaks the network architecture. These are basic facts of IP architecture. The basic facts of IP architecture are established by agreed upon definition. Important issues are raised by these basic facts. Arguments such as those based on suggested hacks of network codes and operating systems, are all specious with respect to the real issues. Issue #1: Is it appropriate for IPSEC to break network architecture, given the absence of experience implementing security on the proposed scale? Issue #2: Where is it established that network layer mechanisms should be used to implement application layer security? Regards, Mitch Nelson netsec@panix From: Phil Karn <karn@unix.ka9q.ampr.org> To: netsec@panix.com Cc: ipsec@TIS.COM Reply-To: karn@qualcomm.com In-Reply-To: <Pine.SUN.3.91.960816155715.811B-100000@panix.com> (netsec@panix.com) Subject: Re: "user" and "network layer" security. Sender: ipsec-approval@neptune.tis.com Precedence: bulk Date: Mon, 26 Aug 96 7:15:18 EDT Message-ID: <9608260715.aa04497@neptune.TIS.COM> >"User" based security and "network layer" security can each be designed >and implemented in ways that are consistent with the established network >architecture. With some pro-forma cross consultation, one should expect >to arrive at reasonable results that provide good security without >conflict and without unduly compromising present network functionality. >The alternative does not offer as much grounds for optimism. Therefore it >seems that all lanquage related to "user" should be expunged from IPSEC >and instead treated in a seperate discussion group. I couldn't agree more. As one of the originators of the IPSEC group, I have watched with increasing resignation for the last four years as my original idea has grown completely out of control, with very little to show for it. My original desire for security just above IP was to solve an immediate and well-defined problem: when I use the network at an IETF meeting or a USENIX, how can my laptop get back through my company's firewall in a safe and secure fashion? A closely related problem is the use of the Internet as a low-cost alternative to leased lines between geographically separate subnets of a corporate network. Leased lines are easily encrypted at the link layer, but you have to move up to at least the IP layer to build a "virtual leased line" over the net. A security layer immediately above IP is a simple, straightforward and highly effective solution to both problems. I was so taken by IPSEC's seeming elegance that I started saying it could displace security at the application layer. I now realize this was a serious mistake. The interminable philosphical discussions here about "user-oriented keying" and the geometrically increasing complexity of the proposed key management protocols (including Photuris) are clear proof of that. Furthermore, there has been considerable progress in public-key-based application-layer security in the past several years. We now have PGP for email and files, SHTTP for the web, and SSH for remote login, command execution and file transfer. Unlike IPSEC, I use all three every day, and they work. SSH seems likely to develop into a general purpose transport layer security mechanism that satisfies much (though not all) of the need for end-to-end Internet security. So our idealistic idea of avoiding all that application layer work has been almost completely overtaken by events. If the IPSEC group's work is to ever have any relevance, it must return to the original, bare-bones goal of building protected "tunnels" at the host-to-host or subnet-to-subnet level of granularity. There's still plenty of need for this function, but trying to do more than this is likely to continue to get us nowhere. In this light, SKIP keeps looking better to me all the time. Its claim to the "simple" label certainly keeps getting stronger. The only real problem I've ever had with it was the lack of perfect forward secrecy (PFS) in the original design. But that's in there too. So other than the lack of support for a facility (user-oriented keying) that we can't really do properly anyway, what's wrong with it? Phil Received: from relay.hq.tis.com by neptune.TIS.COM id aa07262; 26 Aug 96 10:23 EDT Received: by relay.hq.tis.com; id KAA17555; Mon, 26 Aug 1996 10:26:23 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma017552; Mon, 26 Aug 96 10:25:56 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA19207; Mon, 26 Aug 96 10:25:15 EDT Received: by relay.hq.tis.com; id KAA17549; Mon, 26 Aug 1996 10:25:53 -0400 Received: from ns.border.com(199.71.190.98) by relay.tis.com via smap (V3.1.1) id xma017547; Mon, 26 Aug 96 10:25:31 -0400 Received: by janus.border.com id <18439-1>; Mon, 26 Aug 1996 10:28:05 -0400 Message-Id: <96Aug26.102805edt.18439-1@janus.border.com> To: ipsec@TIS.COM Subject: Re: "user" and "network layer" security mechanisms. From: "C. Harald Koch" <chk@border.com> Date: Mon, 26 Aug 1996 10:27:32 -0400 Sender: ipsec-approval@neptune.tis.com Precedence: bulk One observation: The people working on other protocols requiring security (TLS, L2TP, LDAP, and probably others) have all been overheard saying the same thing: Wouldn't it be nice to have a single key negotiation protocol for IPsec *and* for our protocols? So, Before we run around in a frenzy removing 'user oriented keying', we should remember that AH/ESP are no longer the only customers of an IPSEC WG key management protocol. -- Harald Koch chk@border.com From: Hilarie Orman <ho@earth.hpc.org> Message-Id: <199608261512.LAA23989@earth.hpc.org> To: ipsec@TIS.COM Subject: no SKIP/ISAKMP/OAKLEY resolution Sender: ipsec-approval@neptune.tis.com Precedence: bulk Date: Mon, 26 Aug 96 11:09:36 EDT The design group attempting to combine SKIP/OAKLEY/ISAKMP into one protocol has been unable to resolve deeply held technical differences of opinion. Some progress was made initially, but there has been no change in several weeks now, so I must report failure, with great disappointment. In my opinion, this was a group effort and a group failure --- I exhort the greater working group to find quick agreement on goals and an acceptable solution. Hilarie Orman Date: Mon, 26 Aug 1996 12:12:22 -0400 To: karn@qualcomm.com, netsec@panix.com From: Robert Moskowitz <rgm3@chrysler.com> Subject: Re: "user" and "network layer" security. Cc: ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9608261235.aa08927@neptune.TIS.COM> At 07:15 AM 8/26/96 EDT, Phil Karn wrote: > >My original desire for security just above IP was to solve an >immediate and well-defined problem: when I use the network at an IETF >meeting or a USENIX, how can my laptop get back through my company's >firewall in a safe and secure fashion? Funny, that is what I define as 'user' the 'user' of the laptop. This thingee ain't never going to work for the 'user' of a terminal attached to a terminal server. At least the way terminal servers are working these days. > >Furthermore, there has been considerable progress in public-key-based >application-layer security in the past several years. We now have PGP >for email and files, SHTTP for the web, and SSH for remote login, >command execution and file transfer. Unlike IPSEC, I use all three >every day, and they work. SSH seems likely to develop into a general >purpose transport layer security mechanism that satisfies much (though >not all) of the need for end-to-end Internet security. So our >idealistic idea of avoiding all that application layer work has been >almost completely overtaken by events. I still don't feel comfortable with transport layer security mechanisms like SSL (that you did not list). I am going to need a good run-through by someone that is not a proslytizer for it, but very well versed on the subject. You see, I work with Venn diagrams in my head (sometimes I still draw them). I have this one that has network layer security and data layer security and it leaves very little left for transport layer security. Most seem to have data layer as a nitch player (securing mail), I have it as a major component and with the cost of cpus and security engines better for many of the things that SHTTP gets used for today. Being part of an industry with general distrust but major partnering, I need for the policy to be bound to the object. >In this light, SKIP keeps looking better to me all the time. Its claim >to the "simple" label certainly keeps getting stronger. The only real >problem I've ever had with it was the lack of perfect forward secrecy >(PFS) in the original design. But that's in there too. So other than >the lack of support for a facility (user-oriented keying) that we >can't really do properly anyway, what's wrong with it? I am working on my list of items that makes Oakley (and GKMP, did you see the drafts just released?) on ISAKMP as the better mechanism for a inter-business security. SKIP, it looks like can be made to work for the intra-business model. After all it is simple and inter-business is not. Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.hq.tis.com by neptune.TIS.COM id aa10054; 26 Aug 96 14:10 EDT Received: by relay.hq.tis.com; id OAA24895; Mon, 26 Aug 1996 14:13:17 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma024844; Mon, 26 Aug 96 14:12:57 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA01755; Mon, 26 Aug 96 14:12:14 EDT Received: by relay.hq.tis.com; id OAA24825; Mon, 26 Aug 1996 14:12:46 -0400 Received: from relay.hp.com(15.255.152.2) by relay.tis.com via smap (V3.1.1) id xma024811; Mon, 26 Aug 96 14:12:32 -0400 Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA245873282; Mon, 26 Aug 1996 11:14:44 -0700 Message-Id: <199608261814.AA245873282@relay.hp.com> Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com id AA074423282; Mon, 26 Aug 1996 14:14:42 -0400 To: Bob Natale <natale@acec.com> Cc: fred@cisco.com, ipsec@TIS.COM, karn@qualcomm.com Subject: Re: IETF focus In-Reply-To: natale's message of Mon, 26 Aug 1996 11:05:47 -0400. <ECS9608261147A@acec.com> Date: Mon, 26 Aug 1996 14:14:41 -0400 From: Bill Sommerfeld <sommerfeld@apollo.hp.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk [please note the change in CC: line from ietf back to ipsec...] Interesting that you should mention WG charters as an issue. IPSEC's charter includes.. The preliminary goals will specifically pursue host-to-host security followed by subnet-to-subnet and host-to-subnet topologies. It appears that the initial "early adopters" of IPSEC are the firewall folks -- so host-to-subnet and subnet-to-subnet is being developed and deployed before host-to-host. The charter also says: The Internet Key Management Protocol (IKMP) will be specified as an application layer protocol that is independent of the lower layer security protocol. Hmm. That could be interpreted to rule out SKIP, but the WG has been behaving as if it's a candidate on equal footing with ISAKMP (and rightly so..). Because of these inconsistancies between the charter and the current drafts up for discussion, and the failure of the "smoke filled key management room" to produce anything, I think we need to seriously consider revising the charter to reflect reality. - Bill Received: from relay.hq.tis.com by neptune.TIS.COM id aa12296; 26 Aug 96 17:12 EDT Received: by relay.hq.tis.com; id RAA02537; Mon, 26 Aug 1996 17:15:20 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma002511; Mon, 26 Aug 96 17:14:51 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA12246; Mon, 26 Aug 96 17:14:12 EDT Received: by relay.hq.tis.com; id RAA02506; Mon, 26 Aug 1996 17:14:50 -0400 Received: from panix.com(198.7.0.2) by relay.tis.com via smap (V3.1.1) id xma002492; Mon, 26 Aug 96 17:14:32 -0400 Received: (from netsec@localhost) by panix.com (8.7.5/8.7/PanixU1.3) id RAA23193; Mon, 26 Aug 1996 17:16:49 -0400 (EDT) Date: Mon, 26 Aug 1996 17:16:48 -0400 (EDT) From: "M.C.Nelson" <netsec@panix.com> To: ipsec@TIS.COM Cc: karn@qualcomm.com MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Subject: "user" and "network layer" security, a renewed IPSEC. Message-Id: <Pine.SUN.3.91.960826171444.22574A-100000@panix.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk I am sorry that I did not read Phil's note of Aug 25 before sending my note on Aug 26. I agree with Phil's suggestion regarding SKIP, and I suggest that we proceed along those lines. Also, I think that the IPSEC charter should be revised to focus more explicitly on network layer security. The task should be well defined, as a first step towards producing the best possible result. (Application layer security can be the well defined task of an APPSEC working group.) SKIP seems to reflect reasonable objectives of network layer security. Still it would probably be a useful exercise to try and summarize what those objectives are. Meanwhile I suggest that we set a reasonable minimum period of time for renewed discussion of the SKIP proposal in its details. Mitch Nelson netsec@panix.com >From Phil Karn: >>"User" based security and "network layer" security can each be designed >>and implemented in ways that are consistent with the established network >>architecture. With some pro-forma cross consultation, one should expect >>to arrive at reasonable results that provide good security without >>conflict and without unduly compromising present network functionality. >>The alternative does not offer as much grounds for optimism. Therefore >>it seems that all lanquage related to "user" should be expunged from >>IPSEC and instead treated in a seperate discussion group. (quoted by from M.C.Nelson of 8/16) >I couldn't agree more. As one of the originators of the IPSEC group, I >have watched with increasing resignation for the last four years as my >original idea has grown completely out of control, with very little to >show for it. ..... >If the IPSEC group's work is to ever have any relevance, it must >return to the original, bare-bones goal of building protected >"tunnels" at the host-to-host or subnet-to-subnet level of >granularity. There's still plenty of need for this function, but >trying to do more than this is likely to continue to get us nowhere. > >In this light, SKIP keeps looking better to me all the time. Its claim >to the "simple" label certainly keeps getting stronger. The only real >problem I've ever had with it was the lack of perfect forward secrecy >(PFS) in the original design. But that's in there too. So other than >the lack of support for a facility (user-oriented keying) that we >can't really do properly anyway, what's wrong with it? Received: from relay.hq.tis.com by neptune.TIS.COM id aa19675; 27 Aug 96 4:45 EDT Received: by relay.hq.tis.com; id EAA10115; Tue, 27 Aug 1996 04:49:07 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma010110; Tue, 27 Aug 96 04:48:38 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA27741; Tue, 27 Aug 96 04:47:59 EDT Received: by relay.hq.tis.com; id EAA10107; Tue, 27 Aug 1996 04:48:37 -0400 Received: from servo.qualcomm.com(129.46.101.170) by relay.tis.com via smap (V3.1.1) id xma010105; Tue, 27 Aug 96 04:48:17 -0400 Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id BAA18913; Tue, 27 Aug 1996 01:50:37 -0700 (PDT) Date: Tue, 27 Aug 1996 01:50:37 -0700 (PDT) From: Phil Karn <karn@qualcomm.com> Message-Id: <199608270850.BAA18913@servo.qualcomm.com> To: rgm3@chrysler.com Cc: netsec@panix.com, ipsec@TIS.COM In-Reply-To: <3.0b11.32.19960826120815.00b16eb0@pop3hub.is.chrysler.com> (message from Robert Moskowitz on Mon, 26 Aug 1996 12:12:22 -0400) Subject: Re: "user" and "network layer" security. Sender: ipsec-approval@neptune.tis.com Precedence: bulk >I am working on my list of items that makes Oakley (and GKMP, did you see >the drafts just released?) on ISAKMP as the better mechanism for a >inter-business security. SKIP, it looks like can be made to work for the >intra-business model. After all it is simple and inter-business is not. Hmm, your "inter-business" and "intra-business" distinction is a very insightful one. My original goal for IPSEC was clearly to solve what you are calling the "intra-business" security problem, at least for the kind of business that doesn't have so many internal compartments that it is really a bunch of completely separate businesses under one roof. As you say, the other model is a LOT more complicated. I think the intER-business problem is better left to the application layer security guys. There certainly are many more of them on the job now than a few years ago, and some knowledgeable customers do seem to like what they're doing. For example, Bank of America and Wells Fargo both support home banking via secure Netscape. I can't think of any non-governmental entity more conservative on security than a bank, so it seems they must have conducted at least *some* level of in-house security review. Especially since under the current banking laws, the banks assume most of the risk of a security breach just as they do with credit cards. Phil Received: from relay.hq.tis.com by neptune.TIS.COM id aa21623; 27 Aug 96 7:37 EDT Received: by relay.hq.tis.com; id OAA24938; Mon, 26 Aug 1996 14:13:46 -0400 From: wobber@pa.dec.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma024920; Mon, 26 Aug 96 14:13:36 -0400 Received: from london.eu.tis.com by tis.com (4.1/SUN-5.64) id AA01797; Mon, 26 Aug 96 14:12:47 EDT Received: from relay.eu.tis.com (firewall-user@relay.eu.tis.com [10.217.55.100]) by london.eu.tis.com (8.7.3/8.7.3) with ESMTP id TAA03721 for <ipsec@tis.com>; Mon, 26 Aug 1996 19:11:18 +0100 (BST) Received: by relay.eu.tis.com; id PAA06248; Mon, 26 Aug 1996 15:07:18 +0100 (BST) Received: from mail1.digital.com(204.123.2.50) by relay.eu.tis.com via smap (V3.1.1) id xma006246; Mon, 26 Aug 96 15:06:57 +0100 Received: from hickory.pa.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA12758; Mon, 26 Aug 1996 11:02:36 -0700 Received: by hickory.pa.dec.com; id AA02275; Mon, 26 Aug 1996 11:01:36 -0700 Message-Id: <9608261801.AA02275@hickory.pa.dec.com> To: William Allen Simpson <wsimpson@greendragon.com> Cc: ipsec@TIS.COM, wobber@pa.dec.com Subject: Re: "user" and "network layer" security mechanisms. In-Reply-To: Message of Mon, 26 Aug 96 7:16:18 EDT from William Allen Simpson <wsimpson@greendragon.com> <5476.wsimpson@greendragon.com> Date: Mon, 26 Aug 96 11:01:36 -0700 X-Mts: smtp Sender: ipsec-approval@neptune.tis.com Precedence: bulk >> For the great class of usage, firewall to firewall tunnels (where only >> network origination is authenticated), or laptop to firewall, IP >> "network-layer" security easily handles those needs. The "user" or >> "principle" or "party" maps nicely to the IP address. This works fine for folks whose laptop or PC is equipped with a static IP address. What about everyone else? For a majority of computers, IP addresses aren't meaningful for security. When a user has complete physical control over a computer (such as a laptop) there can be no realistic node-level security without special hardware. In this environment, IP addresses serve as a convenient indirection for operating systems and communication protocols that can't easily deal with user names. Although we could build a security infrastructure that institutionalizes IP addresses as shorthand for user identities, is this really a good idea for the long term? Ted Wobber DEC Systems Research Center Date: Mon, 26 Aug 1996 17:56:28 -0400 From: "Mitchell C. Nelson" <nelson@mcn.netsec.com> Message-Id: <199608262156.RAA00328@mcn.netsec.com> To: ipsec@TIS.COM, karn@qualcomm.com Subject: A renewed IPSEC ("user" and "network layer" security). Sender: ipsec-approval@neptune.tis.com Precedence: bulk I am sorry that I did not read Phil's note of Aug 25 before sending my note on Aug 26. I agree with Phil's suggestion regarding SKIP, and I suggest that we proceed along those lines. Also, I think that the IPSEC charter should be revised to focus more explicitly on network layer security. The task should be well defined, as a first step towards producing the best possible result. (Application layer security can be the well defined task of an APPSEC working group.) SKIP seems to reflect reasonable objectives of network layer security. Still it would probably be a useful exercise to try and summarize what those objectives are. Meanwhile I suggest that we set a reasonable minimum period of time for renewed discussion of the SKIP proposal in its details. Mitch Nelson netsec@panix.com >From Phil Karn: >>"User" based security and "network layer" security can each be designed >>and implemented in ways that are consistent with the established network >>architecture. With some pro-forma cross consultation, one should expect >>to arrive at reasonable results that provide good security without >>conflict and without unduly compromising present network functionality. >>The alternative does not offer as much grounds for optimism. Therefore >>it seems that all lanquage related to "user" should be expunged from >>IPSEC and instead treated in a seperate discussion group. (quoted by from M.C.Nelson of 8/16) >I couldn't agree more. As one of the originators of the IPSEC group, I >have watched with increasing resignation for the last four years as my >original idea has grown completely out of control, with very little to >show for it. ..... >If the IPSEC group's work is to ever have any relevance, it must >return to the original, bare-bones goal of building protected >"tunnels" at the host-to-host or subnet-to-subnet level of >granularity. There's still plenty of need for this function, but >trying to do more than this is likely to continue to get us nowhere. > >In this light, SKIP keeps looking better to me all the time. Its claim >to the "simple" label certainly keeps getting stronger. The only real >problem I've ever had with it was the lack of perfect forward secrecy >(PFS) in the original design. But that's in there too. So other than >the lack of support for a facility (user-oriented keying) that we >can't really do properly anyway, what's wrong with it? Date: Tue, 27 Aug 96 15:10:42 GMT From: William Allen Simpson <wsimpson@greendragon.com> MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Message-Id: <5478.wsimpson@greendragon.com> To: ipsec@TIS.COM Subject: Re: "user" and "network layer" security mechanisms. Sender: ipsec-approval@neptune.tis.com Precedence: bulk I'm sorry, I was insufficiently clear. The IP address (in my list of scenarios) is part of the IP address plus SPI -- a temporary shorthand for party/principle/user identities. There is no need for the IP address to remain static. You still need some key management exchange to bind an "identity" with the IP address plus SPI combination. > From: wobber@pa.dec.com > This works fine for folks whose laptop or PC is equipped with a static > IP address. What about everyone else? > WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 Received: from relay.hq.tis.com by neptune.TIS.COM id aa25794; 27 Aug 96 12:32 EDT Received: by relay.hq.tis.com; id MAA20145; Tue, 27 Aug 1996 12:35:27 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma020135; Tue, 27 Aug 96 12:35:05 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA16143; Tue, 27 Aug 96 12:34:22 EDT Received: by relay.hq.tis.com; id MAA20130; Tue, 27 Aug 1996 12:34:57 -0400 Received: from capone.ch.apollo.hp.com(15.254.24.3) by relay.tis.com via smap (V3.1.1) id xma020127; Tue, 27 Aug 96 12:34:53 -0400 Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id <AA078113831@capone.ch.apollo.hp.com>; Tue, 27 Aug 1996 12:37:11 -0400 Received: from thunk (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.6.12/8.6.12) with ESMTP id MAA01312; Tue, 27 Aug 1996 12:37:06 -0400 Message-Id: <199608271637.MAA01312@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: Phil Karn <karn@qualcomm.com> Cc: rgm3@chrysler.com, netsec@panix.com, ipsec@TIS.COM Subject: Re: "user" and "network layer" security. In-Reply-To: karn's message of Tue, 27 Aug 1996 01:50:37 -0700. <199608270850.BAA18913@servo.qualcomm.com> Date: Tue, 27 Aug 1996 12:36:07 -0400 From: Bill Sommerfeld <sommerfeld@apollo.hp.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk i'd actually argue that there are a bunch of different niches.. Inter-business vs intra-business oversimplifies the situation. The "intrabusiness" niche covers a quite broad spectrum, from small workgroups to large enterprises. The "interbusiness" niche also covers a broad spectrum, depending on the nature of the business relationship -- is it a casual one-shot deal (a quantity-one catalog order of a commodity from the low bidder of the day), or a committed multi-year multi-megabuck relationship? In the latter case, you organization may well have a closer working relationship with its opposite number in the other company than with other organizations from your same company... so your computers may well need to have a similarly "close" relationship... - Bill To: Phil Karn <karn@qualcomm.com> Cc: rgm3@chrysler.com, ipsec@TIS.COM Subject: Re: "user" and "network layer" security. In-Reply-To: Your message of "Tue, 27 Aug 1996 01:50:37 PDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 27 Aug 1996 11:05:06 -0400 From: "Perry E. Metzger" <perry@piermont.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9608271235.aa25853@neptune.TIS.COM> Phil Karn writes: > For example, Bank of America and Wells Fargo both support home banking > via secure Netscape. 40 bit RC4 based SSL... > I can't think of any non-governmental entity more conservative on > security than a bank, so it seems they must have conducted at least > *some* level of in-house security review. Especially since under the > current banking laws, the banks assume most of the risk of a > security breach just as they do with credit cards. I hate to slander clients, but... I make a considerable fraction of my money telling banks how to keep themselves secure. You would be surprised at how bad some of what they do is. They mean much better, of course, and they are willing to spend the money when they know what they want, but they often don't know good security from bad security -- they are still in many cases building up the expertise, and its hard to get with things moving as fast as they do now. The world of networks is as new to them as it is to most businesses. Some banks are much better than others, of course. IPSec has several advantages over application layer protocols, by the way, not the least of which is that the signaling can be protected. Try defending your BGP-4 TCP connections from spurious RSTs with application layer defenses, for example... Its also nice to build the security system once and have it there always when you want it. I know all this goes beyond what you and others originally envisioned for swIPe and such, but it isn't an unreasonable use of the technology. Perry Date: Tue, 27 Aug 1996 14:56:25 -0400 To: Phil Karn <karn@qualcomm.com>, rgm3@chrysler.com From: Robert Moskowitz <rgm3@chrysler.com> Subject: Re: "user" and "network layer" security. Cc: netsec@panix.com, ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9608271457.aa28918@neptune.TIS.COM> At 01:50 AM 8/27/96 -0700, Phil Karn wrote: > >I think the intER-business problem is better left to the application >layer security guys. There certainly are many more of them on the job >now than a few years ago, and some knowledgeable customers do seem to >like what they're doing. Won't ever happen too many of them and not enough security smarts. Other complexities too. I've been studing this area for a few years now and dealing with vendors. I can no longer wait for them to move security from page 8 of enhancements to the top. Where you have seen security added is the easy stuff, the top of the iceburg. >For example, Bank of America and Wells Fargo both support home banking >via secure Netscape. No comparison to business to business issues. The trust model is much more complex. >I can't think of any non-governmental entity more >conservative on security than a bank, so it seems they must have >conducted at least *some* level of in-house security >review. Especially since under the current banking laws, the banks >assume most of the risk of a security breach just as they do with >credit cards. Simple, the banks extend their security model to their clientel. Can't do than in a business to business anymore. I am deploying 3 applications like that right now for up to 4,000 separate business and there are major concerns if we will ever get it past a few hundred. Robert Moskowitz Chrysler Corporation (810) 758-8212 Date: Tue, 27 Aug 1996 14:56:29 -0400 To: Bill Sommerfeld <sommerfeld@apollo.hp.com>, Phil Karn <karn@qualcomm.com> From: Robert Moskowitz <rgm3@chrysler.com> Subject: Re: "user" and "network layer" security. Cc: rgm3@chrysler.com, netsec@panix.com, ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9608271459.aa28948@neptune.TIS.COM> At 12:36 PM 8/27/96 -0400, Bill Sommerfeld wrote: > >Inter-business vs intra-business oversimplifies the situation. Oh course, any handle oversimplifies. >The "intrabusiness" niche covers a quite broad spectrum, from small >workgroups to large enterprises. The major difference is one of trust. Even in Chrysler, there is an assumed trust level (except between corporate and engineering ;). >The "interbusiness" niche also covers a broad spectrum, depending on >the nature of the business relationship -- is it a casual one-shot >deal (a quantity-one catalog order of a commodity from the low bidder >of the day), or a committed multi-year multi-megabuck relationship? We have them both. >In the latter case, you organization may well have a closer working >relationship with its opposite number in the other company than with >other organizations from your same company... so your computers may >well need to have a similarly "close" relationship... Ain't it the truth! But there is trust. We do not run/configure the systems over at GE Plastics. Definitely not the networks. So what do we do today? Put to systems on the poor guy's desk and two networks in GE (actually more as there is a Ford and GM network presense too). Robert Moskowitz Chrysler Corporation (810) 758-8212 Date: Tue, 27 Aug 1996 14:56:27 -0400 To: perry@piermont.com, Phil Karn <karn@qualcomm.com> From: Robert Moskowitz <rgm3@chrysler.com> Subject: Re: "user" and "network layer" security. Cc: rgm3@chrysler.com, ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9608271515.aa29325@neptune.TIS.COM> At 11:05 AM 8/27/96 -0400, Perry E. Metzger wrote: > >I make a considerable fraction of my money telling banks how to keep >themselves secure. You would be surprised at how bad some of what they >do is. They mean much better, of course, and they are willing to spend >the money when they know what they want, but they often don't know >good security from bad security -- they are still in many cases >building up the expertise, and its hard to get with things moving as >fast as they do now. The world of networks is as new to them as it is >to most businesses. Some banks are much better than others, of course. Now take that to the CAD people, the MRP, the ERP, etc that have no comprehension of this stuff. In San Jose, ask me about one experience with an MRP company.... Robert Moskowitz Chrysler Corporation (810) 758-8212 To: Bill Sommerfeld <sommerfeld@apollo.hp.com> Cc: ipsec@TIS.COM Subject: Re: "user" and "network layer" security. In-Reply-To: Your message of "Tue, 27 Aug 1996 12:36:07 EDT." <199608271637.MAA01312@thunk.orchard.medford.ma.us> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 27 Aug 1996 15:21:55 -0400 From: "Perry E. Metzger" <perry@piermont.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9608271525.aa29584@neptune.TIS.COM> Bill Sommerfeld writes: > i'd actually argue that there are a bunch of different niches.. > > Inter-business vs intra-business oversimplifies the situation. Strongly agreed. BTW, IPSec is cool in many ways because it is flexible. It can be used to build virtual private networks, or it can be used to secure an individual TCP connection, or for other things. As such, I think its a good mechanism in general... Perry Received: from relay.hq.tis.com by neptune.TIS.COM id aa02960; 27 Aug 96 18:21 EDT Received: by relay.hq.tis.com; id SAA03456; Tue, 27 Aug 1996 18:24:50 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma003448; Tue, 27 Aug 96 18:24:28 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA07417; Tue, 27 Aug 96 18:23:47 EDT Received: by relay.hq.tis.com; id SAA03438; Tue, 27 Aug 1996 18:24:21 -0400 Received: from servo.qualcomm.com(129.46.101.170) by relay.tis.com via smap (V3.1.1) id xma003431; Tue, 27 Aug 96 18:24:16 -0400 Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id PAA28724; Tue, 27 Aug 1996 15:26:06 -0700 (PDT) Date: Tue, 27 Aug 1996 15:26:06 -0700 (PDT) From: Phil Karn <karn@qualcomm.com> Message-Id: <199608272226.PAA28724@servo.qualcomm.com> To: perry@piermont.com Cc: rgm3@chrysler.com, ipsec@TIS.COM In-Reply-To: <199608271505.LAA29220@jekyll.piermont.com> (perry@piermont.com) Subject: Re: "user" and "network layer" security. Sender: ipsec-approval@neptune.tis.com Precedence: bulk >40 bit RC4 based SSL... Excerpted from http://wellsfargo.com/nav/security2/: You can use International grade security for most Internet Banking functions EXCEPT the Internet Bill Payment Service. To access the Internet Bill Payment service, you will need to use an Internet browser that contains "U.S." or "Domestic" grade security encryption. --Phil Received: from relay.hq.tis.com by neptune.TIS.COM id aa04252; 27 Aug 96 19:43 EDT Received: by relay.hq.tis.com; id QAA00754; Tue, 27 Aug 1996 16:41:53 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma000742; Tue, 27 Aug 96 16:41:23 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA01937; Tue, 27 Aug 96 16:40:42 EDT Received: by relay.hq.tis.com; id QAA00733; Tue, 27 Aug 1996 16:41:20 -0400 Received: from dns1.noc.best.net(206.86.8.69) by relay.tis.com via smap (V3.1.1) id xma000725; Tue, 27 Aug 96 16:41:08 -0400 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns1.noc.best.net (8.6.12/8.6.5) with ESMTP id NAA01360; Tue, 27 Aug 1996 13:40:52 -0700 Received: from [206.79.9.153] ([206.79.9.153]) by shellx.best.com (8.6.12/8.6.5) with SMTP id NAA10262; Tue, 27 Aug 1996 13:37:41 -0700 Date: Tue, 27 Aug 1996 13:37:41 -0700 Message-Id: <v02140b01ae4879d17e1f@[206.79.9.153]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipsec@TIS.COM, nelson@mcn.netsec.com From: John Lawler <jlawler@vpnet.com> Subject: Re: A renewed IPSEC Sender: ipsec-approval@neptune.tis.com Precedence: bulk As has been made clear at the last few IETF meetings, our company is neutral about the "key management wars"--we will support whatever standard is selected. However, we feel very strongly that there is customer demand for network security today, and we and other companies need to ship products to meet those demands. Moreover, the Internet market which has sped up *considerably* over the last year. WE CANNOT AFFORD TO FURTHER DELAY THE DEVELOPMENT OF THIS INDUSTRY. Our company has examined both specifications closely, and we will certainly support whatever standard emerges. However, while we believe that both SKIP and ISAKMP have significant benefits, it is our position that at this time, SKIP is the more mature proposal. We concur with Phil Karn (one of the originators of the IPSEC group) that SKIP is simple and effective. From our independent vantage point, it appears that every "complaint" about SKIP has been addressed: perfect forward secrecy has been added, multicast support has been strengthened. That being the case, we believe it is in everyone's best interests for SKIP to proceed to the next phase in the standards process so that commercially shipping products can be developed in a timely manner. John Lawler | "Fifty-five crystal spheres geared VPNet | to God's crankshaft is my idea of a 555 North Mathilda Ave, Suite. 110 | satisfying universe." Sunnyvale, CA 94086 | -- "Arcadia", Tom Stoppard (408) 720-7618 jlawler@vpnet.com | To: Phil Karn <karn@qualcomm.com> Cc: ipsec@TIS.COM Subject: Re: "user" and "network layer" security. In-Reply-To: Your message of "Tue, 27 Aug 1996 15:26:06 PDT." <199608272226.PAA28724@servo.qualcomm.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 27 Aug 1996 18:33:19 -0400 From: "Perry E. Metzger" <perry@piermont.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9608280729.aa12048@neptune.TIS.COM> Phil Karn writes: > >40 bit RC4 based SSL... > > Excerpted from http://wellsfargo.com/nav/security2/: > > You can use International grade security for most Internet Banking > functions EXCEPT the Internet Bill Payment Service. To access the > Internet Bill Payment service, you will need to use an Internet > browser that contains "U.S." or "Domestic" grade security encryption. They've come a long way, then... Perry Received: from relay.hq.tis.com by neptune.TIS.COM id aa14831; 28 Aug 96 11:11 EDT Received: by relay.hq.tis.com; id LAA16912; Wed, 28 Aug 1996 11:14:24 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma016905; Wed, 28 Aug 96 11:13:56 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA03925; Wed, 28 Aug 96 11:13:15 EDT Received: by relay.hq.tis.com; id LAA16897; Wed, 28 Aug 1996 11:13:54 -0400 Received: from fnal.fnal.gov(131.225.110.17) by relay.tis.com via smap (V3.1.1) id xma016891; Wed, 28 Aug 96 11:13:26 -0400 Received: from munin.fnal.gov ("port 4805"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I8T0KNC1YI0024II@FNAL.FNAL.GOV>; Wed, 28 Aug 1996 10:15:40 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m) id KAA02277; Wed, 28 Aug 1996 10:13:46 -0500 (CDT) Date: Wed, 28 Aug 1996 10:13:39 -0500 From: Matt Crawford <crawdad@fnal.gov> Subject: Re: "user" and "network layer" security. In-Reply-To: "27 Aug 1996 18:33:19 EDT." <"9608280729.aa12048"@neptune.TIS.COM> To: perry@piermont.com Cc: Phil Karn <karn@qualcomm.com>, ipsec@TIS.COM MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Message-Id: <199608281513.KAA02277@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{<k&QF?d6L7o&zLqb%kXn!!]ykXMKtTiy9#20]$EKP/^Z$T]'P6, 8L#r&mH4PB<ljN,_.=iCpv#N:HIcy5t7{HV:<=g=V?^;-d,J*xkq0r Sender: ipsec-approval@neptune.tis.com Precedence: bulk > > Excerpted from http://wellsfargo.com/nav/security2/: > > To access the Internet Bill Payment service, you will need to > > use an Internet browser that contains "U.S." or "Domestic" > > grade security encryption. > They've come a long way, then... > Perry Maybe Wells Fargo has better consultants than the New York banks you're familiar with. ;-) Matt Received: from relay.hq.tis.com by neptune.TIS.COM id aa18536; 28 Aug 96 15:32 EDT Received: by relay.hq.tis.com; id PAA25872; Wed, 28 Aug 1996 15:35:58 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma025826; Wed, 28 Aug 96 15:35:35 -0400 Received: from sol.hq.tis.com by tis.com (4.1/SUN-5.64) id AA26652; Wed, 28 Aug 96 15:34:54 EDT Message-Id: <9608281934.AA26652@tis.com> To: ipsec@TIS.COM Subject: Will the real PFS please stand up? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <26608.841260883.1@tis.com> Date: Wed, 28 Aug 1996 15:34:51 -0400 From: "David M. Balenson" <balenson@TIS.COM> Sender: ipsec-approval@neptune.tis.com Precedence: bulk I'd like to ask folks exactly what they mean by perfect forward secrecy? The recent ID on SKIP extension for Perfect Forward Secrecy (PFS) uses the term, but never actually defines it. (I think there should be a definition, to ensure clarity and consistency.) The latest ID draft-ietf-ipsec-isakmp-05.txt defines it (which is good), but while the definition may be more intuitive, it is BACKWARDS from what appeared in all the earlier drafts, as well as what I understand to be the traditional meaning. The best definition I know of is actually in the Diffie/Van Oorschot/ Wiener paper on Authentication and Authenticated Key Exchanges. Regards, -DB --------------------------------------------------------------------------- David M. Balenson Trusted Information Systems, 3060 Washington Rd., Glenwood, MD 21738 USA balenson@tis.com; tel 301.854.5358; fax 301.854.5363 Received: from relay.hq.tis.com by neptune.TIS.COM id aa19157; 28 Aug 96 16:24 EDT Received: by relay.hq.tis.com; id QAA27708; Wed, 28 Aug 1996 16:27:54 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma027696; Wed, 28 Aug 96 16:27:32 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA03806; Wed, 28 Aug 96 16:26:46 EDT Received: by relay.hq.tis.com; id QAA27684; Wed, 28 Aug 1996 16:27:24 -0400 Received: from capone.ch.apollo.hp.com(15.254.24.3) by relay.tis.com via smap (V3.1.1) id xma027654; Wed, 28 Aug 96 16:27:11 -0400 Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id <AA132594167@capone.ch.apollo.hp.com>; Wed, 28 Aug 1996 16:29:27 -0400 Received: from thunk (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.6.12/8.6.12) with ESMTP id QAA00220; Wed, 28 Aug 1996 16:29:26 -0400 Message-Id: <199608282029.QAA00220@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: "David M. Balenson" <balenson@TIS.COM> Cc: ipsec@TIS.COM Subject: Re: Will the real PFS please stand up? In-Reply-To: balenson's message of Wed, 28 Aug 1996 15:34:51 -0400. <9608281934.AA26652@tis.com> Date: Wed, 28 Aug 1996 16:29:23 -0400 From: Bill Sommerfeld <sommerfeld@apollo.hp.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk On a related note, the skip-pfs draft does PFS in a different way from how it's done in the other protocols. Now, I don't consider myself a cryptographer, but something in skip-pfs struck me as somewhat unconventional... This is not the first time that I've raised this issue, but I don't think it's been resolved.. As I read the draft, skip-pfs does not provide PFS protection of the identity certificates of the communicating parties. The exchange is: I->J: { g^x, g, p, [Cert_I]g^xj, EMKID_J_I}Kij J->I: { g^y, g, p, [Cert_J]g^xj, EMKID_J_I, EMKID_I_J}Kij (key: i,j: long term secrets of I and J x,y: ephemeral secrets [encryption] {integrity protection}) The resulting traffic is protected using a key derived from g^xy, which seems to be OK. What concerns me is the use of g^xj to protect the ephemeral certificates; it appears to me as if subsequent compromise of j will allow an eavesdropper to decrypt previously recorded [Cert_I]g^xj, revealing the identities of everyone who has corresponded with j during the period of interest. Now, if I and J are just host identities, this isn't interesting (because the same information is found in their IP addresses) but if SKIP gets extended to do per-user keying I think we have a potential problem. It would be fairly simple to fix this by adding another round trip, but the resulting protocol would would look a lot like OAKLEY or Photuris. - Bill Received: from relay.hq.tis.com by neptune.TIS.COM id aa20732; 28 Aug 96 18:42 EDT Received: by relay.hq.tis.com; id SAA03606; Wed, 28 Aug 1996 18:45:38 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma003602; Wed, 28 Aug 96 18:45:09 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA13658; Wed, 28 Aug 96 18:44:28 EDT Received: by relay.hq.tis.com; id SAA03599; Wed, 28 Aug 1996 18:45:08 -0400 Received: from servo.qualcomm.com(129.46.101.170) by relay.tis.com via smap (V3.1.1) id xma003594; Wed, 28 Aug 96 18:44:50 -0400 Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id PAA09951; Wed, 28 Aug 1996 15:47:08 -0700 (PDT) Date: Wed, 28 Aug 1996 15:47:08 -0700 (PDT) From: Phil Karn <karn@qualcomm.com> Message-Id: <199608282247.PAA09951@servo.qualcomm.com> To: balenson@TIS.COM Cc: ipsec@TIS.COM In-Reply-To: <9608281934.AA26652@tis.com> (balenson@TIS.COM) Subject: Re: Will the real PFS please stand up? Sender: ipsec-approval@neptune.tis.com Precedence: bulk >I'd like to ask folks exactly what they mean by perfect forward secrecy? Fair enough. Perfect forward secrecy means a key management protocol and implementation in which keys actually used to encrypt traffic (e.g., the keys in a ESP security association) are periodically changed such that prior traffic keys cannot be recovered (and prior encrypted traffic cannot be decrypted) even when the attacker has a complete recording of all traffic and a complete readout of all *current* machine state for both parties. "Current state" includes all long-lived secret keys, but does *not* include any state that was destroyed at the last traffic key change. Phil Received: from relay.hq.tis.com by neptune.TIS.COM id aa21391; 28 Aug 96 19:48 EDT Received: by relay.hq.tis.com; id TAA04467; Wed, 28 Aug 1996 19:51:36 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma004463; Wed, 28 Aug 96 19:51:12 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA15243; Wed, 28 Aug 96 19:50:27 EDT Received: by relay.hq.tis.com; id TAA04457; Wed, 28 Aug 1996 19:51:06 -0400 Received: from inet-user-gw-1.us.oracle.com(192.86.155.82) by relay.tis.com via smap (V3.1.1) id xma004454; Wed, 28 Aug 96 19:50:53 -0400 Received: from mailsun2.us.oracle.com by inet-user-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id QAA23332; Wed, 28 Aug 1996 16:52:32 -0700 Received: by mailsun2.us.oracle.com (SMI-8.6/37.8) id QAA28966; Wed, 28 Aug 1996 16:51:21 -0700 Message-Id: <199608282351.QAA28966@mailsun2.us.oracle.com> Date: 28 Aug 96 16:46:18 -0700 From: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com> To: ipsec@TIS.COM Subject: Re: "user" and "network layer" security. reply to respondents. Cc: nelson@mcn.netsec.com X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-request@neptune.hq.tis.com's message of 25-Aug-96 23:09 Mime-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.0.2.1.40) Content-Type: multipart/mixed; boundary="=_ORCL_6958916_0_11919608281752200" Sender: ipsec-approval@neptune.tis.com Precedence: bulk --=_ORCL_6958916_0_11919608281752200 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" >Issue #1: > > Is it appropriate for IPSEC to break network architecture, given > the absence of experience implementing security on the proposed > scale? IPsec does not break the "Internet Architecture". The use of the term "user" with IPsec security associations is confusing, but not inappropriate for some scenarios. Key management is an application layer activity where the security associations are created and provide authentication to peer application layer entities. The security association is then available to be used by ESP, AH or perhaps other security mechanisms. The authentication provided by applicaitons can be at the granularity of a "user". The use of the resulting authenticaiton process can be enforced at the network layer using ESP or AH. There is significant experience fielding network layer security by various governments and defense contractors. There is also significant experience by many commercial vendors in the fielding of proprietary implementations of network layer security technologies. > >Issue #2: > > Where is it established that network layer mechanisms should be > used to implement application layer security? Should? Secure systems can be built from many mechanisms. IPsec provides application layer authentication (key management) that can be used by a network layer security mechanism (ESP and/or AH). I do agree that there are issues with "user-oriented" versus "network-oriented" security. My issue is with the information bound to a security association. The definition of naming approaches (public key infrastructure etc.) has moved even slower then IPsec :-) The real issue that needs to be addressed is the naming framework that we are building into our security architecture. One aspect of these names might be "what" they represent. Paul -------------------------------------------------------------- --=_ORCL_6958916_0_11919608281752200 Content-Type:message/rfc822 Date: 25 Aug 96 23:09:58 From:"Mitchell C. Nelson <nelson@mcn.netsec.com>" <ipsec-request@neptune.hq.tis.com> To:ipsec@tis.com Subject:"user" and "network layer" security. reply to respondents. Sender:ipsec-approval@neptune.hq.tis.com Precedence: bulk MIME-Version: 1.0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" The term "user" is undefined in the network layer of IP. It has no sensible context in a discussion of *network layer* security mechanisms. Moreover, introducing a parameter to the network layer that corresponds to "user", breaks the network architecture. These are basic facts of IP architecture. The basic facts of IP architecture are established by agreed upon definition. Important issues are raised by these basic facts. Arguments such as those based on suggested hacks of network codes and operating systems, are all specious with respect to the real issues. Issue #1: Is it appropriate for IPSEC to break network architecture, given the absence of experience implementing security on the proposed scale? Issue #2: Where is it established that network layer mechanisms should be used to implement application layer security? Regards, Mitch Nelson netsec@panix --=_ORCL_6958916_0_11919608281752200-- Received: from relay.hq.tis.com by neptune.TIS.COM id aa25526; 29 Aug 96 2:41 EDT Received: by relay.hq.tis.com; id CAA08451; Thu, 29 Aug 1996 02:44:34 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma008449; Thu, 29 Aug 96 02:44:09 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA22828; Thu, 29 Aug 96 02:43:24 EDT Received: by relay.hq.tis.com; id CAA08446; Thu, 29 Aug 1996 02:44:04 -0400 Received: from vesuv.rz.tu-ilmenau.de(141.24.4.2) by relay.tis.com via smap (V3.1.1) id xma008444; Thu, 29 Aug 96 02:43:37 -0400 Received: from PrakInf.TU-Ilmenau.DE (actually atlantis.PrakInf.TU-Ilmenau.DE) by vesuv.rz.tu-ilmenau.de with SMTP (PP); Thu, 29 Aug 1996 08:45:32 +0000 Received: from remus.prakinf by PrakInf.TU-Ilmenau.DE (4.1/SMI-4.1(mailhost)) id AA25469; Thu, 29 Aug 96 08:45:29 +0200 Date: Thu, 29 Aug 96 08:45:29 +0200 From: Holger Reif <Holger.Reif@prakinf.tu-ilmenau.de> Message-Id: <9608290645.AA25469@PrakInf.TU-Ilmenau.DE> To: perry@piermont.com Subject: Re: "user" and "network layer" security. Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk > > Excerpted from http://wellsfargo.com/nav/security2/: > > To access the Internet Bill Payment service, you will need to > > use an Internet browser that contains "U.S." or "Domestic" > > grade security encryption. > They've come a long way, then... > Perry They even closed their site when the PRNG bug of netscape navigator was discovered last year. Obviously they understood the implications. Or where at least told about them. read you later - Holger Reif ---------------------------------------- Signaturprojekt Deutsche Einheit TU Ilmenau - Informatik - Telematik (Verdamp lang her) Holger.Reif@PrakInf.TU-Ilmenau.DE Alt wie ein Baum werden, um ueber http://Remus.PrakInf.TU-Ilmenau.DE/Reif/ alle 7 Bruecken gehen zu koennen Received: from relay.hq.tis.com by neptune.TIS.COM id aa28249; 29 Aug 96 6:24 EDT Received: by relay.hq.tis.com; id GAA10002; Thu, 29 Aug 1996 06:27:22 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma009994; Thu, 29 Aug 96 06:26:54 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA26393; Thu, 29 Aug 96 06:26:12 EDT Received: by relay.hq.tis.com; id GAA09988; Thu, 29 Aug 1996 06:26:52 -0400 Received: from tik1.ethz.ch(129.132.119.131) by relay.tis.com via smap (V3.1.1) id xma009983; Thu, 29 Aug 96 06:26:34 -0400 Received: from kom30.ethz.ch (kom30 [129.132.66.8]) by tik1.ethz.ch (8.7.5/8.7.3) with ESMTP id MAA18289; Thu, 29 Aug 1996 12:28:24 +0200 (MET DST) From: Germano Caronni <caronni@tik.ee.ethz.ch> Received: (from caronni@localhost) by kom30.ethz.ch (8.7.5/8.7.3) id MAA03328; Thu, 29 Aug 1996 12:28:19 +0200 (MET DST) Message-Id: <199608291028.MAA03328@kom30.ethz.ch> Subject: Anonymity vs PFS (was: Will the real PFS please stand up?) To: Bill Sommerfeld <sommerfeld@apollo.hp.com> Date: Thu, 29 Aug 1996 12:28:18 +0200 (MET DST) Cc: ipsec@TIS.COM, Project SKIP <skip@tik.ee.ethz.ch> In-Reply-To: <199608282029.QAA00220@thunk.orchard.medford.ma.us> from "Bill Sommerfeld" at Aug 28, 96 04:29:23 pm X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk Bill Sommerfeld wrote: > As I read the draft, skip-pfs does not provide PFS protection of the > identity certificates of the communicating parties. [...] > > The exchange is: > > I->J: { g^x, g, p, [Cert_I]g^xj, EMKID_J_I}Kij > J->I: { g^y, g, p, [Cert_J]g^xj, EMKID_J_I, EMKID_I_J}Kij [...] > What concerns me is the use of g^xj to protect the ephemeral > certificates; it appears to me as if subsequent compromise of j will > allow an eavesdropper to decrypt previously recorded [Cert_I]g^xj, > revealing the identities of everyone who has corresponded with j > during the period of interest. [...] Well, as I see it, SKIP PFS provides PFS (see the definiton of Phil Karn, to which I fully agree) but it does not provide *perfect* anonymity. Anonymity of participants and forward secrecy of communications really are orthogonal properties. If I remember correctly, we already had this discussion a few months ago? One (rather old) answer was: ] One solution for anonymity for mobile users is to have anonymous ] principal ids (either per host or per user) (represented by private keys ] in smart cards or encrypted in some user password) that can be handed out ] to mobile users. ] These anonymous smart cards can be rotated among users, so that it isn't ] possible to know who is using a particular anonymous principal ] ID at any point in time. ] This can be implemented with SKIP, without requiring any change to the ] protocol. This was an organisational solution to the whole issue even before PFS was done. Unfortunatedly I have other relevant parts of my archives at the wrong place, so I can not dig up 'conclusions', if there were any, which I doubt. By the way, by using unsigned DH public values as defined in *-udh-* as Cert_I and Cert_J, you get true anonymity, and perfect forward secrecy. Actually, beacuse of the flexibility of SKIP and its namespace approach, which I confess to like very much ;-), you can combine three types of 'certificates' and use one of them for each side of the message exchange. The three types are 'unsigned ephemeral', 'signed ephemeral' and 'conventional' certificates. For each two of these combined you get some nifty properties for the 'security association', and all of this can be easily done using the certificate discovery protocol, independant of the underlying key management proposal;-) Germano Date: Thu, 29 Aug 1996 07:02:25 -0400 To: Bill Sommerfeld <sommerfeld@apollo.hp.com>, "David M. Balenson" <balenson@TIS.COM> From: Robert Moskowitz <rgm3@chrysler.com> Subject: Re: Will the real PFS please stand up? Cc: ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9608290746.aa29081@neptune.TIS.COM> At 04:29 PM 8/28/96 -0400, Bill Sommerfeld wrote: > >The exchange is: > >I->J: { g^x, g, p, [Cert_I]g^xj, EMKID_J_I}Kij >J->I: { g^y, g, p, [Cert_J]g^xj, EMKID_J_I, EMKID_I_J}Kij > > (key: i,j: long term secrets of I and J > x,y: ephemeral secrets > [encryption] > {integrity protection}) > >The resulting traffic is protected using a key derived from g^xy, >which seems to be OK. > >What concerns me is the use of g^xj to protect the ephemeral >certificates; it appears to me as if subsequent compromise of j will >allow an eavesdropper to decrypt previously recorded [Cert_I]g^xj, >revealing the identities of everyone who has corresponded with j >during the period of interest. Does this mean that an escrowing of J can yield j? And thus escrowing is effective against SKIP PFS? If so, this is unexceptable. PFS must be immune to key escrowing. For those that are looking for NSA boogiemen everywhere, look carefully at this :) >Now, if I and J are just host identities, this isn't interesting >(because the same information is found in their IP addresses) but if >SKIP gets extended to do per-user keying I think we have a potential >problem. Huh? Please enlighten me. >It would be fairly simple to fix this by adding another round trip, >but the resulting protocol would would look a lot like OAKLEY or >Photuris. Meaning that these are not open to recorded attacks in this manner. But what about your comment: "if I and J are just host identities". How does this relate in Oakley or Photuris? Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.hq.tis.com by neptune.TIS.COM id aa29960; 29 Aug 96 9:11 EDT Received: by relay.hq.tis.com; id JAA12872; Thu, 29 Aug 1996 09:14:52 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma012866; Thu, 29 Aug 96 09:14:24 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA02291; Thu, 29 Aug 96 09:13:43 EDT Received: by relay.hq.tis.com; id JAA12859; Thu, 29 Aug 1996 09:14:22 -0400 Received: from tik1.ethz.ch(129.132.119.131) by relay.tis.com via smap (V3.1.1) id xma012841; Thu, 29 Aug 96 09:13:59 -0400 Received: from kom30.ethz.ch (kom30 [129.132.66.8]) by tik1.ethz.ch (8.7.5/8.7.3) with ESMTP id PAA20044; Thu, 29 Aug 1996 15:15:46 +0200 (MET DST) From: Germano Caronni <caronni@tik.ee.ethz.ch> Received: (from caronni@localhost) by kom30.ethz.ch (8.7.5/8.7.3) id PAA03573; Thu, 29 Aug 1996 15:15:44 +0200 (MET DST) Message-Id: <199608291315.PAA03573@kom30.ethz.ch> Subject: OAKLEY/ISAKMP/SKIP design group To: ipsec@TIS.COM Date: Thu, 29 Aug 1996 15:15:43 +0200 (MET DST) Cc: Project SKIP <skip@tik.ee.ethz.ch> X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk Hello everybody, When looking back at the past 1 1/2 years, and how IPSEC evolved, I kind of despair. Lots of progress were made all at the same time, and all in different directions, with lots of people pulling at different strings. I wonder how this will be going on. But, let me be a little more specific: To my deep sorrow, Hilarie Orman has announced the failure of the design group that was supposed to come up with a unified key management approach. It might be very interesting for the group as a whole to understand why this occurred. Could perhaps some of the group members elaborate on their respective views to what technical differences were not acquiescable? At the moment, I feel somewhat at a loss. Bot SKIP and OAKLEY/ISAKMP respectively Photuris have important properties, Robert Moskowitz, Phil Karn and others elaborated on the validity of the two approaches. Both approaches have substantial backing by a broader community, at least this is what I perceive. I personally prefer SKIP, because of its inherent simplicity and because its easily done - and verified - but after having invested substantial work in it, my not so humble opinion might be tainted. Some more untainted voices arguing for the one or the other approach would certainly be of interest to me... Perhaps the working group should reconsider, and let both approaches go forward on the standards track? Friendly greetings, Germano Caronni Received: from relay.hq.tis.com by neptune.TIS.COM id aa01455; 29 Aug 96 10:50 EDT Received: by relay.hq.tis.com; id KAA15453; Thu, 29 Aug 1996 10:58:23 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma015441; Thu, 29 Aug 96 10:57:56 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA15042; Thu, 29 Aug 96 10:57:14 EDT Received: by relay.hq.tis.com; id KAA15437; Thu, 29 Aug 1996 10:57:53 -0400 Received: from capone.ch.apollo.hp.com(15.254.24.3) by relay.tis.com via smap (V3.1.1) id xma015435; Thu, 29 Aug 96 10:57:46 -0400 Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id <AA241100802@capone.ch.apollo.hp.com>; Thu, 29 Aug 1996 11:00:02 -0400 Received: from thunk (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.6.12/8.6.12) with ESMTP id LAA00829; Thu, 29 Aug 1996 11:00:00 -0400 Message-Id: <199608291500.LAA00829@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: rgm3@chrysler.com Cc: "David M. Balenson" <balenson@TIS.COM>, ipsec@TIS.COM Subject: Re: Will the real PFS please stand up? In-Reply-To: rgm3's message of Thu, 29 Aug 1996 07:02:25 -0400. <3.0b11.32.19960829070029.00a20850@pop3hub.is.chrysler.com> Date: Thu, 29 Aug 1996 10:59:54 -0400 From: Bill Sommerfeld <sommerfeld@apollo.hp.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk > >What concerns me is the use of g^xj to protect the ephemeral > >certificates; it appears to me as if subsequent compromise of j will > >allow an eavesdropper to decrypt previously recorded [Cert_I]g^xj, > >revealing the identities of everyone who has corresponded with j > >during the period of interest. > > Does this mean that an escrowing of J can yield j? And thus escrowing is > effective against SKIP PFS? If so, this is unexceptable. PFS must be > immune to key escrowing. well, if we assume: a) escrowing of the long-term secret j b) no escrowing of the short-term secrets x and y then release of `j' from escrow will reveal the identity of the entities communicating with `J', but won't compromise their traffic. I'm not sure these assumptions about key escrow policy are realistic; in any situation where key escrow is mandated, skip-pfs, photuris, and OAKLEY will all be illegal as specified. > >Now, if I and J are just host identities, this isn't interesting > >(because the same information is found in their IP addresses) but if > >SKIP gets extended to do per-user keying I think we have a potential > >problem. > > Huh? Please enlighten me. Ok: A certificate creates a binding between a principal's name and its public key. If the `name' in the certificate is just an IP address, then compromise of the contents of Cert_I and Cert_J reveals no information not already available to eavesdroppers, and skip-pfs's lack of PFS protection on the exchanged certificates is moot. If the `name' in the certificate contains something other than an IP address, or something more than an IP address, then skip-pfs's lack of PFS protection on the exchanged certificates becomes interesting. > >It would be fairly simple to fix this by adding another round trip, > >but the resulting protocol would would look a lot like OAKLEY or > >Photuris. > > Meaning that these are not open to recorded attacks in this manner. Right; photuris doesn't exchange certificates until after a purely ephemeral DH exchange is completed. I believe OAKLEY has at least one mode which behaves the same way. > But what about your comment: "if I and J are just host identities". > How does this relate in Oakley or Photuris? As above.. if principal names are always IP addresses, there's no benefit in keeping them secret in the key mgt protocol because they're sent in the clear in every packet.. - Bill Received: from relay.hq.tis.com by neptune.TIS.COM id aa00673; 29 Aug 96 10:01 EDT Received: by relay.hq.tis.com; id KAA14204; Thu, 29 Aug 1996 10:06:53 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma014200; Thu, 29 Aug 96 10:06:40 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA07775; Thu, 29 Aug 96 10:05:45 EDT Received: by relay.hq.tis.com; id KAA14197; Thu, 29 Aug 1996 10:06:22 -0400 Received: from tik1.ethz.ch(129.132.119.131) by relay.tis.com via smap (V3.1.1) id xma014195; Thu, 29 Aug 96 10:06:02 -0400 Received: from kom30.ethz.ch (kom30 [129.132.66.8]) by tik1.ethz.ch (8.7.5/8.7.3) with ESMTP id QAA20645; Thu, 29 Aug 1996 16:08:17 +0200 (MET DST) From: Germano Caronni <caronni@tik.ee.ethz.ch> Received: (from caronni@localhost) by kom30.ethz.ch (8.7.5/8.7.3) id QAA03678; Thu, 29 Aug 1996 16:08:13 +0200 (MET DST) Message-Id: <199608291408.QAA03678@kom30.ethz.ch> Subject: Re: Will the real PFS please stand up? To: Robert Moskowitz <rgm3@chrysler.com> Date: Thu, 29 Aug 1996 16:08:12 +0200 (MET DST) Cc: ipsec@TIS.COM In-Reply-To: <9608290746.aa29081@neptune.TIS.COM> from "Robert Moskowitz" at Aug 29, 96 07:02:25 am X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk Robert Moskowitz wrote: > >What concerns me is the use of g^xj to protect the ephemeral > >certificates; it appears to me as if subsequent compromise of j will > >allow an eavesdropper to decrypt previously recorded [Cert_I]g^xj, > >revealing the identities of everyone who has corresponded with j > >during the period of interest. > > Does this mean that an escrowing of J can yield j? And thus escrowing is > effective against SKIP PFS? If so, this is unexceptable. PFS must be > immune to key escrowing. Yes, by escrowing J, you can get j. But this is *not* effective against SKIP PFS. The reason for this is that 'j' is used as an authentication key. If the escrowing agent does not get x and/or y, which are ephemeral DH secret values, the escrowing agent can only find out who communicated with J, and can naturally impersonate J. This would work the same way with all other schemes too, if authenticated exchanges are foreseen. Friendly greetings, Germano by the way: In my opinion escrowing communicated data is nuts anyway, you want key escrow for long term archived data, where key owners (and their secrets) may 'get lost'... From: Rich Skrenta <skrenta@osmosys.incog.com> Message-Id: <199608291706.KAA00973@miraj.incog.com> Subject: Re: Will the real PFS please stand up? To: Robert Moskowitz <rgm3@chrysler.com> Date: Thu, 29 Aug 1996 10:06:57 -0700 (PDT) Cc: sommerfeld@apollo.hp.com, balenson@TIS.COM, ipsec@TIS.COM 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-approval@neptune.tis.com Precedence: bulk > Does this mean that an escrowing of J can yield j? And thus escrowing is > effective against SKIP PFS? No, it means what Bill said -- that anonymity of the participants is not covered by the PFS. `J' above is the identity of one of the communicating parties; it doesn't make sense to talk about escrowing it. If we're talking about host-host communication, the identities of the two parties are known anyway. Hence this paragraph from the draft: "The encryption of each principal's certificate using g^xj is optional. It is used to provide anonymity of the parties involved in the ephemeral exchange. In case anonymity is not desired or necessary (e.g. node to node communications) the encryption using g^xj may be omitted." Date: Thu, 29 Aug 1996 13:03:36 -0500 From: David Wheeler-P26179 <David_Wheeler-P26179@email.mot.com> Message-Id: <MSMAIL PC */PRMD=MOT/ADMD=MOT/C=US/@MHS> Subject: Everything degenerates to Key Management To: ipsec@TIS.COM X400-Mts-Identifier: [ /P=MOT/A=MOT/C=US/ ; m\gstmd\960829130336b ] X-Mailer: Worldtalk (4.0.2-p15)/STREAM Sender: ipsec-approval@neptune.tis.com Precedence: bulk I've been listening/reading the group's discussions for some time.It is clear that IPSEC, we, must produce and field a viable solution within the next year or be overcome by events. This truth, while brutal, I think can be confirmed independently by all of us. Every discussion seems to degenerate into the fixed camps of key management proponents, and it seems nearly impossible to unify until this issue is well put to bed. I agree heartily with Mr. Harald Koch: >The people working on other protocols requiring security (TLS, L2TP, LDAP, >and probably others) have all been overheard saying the same thing: > > Wouldn't it be nice to have a single key negotiation protocol for > IPsec *and* for our protocols? > >So, Before we run around in a frenzy removing 'user oriented keying', we >should remember that AH/ESP are no longer the only customers of an IPSEC WG >key management protocol. Though my preference would be an ISAKMP/OAKLEY key management solution for IPSEC, I understand Phil's concern at how far we have gone from the original goals. >I couldn't agree more. As one of the originators of the IPSEC group, I >have watched with increasing resignation for the last four years as my >original idea has grown completely out of control, with very little to >show for it. >... >how can my laptop get back through my company's >firewall in a safe and secure fashion? >... >If the IPSEC group's work is to ever have any relevance, it must >return to the original, bare-bones goal of building protected >"tunnels" at the host-to-host or subnet-to-subnet level of >granularity. There's still plenty of need for this function, but >trying to do more than this is likely to continue to get us nowhere. > >In this light, SKIP keeps looking better to me all the time. Its claim >to the "simple" label certainly keeps getting stronger. I do however feel strongly that we have a responsibility to position the Internet protocols for future capability. Ignoring the need that is well voiced for a common, flexible, and extensible key managment protocol would border on deliquency. As Germano Caronni requested, I would like to reiterate, that it would be helpful to review the TECHNICAL reasons for failure of unifying the key management approaches. >To my deep sorrow, Hilarie Orman has announced the failure of the design >group that was supposed to come up with a unified key management approach. >It might be very interesting for the group as a whole to understand why this >occurred. Could perhaps some of the group members elaborate on their >respective views to what technical differences were not acquiescable? It would be helpful if this exchange were HIGHLY moderated - much like a debate. However, written form - through the mail list - would be a much better forum than a meeting. I propose that key designers/proponents of the key management protocols collaberate and present a SHORT position paper on the primary aspects/ features of their respective protocols that cannot be unified with other approaches; a single submittal for each protocol may be forwarded to Ran or Paul who will then post to the group. A SINGLE, UNIFIED rebuttal from each party be allowed to be posted following the first submittal, again through one of the chairs. This process will allow us the read a clearly presented position from the major contributors WITHOUT a lot of bantering clogging up the exchange. Folks, we need a unfied approach, or we will continue to bicker until someone else produces a workable compromise and we will all end up looking like fools -- many other groups/companies are doing this. If we can't get there, and come to a professional concenus, then maybe Phil is right -- we'll need to rope in our goals. Dave Wheeler Motorola, SSTG Scottsdale, Az "What's the difference between a wise man and a fool arguing in the street? A stranger can't tell the difference between the wise man and the fool." Received: from relay.hq.tis.com by neptune.TIS.COM id aa09482; 29 Aug 96 21:31 EDT Received: by relay.hq.tis.com; id VAA02406; Thu, 29 Aug 1996 21:34:57 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma002404; Thu, 29 Aug 96 21:34:28 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA23335; Thu, 29 Aug 96 21:33:47 EDT Received: by relay.hq.tis.com; id VAA02399; Thu, 29 Aug 1996 21:34:27 -0400 Received: from inet-user-gw-1.us.oracle.com(192.86.155.82) by relay.tis.com via smap (V3.1.1) id xma002392; Thu, 29 Aug 96 21:34:00 -0400 Received: from maildig1.us.oracle.com by inet-user-gw-1.us.oracle.com with SMTP (8.6.12/37.7) id SAA03125; Thu, 29 Aug 1996 18:33:03 -0700 Received: by maildig1.us.oracle.com (5.65v3.2/37.8) id AA13364; Thu, 29 Aug 1996 17:59:09 -0700 Message-Id: <9608300059.AA13364@maildig1.us.oracle.com> Date: 29 Aug 96 17:57:32 -0700 From: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com> To: ipsec@TIS.COM Subject: Re: Will the real PFS please stand up? X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-request@neptune.hq.tis.com's message of 29-Aug-96 07:08 Mime-Version: 1.0 X-Mailer: Oracle InterOffice (version 2.1.16.0.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Hi Germano, >Friendly greetings, > Germano > >by the way: >In my opinion escrowing communicated data is nuts anyway, >you want key escrow for long term archived data, where >key owners (and their secrets) may 'get lost'... I agree, but would like to add that ... "Key archiving" makes sense for long term archived data and sometimes for private signature or encryption keys. This allows access to data when keys are misplaced, or restoration of capabilities when a user forgets or losses his key. "Law enforcement escrow" makes sense to agencies that wish to covertly monitor data being communicated in real time. Law enforcement access to stored data may be provided by mechanisms that could be described as key archiving or law enforcement escrow. The IPsec efforts are concerned primarily with the "real-time" protection of IP datagrams so there should be no confusion within this committee between the categories of key recovery. To date, no requirements have been put forward within the IPsec working group for support of key archiving or law enforcement key escrow. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 633-2963 Redwood Shores, CA 94065 E-Mail: palamber@us.oracle.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ for a secure time -> send resumes to: palamber@us.oracle.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Received: from relay.hq.tis.com by neptune.TIS.COM id aa12711; 30 Aug 96 0:47 EDT Received: by relay.hq.tis.com; id AAA04525; Fri, 30 Aug 1996 00:50:51 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma004523; Fri, 30 Aug 96 00:50:28 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA27162; Fri, 30 Aug 96 00:49:42 EDT Received: by relay.hq.tis.com; id AAA04520; Fri, 30 Aug 1996 00:50:21 -0400 Received: from melcogw.melit.melco.co.jp(192.218.140.35) by relay.tis.com via smap (V3.1.1) id xma004518; Fri, 30 Aug 96 00:50:14 -0400 Received: by melcogw.melit.melco.co.jp (5.65+1.6W/2.7W) id AA25341; Fri, 30 Aug 96 13:52:31 JST Received: from katase by inetgw.topo.melco.co.jp (1.38.193.5/6.4J.6-inetgw1.0) id AA22759; Fri, 30 Aug 1996 13:55:39 +0900 Received: from kousoku.kousoku.isl.melco.co.jp by katase.katase.isl.melco.co.jp (4.1/6.4J.6-katase-2/) id AA17208; Fri, 30 Aug 96 13:52:19 JST Received: from l2seno by kousoku.kousoku.isl.melco.co.jp (1.38.193.4/6.4J.6-isl2-2/kousoku-master) id AA17396; Fri, 30 Aug 1996 13:54:31 +0900 Message-Id: <9608300454.AA17396@kousoku.kousoku.isl.melco.co.jp> Date: Fri, 30 Aug 1996 13:55:56 +0900 To: ipsec@TIS.COM From: Shoichiro Seno <senos@kousoku.isl.melco.co.jp> Subject: Any News on UUNET encryption patents? Cc: watakira@kousoku.isl.melco.co.jp, Shoichiro Seno <senos@kousoku.isl.melco.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp X-Mailer: Eudora-J(1.3.8.5-J13) Sender: ipsec-approval@neptune.tis.com Precedence: bulk Hello, A few months ago, the validity of the following patents by UUNET was discussed on this mailing list. Would you let me know recent recent news on these patents, e.g, if someone challenged the patents? >5,442,708 - Computer Network Encryption/Decryption Device >Inventors: Richard L. Adams, Jr., Fairfax, Va.; > Peter D. Hallenbeck, Elfland, N.C. >Assignee: UUNET Techologies, Inc., Falls Church, Va. >Appl. No: 305,509 >Filed: Sep. 13, 1994 >Related U.S. Application Data: > Continuation of Ser. No. 28,437, Mar. 9, 1993, abandoned. >5,444,782 - Computer Network Encryption/Decryption Device >Inventors: Richard L. Adams, Jr., Fairfax, Va.; > Peter D. Hallenbeck, Elfland, N.C. >Assignee: UUNET Techologies, Inc., Falls Church, Va. >Appl. No: 184,631 >Filed: Jan. 19, 1994 >Related U.S. Application Data: > Continuation of Ser. No. 28,437, Mar. 9, 1993, abandoned. -- Shoichiro Seno, (E-mail) senos@kousoku.isl.melco.co.jp High-Speed Network Department, Information Technology R&D Center Mitsubishi Electric Corporation (Tel) +81-467-41-2434, (Fax) +81-467-41-2419 Date: Thu, 29 Aug 1996 19:24:27 -0400 From: "Mitchell C. Nelson" <nelson@mcn.netsec.com> Message-Id: <199608292324.TAA00290@mcn.netsec.com> To: ipsec@TIS.COM, karn@qualcomm.netsec.com, rgm3@chrysler.com Subject: "user" and "network layer" security. Cc: nelson@mcn.netsec.com Sender: ipsec-approval@neptune.tis.com Precedence: bulk Re Robert Moskowitz's "inter" and "intra" business model, I think that this is again a bit of a red-herring. At the network layer there is not to much distinction. The entities that are sensitive to this are very much at the application layer. Hence the *whole* construct of distinquishing between inter and intra really belongs in an application layer security model. The construct could perhaps have some small consequence with respect to routing. But even so, such a consequence would probably only come into a network layer security model as a second order contribution. (Parenthetically recall that some c.f. Tannenbaum, feel that IP routing already has a somewhat confused architecture). Re the suggestion to immediately adapt SKIP, I feel that it is important to first clearly state the objectives of network layer security, and then discuss proposals in those terms. If it is agreed that SKIP is at least more or less in the right direction, then very good. After that, I suspect there are some questions of a mathematical-cryptographical nature that should be discussed. I'm hesitant to bring out my own questions in this category at this moment, because I feel that at this moment it would be a digression. The first thing is to clearly state an appropriate set of objectives. Regards, Mitch Nelson netsec@panix.com To: Bill Sommerfeld <sommerfeld@apollo.hp.com> Cc: ipsec@TIS.COM, gnu@toad.com Subject: PFS, key escrow, and legality In-Reply-To: <199608291500.LAA00829@thunk.orchard.medford.ma.us> Date: Thu, 29 Aug 1996 17:08:10 -0700 From: John Gilmore <gnu@toad.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9608300802.aa20484@neptune.TIS.COM> > I'm not sure these assumptions about key escrow policy are realistic; > in any situation where key escrow is mandated, skip-pfs, photuris, and > OAKLEY will all be illegal as specified. Bill, there are numerous situations in which key escrow of some sort might occur, without making the development, deployment, or use of secure protocols such as Photuris illegal. Kindly don't hand the government what it wants (our capitulation) before we are forced at gunpoint to surrender our privacy. For example, see the Administration's Clipper-3 policy (announced only in July; see http://www.crypto.com/#clipper3). It proposes that users' long-term private keys must be generated by, or stored in, an escrow agency, before a certification authority would publish the corresponding public key. It would allow the use of any algorithm or protocol, even in exportable products. It states "There are no federal laws regulating the use of cryptographic products within the United States.", and continues the Clinton Administration policy of having no plans or proposals to control the domestic use of encryption. It will be a very hard job to ram legislation through Congress that makes everything that you and I are working on illegal. Everyone who owned a copy of PGP or Kerberos would be a felon, including numerous government officials, agencies, and corporations at all levels. Congressional interest in encryption issues is continuing to rise, and it's clear to all interested parties (inside and outside Congress) that nobody supports Government Access to Keys (GAK) except for government officials, people they are paying, and a very small number of public policy activists (Dorothy Denning is the only one I can think of). Making domestic crypto illegal in Congress is a very long shot -- and even if they succeed, EFF is building a legal team that would fight it, the same way we are fighting and winning Constitutional battles against the CDA legislation and the export control legislation. It is far more likely that we'll have to deal with non-legislative programs, or legislation that does not outlaw the domestic use of strong crypto. For example, the government could try to strong-arm or purchase VeriSign, RSA, and other certification authorities to "voluntarily" require GAK, the way they strong-armed AT&T to offer the original Clipper phone. They are currently working to convince governments of naive or unfree countries to mandate the use of GAK, which would mean that vendors who wanted to sell products in those countries would have to supply GAK even if it wasn't required for US use. They could require government contractors to use GAK, etc. Partial GAK, without making strong crypto illegal, doesn't accomplish their aims, though. Using a properly designed protocol with PFS, even escrowing all the long-term keys does not permit them to break the traffic, because the long-term keys are only used for authentication, never for encryption. Encryption is done with an ephemeral key generated by Diffie-Hellman. Even if the government has your long-term private key, has tapped your phone line, and is doing an active attack on your Diffie-Hellman protocol, you will detect the attack and avoid communication -- unless they also have real-time access to the escrowed private keys of EVERYONE YOU COMMUNICATE WITH. Think about that. Giving the government real-time (30 seconds or less) access to every single escrowed private key, without a warrant, based on the flimsy assertion that "someone who we *do* have a warrant for is currently trying to communicate with that person", is something that the public is very unlikely to stand for. It would basically mean that all administrative controls over the key-escrow database would be thrown in the trash. Any law enforcement agency would be able to get anyone's key at any time. Even if machinery enforced the rules, and would only give them keys for parties that a legally wiretapped suspect attempted communication with, they could inject bogus-return-address packets that would cause the wiretapped machine to attempt to communicate with any site whose key they wanted to look up. For example, they could pretend to be opening an SMTP connection, doing a DNS lookup, or starting an IPSEC key exchange from that site. They or an accomplice could do that from anywhere on the net, without even mounting an active attack. So, let's not constrain the debate or our protocols by premature ideas on "what would be legal or illegal". As requested by the IAB and the IESG, let's design protocols that are as strong as we can make them, against every kind of attack we can envision. Including attacks by our own governments on our civil rights. John Gilmore PS: As you might guess, I strongly support keeping the identities of the communicating parties private in the key negotiation protocol, as well as continuing to require PFS for the end-user data. It should be possible with firewall-to-firewall keying and encryption to never reveal the end-system identities, which would be a big help in defeating traffic analysis against large sites such as universities or corporations. Date: Thu, 29 Aug 1996 20:13:05 -0400 From: "Mitchell C. Nelson" <nelson@mcn.netsec.com> Message-Id: <199608300013.UAA00353@mcn.netsec.com> To: ipsec@TIS.COM, PALAMBER@us.oracle.com Subject: "user" and "network layer" security. reply to respondents. Cc: netsec@panix.com Sender: ipsec-approval@neptune.tis.com Precedence: bulk Paul, I think you need to think through your scenario a little more carefully. You'll probably see that your argument doesn't fly. The present IPSEC does in fact, break the network architecture. (But, thank you for a challenging effort.) Regads, Mitch Nelson netsec@panix.com reference - palamber's comment: > IPsec does not break the "Internet Architecture". The use of the term > "user" with IPsec security associations is confusing, but not > inappropriate for some scenarios. Key management is an application > layer activity where the security associations are created and provide > authentication to peer application layer entities. The security > association is then available to be used by ESP, AH or perhaps other > security mechanisms. The authentication provided by applicaitons can > be at the granularity of a "user". The use of the resulting > authenticaiton process can be enforced at the network layer using ESP > or AH. p.s. The experience that you cited is not comparable to what is being proposed here. We are dealing with a very different environment, context, and scale. reference - palamber's comment: > There is significant experience fielding network layer security by > various governments and defense contractors. There is also significant > experience by many commercial vendors ... To: ipsec@TIS.COM Subject: Announcing DNS Security in production BIND code Date: Thu, 29 Aug 1996 19:11:34 -0700 From: John Gilmore <gnu@toad.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9608300806.aa20532@neptune.TIS.COM> Paul Vixie has released a test version of BIND which contains some DNS Security features. The release is available now at ftp://ftp.vix.com/pub/bind/testing/bind-4.9.5-T3B.tar.gz. Only the existence of KEY and SIG records is implemented in this BIND. There is no cryptography implemented; the signatures are never checked. This permits keys and signatures to be stored and retrieved in a completely exportable version of BIND, which is part of the main production BIND evolution. The released code is partly based on IBM changes for Dynamic DNS, and is partly original with me. It was not based on TIS's version because of their export control concerns and restrictive copyrights (which have since been almost resolved). The State Department has approved TIS's request to export their cryptographic version of BIND. TIS is now waiting for final Commerce Dept. approval. When they receive it, I will work with them and Paul to merge their version into the production BIND sources, and to add further cryptographic code to the resolver, to provide production-quality, worldwide, end-to-end cryptovalidation of DNS resource records. In the meantime, TIS's release (ftp://ftp.tis.com/pub/DNSSEC/README) is useful in the US for experimentation, and for generating offline KEY and SIG records (which can then be published with the just-released production BIND server). I encourage all organizations who are interested in Secure DNS to upgrade their organization's production copy of BIND to Paul's latest release. This will facilitate Secure DNS testing and deployment. I have started a mailing list <dnssec-interest@toad.com> for people who are interested in deploying Secure DNS in production use. There is also <dnssec-nics@toad.com> for top-level domain service providers to work out their issues with Secure DNS. Send me email at postmaster@toad.com if you'd like to join either list. This is the first software release from my S/WAN (Secure Wide Area Network) project, whose ultimate goal is to provide transparent improvements to the privacy and security of all Internet communications. See http://www.cygnus.com/~gnu/swan.html. Thank you for supporting the ongoing securing of the Internet infrastructure. John Gilmore To: ipsec@TIS.COM Subject: Patents by Sun? Date: Thu, 29 Aug 1996 17:32:20 -0400 From: "Perry E. Metzger" <perry@piermont.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9608300807.aa20583@neptune.TIS.COM> Someone forwarded this to me. I don't know if its real. I must admit I haven't yet tracked this down to confirm it (it might be a hoax) but it appears by the looks of it that Ashar has patented IPSEC. Again, I have to track down an independent copy to confirm it. If the claims listed are genuine, they are all on their face invalidated by prior art, but... Perry ------- Forwarded Message System for signatureless transmission and reception of data packets between computer networks (Assignee -- Sun Microsystems, Inc.) Abstract: A system for automatically encrypting and decrypting data packet sent from a source host to a destination host across a public internetwork. A tunnelling bridge is positioned at each network, and intercepts all packets transmitted to or from its associated network. The tunnelling bridge includes tables indicated pairs of hosts or pairs of networks between which packets should be encrypted. When a packet is transmitted from a first host, the tunnelling bridge of that host's network intercepts the packet, and determines from its header information whether packets from that host that are directed to the specified destination host should be encrypted; or, alternatively, whether packets from the source host's network that are directed to the destination host's network should be encrypted. If so, the packet is encrypted, and transmitted to the destination network along with an encapsulation header indicating source and destination information: either source and destination host addresses, or the broadcast addresses of the source and destination networks (in the latter case, concealing by encryption the hosts' respective addresses). An identifier of the source network's tunnelling bridge may also be included in the encapsulation header. At the destination network, the associated tunnelling bridge intercepts the packet, inspects the encapsulation header, from an internal table determines whether the packet was encrypted, and from either the source (host or network) address or the tunnelling bridge identifier determines whether and how the packet was encrypted. If the packet was encrypted, it is now decrypted using a key stored in the destination tunnelling bridge's memory, and is sent on to the destination host. The tunnelling bridge identifier is used particularly in an embodiment where a given network has more than one tunnelling bridge, and hence multiple possible encryption/decryption schemes and keys. In an alternative embodiment, the automatic encryption and decryption may be carried out by the source and destination hosts themselves, without the use of additional tunnelling bridges, in which case the encapsulation header includes the source and destination host addresses. Ex Claim Text: A method for transmitting and receiving packets of data via an internetwork from a first host computer on a first computer network to a second host computer on a second computer network, the first and second computer networks including, respectively, first and second bridge computers, each of said first and second host computers and first and second bridge computers including a processor and a memory for storing instructions for execution by the processor, each of said first and second bridge computers further including memory storing at least one predetermined encryption/ decryption mechanism and information identifying a predetermined plurality of host computers as hosts requiring security for packets transmitted between them, the method being carded out by means of the instructions stored in said respective memories and including the steps of: (1) generating, by the first host computer, a first data packet for transmission to the second host computer, a portion of the data packet including information representing an internetwork address of the first host computer and an internetwork address of the second host computer; (2) in the first bridge computer, intercepting the first data packet and determining whether the first and second host computers are among the predetermined plurality of host computers for which security is required, and if not, proceeding to step 5, and if so, proceeding to step 3; (3) encrypting the first data packet in the first bridge computer; (4) in the first bridge computer, generating and appending (4) in the first bridge computer, generating and appending to the first data packet an enapsulation header, including: (a) key management information identifying the predetermined encryption method, and (b) a new address header representing the source and destination for the data packet, thereby generating a modified data packet; (5) transmitting the data packet from the first bridge computer via the internetwork to the second computer network; (6) intercepting the data packet at the second bridge computer; (7) in the second bridge computer, reading the encapsulation header, and determining therefrom whether the data packet was encrypted, and if not, proceeding to step 10, and if so, proceeding to step 8; (8) in the second bridge computer, determining which encryption mechanism was used to encrypt the first data packet; (9) decrypting the first data packet by the second bridge computer; (10) transmitting the first data packet from the second bridge computer to the second host computer; and (11) receiving the unencrypted data packet at the second host computer. Assignee: Sun Microsystems, Inc. Patent Number: 5548646 Issue Date: 1996 08 20 Inventor(s): Aziz, Ashar; Mulligan, Geoffrey; Patterson, Martin; Scott, Glenn. State/Country CA ------- End of Forwarded Message Received: from relay.hq.tis.com by neptune.TIS.COM id aa21488; 30 Aug 96 8:45 EDT Received: by relay.hq.tis.com; id IAA09556; Fri, 30 Aug 1996 08:48:35 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma009525; Fri, 30 Aug 96 08:48:07 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA07131; Fri, 30 Aug 96 08:47:24 EDT Received: by relay.hq.tis.com; id IAA09519; Fri, 30 Aug 1996 08:48:04 -0400 Received: from capone.ch.apollo.hp.com(15.254.24.3) by relay.tis.com via smap (V3.1.1) id xma009499; Fri, 30 Aug 96 08:47:51 -0400 Received: from thunk.orchard.medford.ma.us (orchard.ch.apollo.hp.com) by capone.ch.apollo.hp.com id <AA140069402@capone.ch.apollo.hp.com>; Fri, 30 Aug 1996 08:50:02 -0400 Received: from thunk (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.6.12/8.6.12) with ESMTP id PAA00215; Thu, 29 Aug 1996 15:15:14 -0400 Message-Id: <199608291915.PAA00215@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: nelson@mcn.netsec.com, PALAMBER@us.oracle.com Cc: ipsec@TIS.COM Subject: Re: "user" and "network layer" security. reply to respondents. In-Reply-To: PALAMBER's message of 28 Aug 1996 16:46:18 -0700. <199608282351.QAA28966@mailsun2.us.oracle.com> Date: Thu, 29 Aug 1996 15:15:13 -0400 From: Bill Sommerfeld <sommerfeld@apollo.hp.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk Another way of looking at ipsec is that the transforms are really a layer *in between* network and transport. You're not so much adding a "user" concept at the network layer as adding a new layer next to the transport layer, which already has a concept of "user". - Bill Received: from relay.hq.tis.com by neptune.TIS.COM id aa22783; 30 Aug 96 9:56 EDT Received: by relay.hq.tis.com; id JAA11235; Fri, 30 Aug 1996 09:59:35 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma011228; Fri, 30 Aug 96 09:59:06 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA11044; Fri, 30 Aug 96 09:58:24 EDT Received: by relay.hq.tis.com; id JAA11222; Fri, 30 Aug 1996 09:59:04 -0400 Received: from panix.com(198.7.0.2) by relay.tis.com via smap (V3.1.1) id xma011218; Fri, 30 Aug 96 09:58:51 -0400 Received: (from netsec@localhost) by panix.com (8.7.5/8.7/PanixU1.3) id JAA28291; Fri, 30 Aug 1996 09:59:50 -0400 (EDT) Date: Fri, 30 Aug 1996 09:59:49 -0400 (EDT) From: "M.C.Nelson" <netsec@panix.com> To: Bill Sommerfeld <sommerfeld@apollo.hp.com> Cc: nelson@mcn.netsec.com, PALAMBER@us.oracle.com, ipsec@TIS.COM Subject: Re: "user" and "network layer" security. reply to respondents. In-Reply-To: <199608291915.PAA00215@thunk.orchard.medford.ma.us> Message-Id: <Pine.SUN.3.91.960830095654.26224C-100000@panix.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk Bill, The transport layer doesn't have "user" either. Adding a "user" concept in a new layer between the transport and network layer still breaks the network architecture. Regards, Mitch Nelson netsec@panix.com On Thu, 29 Aug 1996, Bill Sommerfeld wrote: > Another way of looking at ipsec is that the transforms are really a > layer *in between* network and transport. > > You're not so much adding a "user" concept at the network layer as > adding a new layer next to the transport layer, which already has a > concept of "user". > > - Bill > Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM Cc: ipsec@TIS.COM From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ah-hmac-md5-02.txt Date: Fri, 30 Aug 1996 09:41:20 -0400 Message-Id: <9608300941.aa18298@ietf.org> Sender: ipsec-approval@neptune.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : HMAC-MD5 IP Authentication with Replay Prevention Author(s) : M. Oehler, R. Glenn Filename : draft-ietf-ipsec-ah-hmac-md5-02.txt Pages : 7 Date : 08/29/1996 This document describes a keyed-MD5 transform to be used in conjunction with the IP Authentication Header [RFC-1826]. The particular transform is based on [HMAC-MD5]. An option is also specified to guard against replay attacks. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ah-hmac-md5-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ah-hmac-md5-02.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 (193.205.245.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-ietf-ipsec-ah-hmac-md5-02.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@ietf.org 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: <19960829163925.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-md5-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ah-hmac-md5-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960829163925.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from relay.hq.tis.com by neptune.TIS.COM id aa24083; 30 Aug 96 11:22 EDT Received: by relay.hq.tis.com; id LAA15241; Fri, 30 Aug 1996 11:25:11 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma015228; Fri, 30 Aug 96 11:24:51 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA17783; Fri, 30 Aug 96 11:24:04 EDT Received: by relay.hq.tis.com; id LAA15220; Fri, 30 Aug 1996 11:24:42 -0400 Received: from broadway.interport.net(199.184.165.4) by relay.tis.com via smap (V3.1.1) id xma015204; Fri, 30 Aug 96 11:24:22 -0400 Received: from massey (massey.ftp.com [128.127.128.152]) by broadway.interport.net (8.7.3/8.7.3) with SMTP id LAA17411; Fri, 30 Aug 1996 11:26:33 -0400 (EDT) Message-Id: <199608301526.LAA17411@broadway.interport.net> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 30 Aug 1996 11:26:28 -0400 To: "Perry E. Metzger" <perry@piermont.com> From: Rodney Thayer <rodney@sabletech.com> Subject: Re: Patents by Sun? Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk I believe that if you're willing to dig, you can go to the Patent Office web site at www.uspto.gov and look it up by number. At 05:32 PM 8/29/96 -0400, you wrote: > >Someone forwarded this to me. I don't know if its real. > >I must admit I haven't yet tracked this down to confirm it (it might >be a hoax) but it appears by the looks of it that Ashar has patented >IPSEC. Again, I have to track down an independent copy to confirm >it. If the claims listed are genuine, they are all on their face >invalidated by prior art, but... > >Perry > >------- Forwarded Message > > System for signatureless transmission and reception of > data packets between computer networks (Assignee -- Sun > Microsystems, Inc.) > > > Abstract: A system for automatically encrypting and > decrypting data packet sent from a source host to a > destination host across a public internetwork. > > A tunnelling bridge is positioned at each network, and > intercepts all packets transmitted to or from its > associated network. > > The tunnelling bridge includes tables indicated pairs of > hosts or pairs of networks between which packets should > be encrypted. > > When a packet is transmitted from a first host, the > tunnelling bridge of that host's network intercepts the > packet, and determines from its header information > whether packets from that host that are directed to the > specified destination host should be encrypted; or, > alternatively, whether packets from the source host's > network that are directed to the destination host's > network should be encrypted. > > If so, the packet is encrypted, and transmitted to the > destination network along with an encapsulation header > indicating source and destination information: either > source and destination host addresses, or the broadcast > addresses of the source and destination networks (in the > latter case, concealing by encryption the hosts' > respective addresses). > > An identifier of the source network's tunnelling bridge > may also be included in the encapsulation header. At the > destination network, the associated tunnelling bridge > intercepts the packet, inspects the encapsulation header, > from an internal table determines whether the packet was > encrypted, and from either the source (host or network) > address or the tunnelling bridge identifier determines > whether and how the packet was encrypted. > > If the packet was encrypted, it is now decrypted using a > key stored in the destination tunnelling bridge's memory, > and is sent on to the destination host. > > The tunnelling bridge identifier is used particularly in > an embodiment where a given network has more than one > tunnelling bridge, and hence multiple possible > encryption/decryption schemes and keys. > > In an alternative embodiment, the automatic encryption > and decryption may be carried out by the source and > destination hosts themselves, without the use of > additional tunnelling bridges, in which case the > encapsulation header includes the source and destination > host addresses. > > > Ex Claim Text: A method for transmitting and receiving > packets of data via an internetwork from a first host > computer on a first computer network to a second host > computer on a second computer network, the first and > second computer networks including, respectively, first > and second bridge computers, each of said first and > second host computers and first and second bridge > computers including a processor and a memory for storing > instructions for execution by the processor, each of said > first and second bridge computers further including > memory storing at least one predetermined encryption/ > decryption mechanism and information identifying a > predetermined plurality of host computers as hosts > requiring security for packets transmitted between them, > the method being carded out by means of the instructions > stored in said respective memories and including the > steps of: > > (1) generating, by the first host computer, a first data > packet for transmission to the second host computer, a > portion of the data packet including information > representing an internetwork address of the first host > computer and an internetwork address of the second host > computer; > > (2) in the first bridge computer, intercepting the first > data packet and determining whether the first and second > host computers are among the predetermined plurality of > host computers for which security is required, and if > not, proceeding to step 5, and if so, proceeding to step > 3; > > (3) encrypting the first data packet in the first bridge > computer; > > (4) in the first bridge computer, generating and > appending (4) in the first bridge computer, generating > and appending to the first data packet an enapsulation > header, including: > > (a) key management information identifying the > predetermined encryption method, and > > (b) a new address header representing the source and > destination for the data packet, thereby generating a > modified data packet; > > (5) transmitting the data packet from the first bridge > computer via the internetwork to the second computer > network; > > (6) intercepting the data packet at the second bridge > computer; > > (7) in the second bridge computer, reading the > encapsulation header, and determining therefrom whether > the data packet was encrypted, and if not, proceeding to > step 10, and if so, proceeding to step 8; > > (8) in the second bridge computer, determining which > encryption mechanism was used to encrypt the first data > packet; > > (9) decrypting the first data packet by the second bridge > computer; > > (10) transmitting the first data packet from the second > bridge computer to the second host computer; and > > (11) receiving the unencrypted data packet at the second > host computer. > > Assignee: Sun Microsystems, Inc. > > Patent Number: 5548646 > > Issue Date: 1996 08 20 > > Inventor(s): Aziz, Ashar; Mulligan, Geoffrey; Patterson, > Martin; Scott, Glenn. State/Country CA > > >------- End of Forwarded Message > > > > > Rodney Thayer <rodney@sabletech.com> +1 617 332 7292 Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA Fax: +1 617 332 7970 http://www.shore.net/~sable "Developers of communications software" Received: from relay.hq.tis.com by neptune.TIS.COM id aa24190; 30 Aug 96 11:30 EDT Received: by relay.hq.tis.com; id LAA15790; Fri, 30 Aug 1996 11:33:59 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma015772; Fri, 30 Aug 96 11:33:29 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA18290; Fri, 30 Aug 96 11:32:46 EDT Received: by relay.hq.tis.com; id LAA15764; Fri, 30 Aug 1996 11:33:25 -0400 Received: from www.borderware.com(199.71.190.98) by relay.tis.com via smap (V3.1.1) id xma015742; Fri, 30 Aug 96 11:33:19 -0400 Received: by janus.border.com id <18461-1>; Fri, 30 Aug 1996 11:31:28 -0400 Message-Id: <96Aug30.113128edt.18461-1@janus.border.com> To: "M.C.Nelson" <netsec@panix.com> Cc: ipsec@TIS.COM Subject: Re: "user" and "network layer" security. reply to respondents. References: <Pine.SUN.3.91.960830095654.26224C-100000@panix.com> In-Reply-To: netsec's message of "Fri, 30 Aug 1996 09:59:49 -0400". <Pine.SUN.3.91.960830095654.26224C-100000@panix.com> From: "C. Harald Koch" <chk@border.com> Date: Fri, 30 Aug 1996 11:30:27 -0400 Sender: ipsec-approval@neptune.tis.com Precedence: bulk In message <Pine.SUN.3.91.960830095654.26224C-100000@panix.com>, "M.C.Nelson" writes: > > The transport layer doesn't have "user" either. Adding a "user" concept > in a new layer between the transport and network layer still breaks the > network architecture. Fine. I guess we should all throw our hands up in disgust and walk away from the table. The pristine purity of the ISO reference model must be preserved at all cost, right? Do you propose removing all user-based authentication from PPP (CHAP and PAP) also? After all, PPP is a link layer protocol, and the link layer doesn't have a "user" either. How about SSL, at the transport layer? User-oriented keying is useful, and works. The concept is orthogonal to network stack layering. If it voliates some holy "architecture design principles", then those principles should be changed. IMHO, of course. -- Harald Koch chk@border.com Message-Id: <199608301559.LAA04638@jekyll.piermont.com> To: "Mitchell C. Nelson" <nelson@mcn.netsec.com> Cc: ipsec@TIS.COM Subject: Re: "user" and "network layer" security. reply to respondents. In-Reply-To: Your message of "Thu, 29 Aug 1996 20:13:05 EDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 30 Aug 1996 11:59:20 -0400 From: "Perry E. Metzger" <perry@piermont.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk "Mitchell C. Nelson" writes: > Paul, I think you need to think through your scenario a little > more carefully. You'll probably see that your argument doesn't fly. > > The present IPSEC does in fact, break the network architecture. Given that there are real implementations of IPSEC for fairly standard operating systems like 4.4BSD, and that people are, today, successfully moving around IPSEC packets on the real live internet, I'm rather unsure as to why we should be paying attention to your continued claims that the whole thing can't possibly work. Perry Message-Id: <199608301606.MAA04664@jekyll.piermont.com> To: "M.C.Nelson" <netsec@panix.com> Cc: ipsec@TIS.COM Subject: Re: "user" and "network layer" security. reply to respondents. In-Reply-To: Your message of "Fri, 30 Aug 1996 09:59:49 EDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 30 Aug 1996 12:06:30 -0400 From: "Perry E. Metzger" <perry@piermont.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk "M.C.Nelson" writes: > The transport layer doesn't have "user" either. Gee, Mr. Nelson, so I suppose all those telnet sessions I've done over the years were just an illusion, eh? After all, since the transport layer has no notion of user, there is no way for the transport layer to direct data to a particular process, so Telnet can't possibly be implemented, not to mention SMTP. In fact, this mail message is an illusion. Perry Received: from relay.hq.tis.com by neptune.TIS.COM id aa25011; 30 Aug 96 12:18 EDT Received: by relay.hq.tis.com; id MAA17629; Fri, 30 Aug 1996 12:21:36 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma017604; Fri, 30 Aug 96 12:21:05 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA20800; Fri, 30 Aug 96 12:20:24 EDT Received: by relay.hq.tis.com; id MAA17599; Fri, 30 Aug 1996 12:21:04 -0400 Received: from netcom8.netcom.com(192.100.81.117) by relay.tis.com via smap (V3.1.1) id xma017578; Fri, 30 Aug 96 12:20:49 -0400 Received: from winp133 (ple-ca16-03.ix.netcom.com [204.31.114.195]) by netcom8.netcom.com (8.6.13/Netcom) id JAA03651; Fri, 30 Aug 1996 09:23:08 -0700 Message-Id: <2.2.32.19960830162309.00a233f4@netcom8.netcom.com> X-Sender: dpalma@netcom8.netcom.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 30 Aug 1996 09:23:09 -0700 To: ipsec@TIS.COM From: Derek Palma <dpalma@netcom.com> Subject: Re: OAKLEY/ISAKMP/SKIP design group Cc: dpalma@netcom.com Sender: ipsec-approval@neptune.tis.com Precedence: bulk Hello everyone, I would also like to express my disappointment (and my customers') regarding the outcome of the OAKLEY/ISAKMP/SKIP design group. My company, like many others, tries to provide its customers with with the best technologies in a timely manner. We have always looked to the IETF to provide working, interoperable, scalable, sound, and in many cases state-of-the-art solutions to networking problems. IETF working groups have consisted of the best minds in the industry working toward very explicit objectives. These groups have been able to avoid most of the red tape found in formal standards bodies in order to obtain quick practical objectives. I am sorry to see that key management, the mechanism required to make network layer security practical and useful, will not be available in a unified form backed with the group's consensus. There are some very good proposals and a significant number working implementations. It is truly a shame after so much effort of so many people. However my company must address the fact that network layer security can be quite useful and is required by its customers. My company must provide a solution. I hoped that it would be a draft based on a unified solution from this work group. Currently, we have based our implmentations on SKIP, which seems significatnly more mature than the others. But most importantly, it solves our customers' problems. This is all our customers care about! And as long as the technology achieves this, we are satisfied. So I think it is important to note that those who need network layer security with key management will have it. This work group may not endorse, like, or acknowledge it. But it will continue to exist and might even proliferate. If the working group cannot reach consensus, maybe it should let the market be the judge. The market will certainly do this anyway. Mutiple drafts on the standards track are better than none. And if one catches on, this working group and the IETF will still maintain significant influence over its design and use. Regards, Derek Palma --------------------------------------------------------------------- Derek Palma Email: dpalma@netcom.com Net Research, Inc. Direct:(510) 487-6439 32536 Monterey Way Main: (510) 487-6300 Union City, CA 94587 FAX: (510) 487-6072 Message-Id: <199608301718.NAA04790@jekyll.piermont.com> To: Rodney Thayer <rodney@sabletech.com> Cc: ipsec@TIS.COM Subject: Re: Patents by Sun? In-Reply-To: Your message of "Fri, 30 Aug 1996 11:26:28 EDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 30 Aug 1996 13:18:14 -0400 From: "Perry E. Metzger" <perry@piermont.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk Rodney Thayer writes: > I believe that if you're willing to dig, you can go to the Patent Office web > site at www.uspto.gov and look it up by number. Unfortunately, this one was only granted a few days ago so the data at uspto.gov isn't up yet if the patent is real. Perry Received: from relay.hq.tis.com by neptune.TIS.COM id aa28192; 30 Aug 96 15:24 EDT Received: by relay.hq.tis.com; id PAA24272; Fri, 30 Aug 1996 15:27:44 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma024266; Fri, 30 Aug 96 15:27:16 -0400 Received: from la.tis.com (scintillate.la.tis.com) by tis.com (4.1/SUN-5.64) id AA29626; Fri, 30 Aug 96 15:19:51 EDT Received: from relay.la.tis.com by la.tis.com (4.1/SUN-5.64) id AA29235; Fri, 30 Aug 96 12:21:35 PDT Received: by relay.la.tis.com; id MAA27776; Fri, 30 Aug 1996 12:16:56 -0700 Received: from maildeliver4.tiac.net(199.0.65.168) by relay.la.tis.com via smap (V3.1.1) id xma027774; Fri, 30 Aug 96 12:16:32 -0700 Received: from mailserver2.tiac.net (mailserver2.tiac.net [199.0.65.231]) by maildeliver4.tiac.net (8.6.12/8.7.4) with ESMTP id PAA03847; Fri, 30 Aug 1996 15:25:12 -0400 Received: from toonces (ksiegel.tiac.net [206.119.132.115]) by mailserver2.tiac.net (8.6.12/8.7.4) with SMTP id PAA17535; Fri, 30 Aug 1996 15:25:09 -0400 Message-Id: <2.2.32.19960830191858.006ba480@tiac.net> X-Sender: ksiegel@tiac.net X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 30 Aug 1996 15:18:58 -0400 To: Rodney Thayer <rodney@sabletech.com>, "Perry E. Metzger" <perry@piermont.com> From: Ken Siegel <ksiegel@switchblade.com> Subject: Re: Patents by Sun? Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk If it is true that it was granted it is not yet online. However, Ashar (and hence Sun) have been granted another patent (in 1995) that I found in the database. The returned abstract is listed below. Sorry if the formatting is bad but I cut and pasted from Netscape. This patent is certainly also relevant to IPSEC. ------------begin patent stuff---------------- United States Patent 5,416,842 Aziz May 16, 1995 Method and apparatus for key-management scheme for use with internet protocols at site firewalls Inventors: Aziz; Ashar (Fremont, CA). Assignee: Sun Microsystems, Inc. (Mountain View, CA). Appl. No.: 258,344 Filed: Jun. 10, 1994 Intl. Cl.: H04L 9/30; H04L 9/08; H04L 9/00 U.S. Cl.: 380/ 30; 380/ 4; 380/ 21; 380/ 23; 380/ 25; 380/ 49 Field of Search: 380/4, 21, 23, 25, 30, 46, 49, 50; 371/68.3 References Cited [Referenced By:] U.S. Patent Documents 4,916,704 Apr., 1990 Bruckert et al. 371/ 68.3 Other References Whitfield Diffie, "The First Ten Years of Public-Key Cryptography", (Proceedings of the IEEE, vol. 76, No. 5, May 1988). Paul Fahn, "Answers to Frequently Asked Questions About Today's Cryptography", (RSA Laboratories, 1992). "Part I: Message Encryption and Authentication Procedures", (Privacy Enhancement for Internet Electronic Mail, J. Linn (Network Working Group), Feb., 1993. "Part II: Certificate-Based Key Management", (Privacy Enhancement for Internet Electronic Mail, S. Kent (Network Working Group), Feb., 1993. "Part III: Algorithms, Modes, and Identifiers", (Privacy Enhancement for Internet Electronic Mail), D. Balenson (Network Working Group), Feb., 1993. "Part IV: Key Certification and Related Services" (Privacy Enhancement for Internet Electronic Mail), B. Kaliski (Network Working Group), Feb., 1993. Whitfield Diffie, Paul C. Van Oorschoot and Michael J. Wiener, "Authentication and Authenticated Key Exchanges" (Designs, Codes and Cryptography, 2-107-125 (1992), Kluwer Academic Publishers). "The MD5 Message-Digest Algorithm"; MIT Laboratory for Computer Science and RSA Data Security, Inc. (1992), R. Rivest (Network Working Group). RSA Data Security, Inc. Technology Bulletin, copy undated. Primary Examiner: Gregory; Bernarr E. Attorney, Agent or Firm: Irell & Manella Abstract The present invention includes a first data processing device (node I) coupled to a first private network and to a firewall server (FWA). Firewall server FWA is in turn coupled to a public network, such as the Internet. A second data processing device (node J) is coupled to a second private network which is coupled to the Internet through a firewall server (FWB). Node I provides a data packet including IP data and a destination address for the intended receiving node J to firewall FWA. Firewall FWA is provided with a secret value a, and a public value .varies.(^a) mod p. Similarly, firewall FWB is provided with a secret value b and a public value .varies.(^b) mod p. The firewall FWA obtains a Diffie-Hellman (DH) certificate for firewall FWB and determines the public value .varies.(^b) mod p from the DH certificate. Firewall FWA then computes the value of .varies.(^ab) mod p, and derives a key K(ab) from the value .varies.(^ab) mod p. A transient key K(p) is randomly generated and is used to encrypt the data packet to be transmitted by firewall FWA to firewall FWB. The encrypted data packet is then encapsulated in a transmission packet by the firewall FWA. The transmission packet includes an unencrypted destination address for the firewall FWB. Firewall FWA then sends the transmission packet to firewall FWB over the Internet. Upon receipt of the transmission packet from firewall FWA, firewall FWB obtains a DH certificate for firewall FWA, and determines the public value of .varies.(^a) mod p from the DH certificate. Firewall FWB computes the value of .varies.(^ab) mod p, and derives the key K(ab). Firewall B utilizes the key K(ab) to decrypt the transient key K(p), and using the decrypted transient key K(p), firewall FWB decrypts the encrypted data packet received from FWA, thereby resulting in the recovery of the original data sent by node I in unencrypted form to the firewall FWA. The firewall FWB then transmits the decrypted data packet to the receiving node J over the second private network. Ken Siegel Switchblade Networks, Inc. 6 Lisa Drive Nashua, NH 03062 Phone: (603) 891-1500 Internet: ksiegel@switchblade.com URL: www.switchblade.com Date: Fri, 30 Aug 1996 10:50:52 -0700 From: Glenn Scott <asdf@osmosys.incog.com> Message-Id: <199608301750.KAA22206@ono-sendai.incog.com> To: ipsec@TIS.COM Subject: Re: Patents by Sun? Sender: ipsec-approval@neptune.tis.com Precedence: bulk >I must admit I haven't yet tracked this down to confirm it (it might >be a hoax) but it appears by the looks of it that Ashar has patented >IPSEC. Again, I have to track down an independent copy to confirm >it. If the claims listed are genuine, they are all on their face >invalidated by prior art, but... I actually have a copy of the whole patent and since I'm one of the inventors I can at least state what we did: It's a way to use fake addressing to do some tunneling and topology hiding. This patent does not attempt to patent IPSEC. Having been through this stuff before I caution any reader to judge a patent's defensibility or what invalidates it by just its abstract. This list is starting to read a bit like alt.conspiracy. Glenn Message-Id: <3.0b11.32.19960830143943.00a3ad48@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0b11 (32) Date: Fri, 30 Aug 1996 15:16:24 -0400 To: Bill Sommerfeld <sommerfeld@apollo.hp.com> From: Robert Moskowitz <rgm3@chrysler.com> Subject: Re: Will the real PFS please stand up? Cc: "David M. Balenson" <balenson@TIS.COM>, ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 10:59 AM 8/29/96 -0400, Bill Sommerfeld wrote: > >> >Now, if I and J are just host identities, this isn't interesting >> >(because the same information is found in their IP addresses) but if >> >SKIP gets extended to do per-user keying I think we have a potential >> >problem. >> >> Huh? Please enlighten me. > >If the `name' in the certificate is just an IP address, then >compromise of the contents of Cert_I and Cert_J reveals no information >not already available to eavesdroppers, and skip-pfs's lack of PFS >protection on the exchanged certificates is moot. > >If the `name' in the certificate contains something other than an IP >address, or something more than an IP address, then skip-pfs's lack of >PFS protection on the exchanged certificates becomes interesting. AH HA! Ok, the certs that I see using will be either X.509 or SDSI. And yes, I will not want even this exposure. The cert will say that this is Bob Eaton currently over in Frankfurt. Whoa, no. >As above.. if principal names are always IP addresses, there's no >benefit in keeping them secret in the key mgt protocol because they're >sent in the clear in every packet.. I expect to have x.509 certs for this and they will not be IP addressed. Robert Moskowitz Chrysler Corporation (810) 758-8212 Message-Id: <3.0b11.32.19960830151026.009cc120@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0b11 (32) Date: Fri, 30 Aug 1996 15:16:29 -0400 To: David Wheeler-P26179 <David_Wheeler-P26179@email.mot.com>, ipsec@TIS.COM From: Robert Moskowitz <rgm3@chrysler.com> Subject: Re: Everything degenerates to Key Management Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 01:03 PM 8/29/96 -0500, David Wheeler-P26179 wrote: >I've been listening/reading the group's discussions for some time.It is >clear >that IPSEC, we, must produce and field a viable solution within the next >year >or be overcome by events. This truth, while brutal, I think can be >confirmed >independently by all of us. OK People. On Sept 19th, the AIAG's ANX security wg will have its 2nd meeting in Detroit. At this meeting we will be calling for interoperbility testing to deliver products YE96 - 1Q97. >I agree heartily with Mr. Harald Koch: >>The people working on other protocols requiring security (TLS, L2TP, LDAP, >>and probably others) have all been overheard saying the same thing: >> >> Wouldn't it be nice to have a single key negotiation protocol for >> IPsec *and* for our protocols? The AIAG's ANX EC messaging wg has been floating a secure EDI envelope on the SMIME-DEV list. Guess what, X.509 again but HTTP protocol, LDAP or SDSI? Gee we will want something commonized here. >>how can my laptop get back through my company's >>firewall in a safe and secure fashion? Back then this was a noble goal. In today's environment there are solutions you can buy to address this tactically. Yes the market overtook the group; probably learned a lot from the group too. Today's business world is my laptop connecting back to 3 company divisions and 2 trading partners at the same time. Robert Moskowitz Chrysler Corporation (810) 758-8212 Message-Id: <3.0b11.32.19960830145003.012bad40@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0b11 (32) Date: Fri, 30 Aug 1996 15:16:27 -0400 To: caronni@tik.ee.ethz.ch, Robert Moskowitz <rgm3@chrysler.com> From: Robert Moskowitz <rgm3@chrysler.com> Subject: Re: Will the real PFS please stand up? Cc: ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 04:08 PM 8/29/96 +0200, Germano Caronni wrote: > >by the way: >In my opinion escrowing communicated data is nuts anyway, you want key >escrow for long term archived data, where key owners (and their secrets) >may 'get lost'... Agreed. Actually on escrowing I am mind-game playing. Determine a methodology that meets business functional goals. show that it 'invalidates' key excrowing. Watch the fun start in the belt-way. sigh. BTW, I THINK that all of these are vulnerable to man-in-the-middle attacks where the private keys of both parties are know? I can see a business for sniffers that can work in this way. Robert Moskowitz Chrysler Corporation (810) 758-8212 Received: from relay.hq.tis.com by neptune.TIS.COM id aa29480; 30 Aug 96 16:38 EDT Received: by relay.hq.tis.com; id QAA26519; Fri, 30 Aug 1996 16:41:40 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma026497; Fri, 30 Aug 96 16:41:11 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA05461; Fri, 30 Aug 96 16:40:30 EDT Received: by relay.hq.tis.com; id QAA26494; Fri, 30 Aug 1996 16:41:10 -0400 Received: from panix.com(198.7.0.2) by relay.tis.com via smap (V3.1.1) id xma026481; Fri, 30 Aug 96 16:41:02 -0400 Received: (from netsec@localhost) by panix.com (8.7.5/8.7/PanixU1.3) id QAA22359; Fri, 30 Aug 1996 16:42:38 -0400 (EDT) Date: Fri, 30 Aug 1996 16:42:32 -0400 (EDT) From: "M.C.Nelson" <netsec@panix.com> To: "C. Harald Koch" <chk@border.com> Cc: ipsec@TIS.COM Subject: Re: "user" and "network layer" security. reply to respondents. In-Reply-To: <96Aug30.113128edt.18461-1@janus.border.com> Message-Id: <Pine.SUN.3.91.960830162437.19361A-100000@panix.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk It is not true that if we cannot have a user-keyed network layer mechanism we should throw our hands-up and leave the table. There is a place in the network architecture for user keyed security. But it is not in the lower layers. Obviously, it is also not true that user oriented keying is orthogonal to network stack layering (architecture). We should provide appropriate security services using appropriate mechanisms implemented in a manner consistent with existing architecture. If user security is needed, there is at least one right way to do it. Do it right - it will cost less, be easier to implement, and work better. Regards, Mitch Nelson netsec@panix.com On Fri, 30 Aug 1996, C. Harald Koch wrote: > In message <Pine.SUN.3.91.960830095654.26224C-100000@panix.com>, "M.C.Nelson" writes: > > > > The transport layer doesn't have "user" either. Adding a "user" concept > > in a new layer between the transport and network layer still breaks the > > network architecture. > > Fine. I guess we should all throw our hands up in disgust and walk away from > the table. The pristine purity of the ISO reference model must be preserved > at all cost, right? > > Do you propose removing all user-based authentication from PPP (CHAP and > PAP) also? After all, PPP is a link layer protocol, and the link layer > doesn't have a "user" either. How about SSL, at the transport layer? > > User-oriented keying is useful, and works. The concept is orthogonal to > network stack layering. If it voliates some holy "architecture design > principles", then those principles should be changed. > > IMHO, of course. > > -- > Harald Koch > chk@border.com > Message-Id: <199608302051.QAA12777@jekyll.piermont.com> To: Glenn Scott <asdf@osmosys.incog.com> Cc: ipsec@TIS.COM Subject: Re: Patents by Sun? In-Reply-To: Your message of "Fri, 30 Aug 1996 10:50:52 PDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 30 Aug 1996 16:51:40 -0400 From: "Perry E. Metzger" <perry@piermont.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk Glenn Scott writes: > >I must admit I haven't yet tracked this down to confirm it (it might > >be a hoax) but it appears by the looks of it that Ashar has patented > >IPSEC. Again, I have to track down an independent copy to confirm > >it. If the claims listed are genuine, they are all on their face > >invalidated by prior art, but... > > I actually have a copy of the whole patent and since I'm one of the > inventors I can at least state what we did: It's a way to use fake addressing > to do some tunneling and topology hiding. That isn't what the claims section I received (which I posted) says. > This patent does not attempt to patent IPSEC. Having been through this > stuff before I caution any reader to judge a patent's defensibility or what > invalidates it by just its abstract. The abstract isn't the important part. The claims are -- they are the portion which is legally actionable. Were the claims posted the actual ones, or was I sent an inaccurate set of claims? The claims there appear to cover *any* IPSEC style mechanism. This is the set that I have in my possession. + Ex Claim Text: A method for transmitting and receiving + packets of data via an internetwork from a first host + computer on a first computer network to a second host + computer on a second computer network, the first and + second computer networks including, respectively, first + and second bridge computers, each of said first and + second host computers and first and second bridge + computers including a processor and a memory for storing + instructions for execution by the processor, each of said + first and second bridge computers further including + memory storing at least one predetermined encryption/ + decryption mechanism and information identifying a + predetermined plurality of host computers as hosts + requiring security for packets transmitted between them, + the method being carded out by means of the instructions + stored in said respective memories and including the + steps of: + + (1) generating, by the first host computer, a first data + packet for transmission to the second host computer, a + portion of the data packet including information + representing an internetwork address of the first host + computer and an internetwork address of the second host + computer; + + (2) in the first bridge computer, intercepting the first + data packet and determining whether the first and second + host computers are among the predetermined plurality of + host computers for which security is required, and if + not, proceeding to step 5, and if so, proceeding to step + 3; + + (3) encrypting the first data packet in the first bridge + computer; + + (4) in the first bridge computer, generating and + appending (4) in the first bridge computer, generating + and appending to the first data packet an enapsulation + header, including: + + (a) key management information identifying the + predetermined encryption method, and + + (b) a new address header representing the source and + destination for the data packet, thereby generating a + modified data packet; + + (5) transmitting the data packet from the first bridge + computer via the internetwork to the second computer + network; + + (6) intercepting the data packet at the second bridge + computer; + + (7) in the second bridge computer, reading the + encapsulation header, and determining therefrom whether + the data packet was encrypted, and if not, proceeding to + step 10, and if so, proceeding to step 8; + + (8) in the second bridge computer, determining which + encryption mechanism was used to encrypt the first data + packet; + + (9) decrypting the first data packet by the second bridge + computer; + + (10) transmitting the first data packet from the second + bridge computer to the second host computer; and + + (11) receiving the unencrypted data packet at the second + host computer. + + Assignee: Sun Microsystems, Inc. + + Patent Number: 5548646 + + Issue Date: 1996 08 20 + + Inventor(s): Aziz, Ashar; Mulligan, Geoffrey; Patterson, + Martin; Scott, Glenn. State/Country CA Received: from relay.hq.tis.com by neptune.TIS.COM id aa00964; 30 Aug 96 17:56 EDT Received: by relay.hq.tis.com; id RAA28601; Fri, 30 Aug 1996 17:59:41 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma028597; Fri, 30 Aug 96 17:59:16 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA08753; Fri, 30 Aug 96 17:58:31 EDT Received: by relay.hq.tis.com; id RAA28594; Fri, 30 Aug 1996 17:59:10 -0400 Received: from tik1.ethz.ch(129.132.119.131) by relay.tis.com via smap (V3.1.1) id xma028592; Fri, 30 Aug 96 17:58:51 -0400 Received: from kom30.ethz.ch (kom30 [129.132.66.8]) by tik1.ethz.ch (8.7.5/8.7.3) with ESMTP id AAA09960; Sat, 31 Aug 1996 00:01:08 +0200 (MET DST) From: Germano Caronni <caronni@tik.ee.ethz.ch> Received: (from caronni@localhost) by kom30.ethz.ch (8.7.5/8.7.3) id AAA07280; Sat, 31 Aug 1996 00:01:05 +0200 (MET DST) Message-Id: <199608302201.AAA07280@kom30.ethz.ch> Subject: Re: Patents by Sun? To: Ken Siegel <ksiegel@switchblade.com> Date: Sat, 31 Aug 1996 00:01:04 +0200 (MET DST) Cc: rodney@sabletech.com, perry@piermont.com, ipsec@TIS.COM In-Reply-To: <2.2.32.19960830191858.006ba480@tiac.net> from "Ken Siegel" at Aug 30, 96 03:18:58 pm X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Sender: ipsec-approval@neptune.tis.com Precedence: bulk Ken Siegel wrote: > If it is true that it was granted it is not yet > online. However, Ashar (and hence Sun) have been > granted another patent (in 1995) that I found in > the database. The returned abstract is listed > below. Sorry if the formatting is bad but I cut > and pasted from Netscape. This patent is certainly > also relevant to IPSEC. > > Method and apparatus for key-management scheme for use with internet > protocols at site firewalls Well, it is none of my business, but _that_ patent has been placed in the public domain a long while ago. I guess they did this so nobody else could make a patent on that stuff and hinder their work. Germano ----excerpt of blurb----- Sun Microsystems, Inc., in the interest of promoting an open-systems, standardized approach to key management for use on the Internet, is taking the step of dedicating important intellectual property rights in this area to the public. Sun has submitted a proposed specification to the IETF entitled "Simple Key Management Scheme for Internet Protocols (SKIP)". On June 10 1994, Sun filed two patent applications with the United States Patent Office relating to SKIP, entitled "Method and Apparatus for a Key Management Scheme for Internet Protocols", Serial No. 08/258,272; and "Method and Apparatus for Key Management Scheme for Use with Internet Protocols at Site Firewalls", Serial No. 08/258,344. Sun wishes to dedicate its rights under these two applications to the public, and to that end hereby licenses all persons and companies to practice the SKIP procedures claimed in these patent applications (and in the patents resulting from the applications, when and if they issue). This license is immediately effective, and requires no fee. Received: from relay.hq.tis.com by neptune.TIS.COM id aa10175; 31 Aug 96 9:54 EDT Received: by relay.hq.tis.com; id JAA03752; Sat, 31 Aug 1996 09:57:35 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma003750; Sat, 31 Aug 96 09:57:10 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA19611; Sat, 31 Aug 96 09:56:24 EDT Received: by relay.hq.tis.com; id JAA03747; Sat, 31 Aug 1996 09:57:05 -0400 Received: from angus.asg.unb.ca(198.164.16.10) by relay.tis.com via smap (V3.1.1) id xma003745; Sat, 31 Aug 96 09:57:03 -0400 Received: from opie.ASG.unb.ca by mailhub.ASG.unb.ca (AIX 3.2/UCB 5.64/4.03) id AA50570; Fri, 30 Aug 1996 12:20:37 -0300 Date: Fri, 30 Aug 1996 12:20:37 -0300 (ADT) From: Peter Howlett <phowlett@asg.unb.ca> To: ipsec@TIS.COM Subject: Re: "user" and "network layer" security. reply to respondents. In-Reply-To: <Pine.SUN.3.91.960830095654.26224C-100000@panix.com> Message-Id: <Pine.A32.3.93.960830120814.15482A-100000@opie.ASG.unb.ca> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk I have always thought about this from the point of view that the user level does indeed sometimes have a direct influence on lower layers in the stack. IP options for example can be manipulated by a user to get particular attributes from a mode of communication. With IPv6, and those new headers that can be inserted between the conventional layers of the stack, attributes of packets that are sent out can be set by a user level application. Personally, I do not believe this constitutes breaking the architecture, but simply provides required control over the data (and corresponding attributes) that are sent and received. I think IPSec falls into this category. On Fri, 30 Aug 1996, M.C.Nelson wrote: > Bill, > > The transport layer doesn't have "user" either. Adding a "user" concept > in a new layer between the transport and network layer still breaks the > network architecture. > > Regards, > Mitch Nelson > netsec@panix.com > > > > > On Thu, 29 Aug 1996, Bill Sommerfeld wrote: > > > Another way of looking at ipsec is that the transforms are really a > > layer *in between* network and transport. > > > > You're not so much adding a "user" concept at the network layer as > > adding a new layer next to the transport layer, which already has a > > concept of "user". > > > > - Bill > > > -------------------------------------------------------------------- Peter Howlett Atlantic Systems Group E-Mail: Peter.Howlett@ASG.unb.ca Fredericton, N.B. Canada http://www.ASG.unb.ca/personal/ph.html Phone: (506) 447-3050 PGP Key ID: 60F2EEC1 Fax: (506) 453-5004