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 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 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 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 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 From: Naganand Doraswamy 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 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 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{ 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 ; 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 ; 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" 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" 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 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 ; 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 ; 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 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 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 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" 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 , dennis.glatting@plaintalk.bellevue.wa.us From: Robert Moskowitz Subject: Re: DNSSEC for IPSEC? Cc: John Gilmore , 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 , 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" 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 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 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 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" 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 " 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" 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" 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 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 To: "Brian W. McKenney" , "'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 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 +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 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 2. HMAC-SHA IP Authentication with Replay Prevention 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 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" 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 " 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` 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 | Milkyway Networks Corporation Michael C. Richardson | Makers of the Black Hole firewall Senior Research Specialist | info@milkyway.com for BlackHole questions Home: mcr@sandelman.ocunix.on.ca. "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 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 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: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 8 Aug 1996 10:24:53 -0400 To: Hilarie Orman From: Stephen Kent 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 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 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: 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 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 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: 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 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 From: Naganand Doraswamy 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 , Rodney Thayer From: Bob Monsour 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 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" 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 Date: Fri, 9 Aug 96 11:22:42 +0200 To: Naganand Doraswamy 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 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 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 >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 +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: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Rodney Thayer , ipsec@TIS.COM From: "Robert W. Shirey" 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 >>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 +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 | 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: 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 . 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" 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 > > > 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" 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" 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" 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 To: "H.Krawczyk" 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: 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" Cc: Rodney Thayer , ipsec@TIS.COM Subject: Re: compression algorithms A FEW MORE References: In-Reply-To: Your message of "Fri, 09 Aug 1996 14:05:49 -0400". From: "C. Harald Koch" Organization: Border Network Technologies Inc. Phone: +1 416 368 7157 X-Uri: 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 , "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 (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 ; Sun, 11 Aug 1996 17:49:03 -0400 (EDT) Date: Sun, 11 Aug 96 21:37:26 GMT From: William Allen Simpson 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 > 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" 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 > > 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 To: "Mark S. Schneider" 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: 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: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 12 Aug 1996 19:07:30 -0400 To: Marcel Waldvogel From: Stephen Kent Subject: Re: I-D ACTION:draft-thayer-seccomp-00.txt Cc: Naganand Doraswamy , 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" > 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 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" 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 " 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 ; 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 ; 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 Message-Id: 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 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 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 <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 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" 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 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 +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" From: Naganand Doraswamy 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 From: Joe Tardo 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` 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 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