From ipsec-request@ans.net Wed Nov 1 20:49:42 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12608 (5.65c/IDA-1.4.4 for ); Wed, 1 Nov 1995 16:09:25 -0500 Received: by interlock.ans.net id AA11165 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 1 Nov 1995 15:52:17 -0500 Message-Id: <199511012052.AA11165@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 1 Nov 1995 15:52:17 -0500 From: Ran Atkinson Date: Wed, 1 Nov 1995 15:49:42 -0500 Reply-To: rja@cs.nrl.navy.mil X-Mailer: Z-Mail (3.2.1 10apr95) To: ipsec@ans.net Subject: photuris-06.txt Cc: rja@cs.nrl.navy.mil Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: rja@bodhi.cs.nrl.navy.mil Personal comments on the photuris-06.txt draft, mostly organised by document section... 1.6: Please replace the string "in Multi-Level Secure environments," with the string "for multi-user systems," 2.0 (2): It is conceivable that not all ICMP Dest Unreachable, Communication Administratively Prohibited messages that are received will relate to IPsec. It is possible that they might originate at a Firewall that does not implement IPsec, for example. Hence, I'd like to suggest that this text be clarified so that an implementation understands that receipt of such an ICMP message might be good cause to try Photuris but that it is not a "MUST" requirement to try Photuris in that case. 2.4: Delete the sentences below because the document should only specify mechanism and must not specify policy. Different sites can and will have different policies. Policies are not appropriate matter for a regular standards-track document. I don't yet fully understand the new BCP document class, but it is conceivable that one might specify a policy in a BCP style document that is separate from the mechanism document. ... "Encryption policy is in the SPI User (sender) direction." ... "Authentication policy is in the SPI Owner (receiver) direction." ... I don't understand the meaning of the sentence below. Please either clarify it or delete it. Perhaps you are trying to say that "choices are made from the set of offered attributes and that a node does not need to create an SA for each possible combination of offered attributes" ?? "It is not required that a Security Association be created including every offered attribute, or that a SPI be created for every offered attribute." 3.3: I propose rephrasing "Instead, the secret SHOULD be changed at the same frequency as its Exchange-value." to instead read "The Responder secret random value SHOULD be changed at the same frequency as its Exchange-value." 4: Instead of saying "unused", I'd suggest saying "Reserved for possible future use" so that folks clearly understand that this is not a field that they can play with. This comment repeats throughout the remainder of the draft. 4.1: How does the Initiator determine the Initiator-Exchange-Value ? If this is explained elsewhere in the Photuris spec and I missed the explanation, then that means an explicit section reference is needed here. Which 3 Security Parameter attributes are required ? I wonder if this might be trying to say something like: "The Initiator-Offered-Attributes MUST include at least MD5, DES-CBC, and some certificate." 4.2: Same comment as for 4.1 about "3 minimum Security Parameter attributes". I HAVE read the spec but it is not really clear which 3 are mandatory. B: Please change "unassigned" to read "Reserved to IANA" for the Attribute Type numbers. It is important that people understand that they cannot just take and use these numbers wantonly. I didn't finish all of the material after 4.2 in draft-06, but think it is probably sensible to go start on draft-07a (though you won't get comments from me until Monday at the earliest). Ran rja@cs.nrl.navy.mil From ipsec-request@ans.net Wed Nov 1 22:16:00 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14704 (5.65c/IDA-1.4.4 for ); Wed, 1 Nov 1995 18:23:05 -0500 Received: by interlock.ans.net id AA14839 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 1 Nov 1995 18:13:52 -0500 Message-Id: <199511012313.AA14839@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 1 Nov 1995 18:13:52 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 1 Nov 1995 18:13:52 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 1 Nov 1995 18:13:52 -0500 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 1 Nov 1995 18:13:52 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 1 Nov 1995 18:13:52 -0500 Date: 1 Nov 95 16:16:00 -0600 To: cm2bcxg@bs47c.staffs.ac.uk, ipsec@ans.net Subject: Re: key management information Xavier, Key management is a topic of discussion on this list. A major work item of this group is to develop the "Internet Key Management Protocol". Three draft proposals are currently posted on this work item. They are: - draft-ietf-ipsec-photuris-* - draft-ietf-ipsec-skip-* - draft-ietf-ipsec-isakmp-* These can be downloaded fron the IETF archive. YOu might have your library look for the NTIS publication on Key Management written by Roberto Zamparo. This survey covered a variety of existing work and would serve as a good starting point for research. Paul PS - I may miss a few mail messages over the next week, I am changing employers. _______________________________________________________________________________ Subject: key management information Author: cm2bcxg@bs47c.staffs.ac.uk@INTERNET Date: 10/31/95 3:48 AM Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I'm sorry if it's not really the topic of the discussion, but here I can reach the people who may know what I need. I'm looking for information on key management in general and in the IP suite. - documents - links to web or anonym. ftp - anything interesting ?!?!?! Thanks for any help. Xavier. --------------------------------------------------- | Xavier Gosselin | Staffordshire University -UK | - - - - - - - - - - - - - - - - - - - - - - - - - - | E-mail : cm2bcxg@bs47c.staffs.ac.uk | --------------------------------------------------- From ipsec-request@ans.net Thu Nov 2 00:05:45 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA04203 (5.65c/IDA-1.4.4 for ); Wed, 1 Nov 1995 20:30:30 -0500 Received: by interlock.ans.net id AA17417 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 1 Nov 1995 20:18:01 -0500 Message-Id: <199511020118.AA17417@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 1 Nov 1995 20:18:01 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 1 Nov 1995 20:18:01 -0500 Date: Thu, 2 Nov 95 00:05:45 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: photuris-06.txt Thanks, Ran. 4K message; rather a lot. Well, here goes.... > From: Ran Atkinson > 1.6: Please replace the string "in Multi-Level Secure > environments," > with the string "for multi-user systems," > Not intended for plain-old multi-user systems. Too many holes. Cannot guarantee correct operation of the protocol. Folks have already indicated some of the holes on this list. Also, if there are no "levels" of security (that is, all users are authorized to the same access control or the access control is not mandatory), then there is no reason for separate user-level keying. They can read each others' traffic. For plain-old multi-user operating systems, node-node keying is the only technique available. This secures IP from _outside_ interference, even when the end-systems themselves are not secure. > 2.0 (2): It is conceivable that not all ICMP Dest Unreachable, > Communication Administratively Prohibited messages that are > received will relate to IPsec. It is possible that they might > originate at a Firewall that does not implement IPsec, for > example. > That's certainly the expected current case. > Hence, I'd like to suggest that this text be clarified so > that an implementation understands that receipt of such an ICMP > message might be good cause to try Photuris but that it is not > a "MUST" requirement to try Photuris in that case. > It _IS_ a MUST to _try_ Photuris (how would it know _not_ to try?), just not a must succeed. But then, nothing is. And trying is better than nothing. So, that is when an exchange begins. Always. As described last week in the scenarios, if another admin prohibited is received for Photuris, _then_ quit. > 2.4: Delete the sentences below because the document should only > specify mechanism and must not specify policy. > ... > "Encryption policy is in the SPI User (sender) direction." > > "Authentication policy is in the SPI Owner (receiver) direction." > Your assertion is correct. Your analysis of the division is not. Note that the policy itself (Joe can only use FTP not Telnet) is not specified. Only the direction of the policy, as required by the mechanism. Your other comments are already discussed: Each party implements local policy that determines what access, if any, is granted to the holder of a particular identity. For | example, the party might allow anonymous FTP, but prohibit Telnet. | Such policy considerations are outside the scope of this document. > I don't understand the meaning of the sentence below. Please > either clarify it or delete it. Perhaps you are trying to say > that "choices are made from the set of offered attributes and > that > a node does not need to create an SA for each possible > combination > of offered attributes" ?? > > "It is not required that a Security Association be > created > including every offered attribute, or that a SPI be > created > for every offered attribute." > Good ideas. How about: When choices are made from the set of Offered-Attributes, it is not required that any Security Association include every kind of offered attribute in any one SPI, or that a separate SPI be created for every offered attribute. These combinations are implementation dependent. > 3.3: I propose rephrasing > "Instead, the secret SHOULD be changed at the same > frequency as its Exchange-value." > to instead read > "The Responder secret random value SHOULD be changed at > the same frequency as its Exchange-value." > That seems awkward to me, as that phrase was used in the previous sentence. How about: The Responder secret random value MAY remain the same for many different Initiators. Instead, this secret SHOULD be changed whenever the Responder Exchange-Value is changed. > 4: Instead of saying "unused", I'd suggest saying "Reserved for > possible future use" so that folks clearly understand that > this is not a field that they can play with. This comment > repeats throughout the remainder of the draft. > (Sigh) and I changed it to this a couple of rounds ago at another suggestion. Sure, why not.... (both places) Reserved one octet. For future use; MUST be set to zero when transmitted, and MUST be ignored when received. > 4.1: How does the Initiator determine the Initiator-Exchange-Value ? > If this is explained elsewhere in the Photuris spec and I > missed the explanation, then that means an explicit section > reference is needed here. > It's in the ME and EC sections you asked to be moved to the end (which used to be at the beginning). It already has an explicit reference to the "Scheme Choice", which in turn references the "Exchange Scheme Appendix", which in turn (for each scheme) references ME or EC. That's pretty thorough! > Which 3 Security Parameter attributes are required ? > I wonder if this might be trying to say something like: > "The Initiator-Offered-Attributes MUST include > at least MD5, DES-CBC, and some certificate." > Sorry, but that's MD5, DES-CBC-32, and DES-CBC-64. They are indicated in the Appendix. It already says all that: The formats are specified in the "Attribute List" Appendix, where mandatory attributes are also specified. The end of the list is indicated by the > 4.2: Same comment as for 4.1 about "3 minimum Security Parameter > attributes". I HAVE read the spec but it is not really clear > which 3 are mandatory. > Same response. > B: Please change "unassigned" to read "Reserved to IANA" for the > Attribute Type numbers. It is important that people understand > that they cannot just take and use these numbers wantonly. > This is already official IANA-speak. "unassigned" is the term for something which IANA can assign. "reserved" means IANA cannot assign it. However, I could add some verbiage that unassigned numbers must be requested from IANA: Up-to-date values for the Attribute Type are specified in the most recent "Assigned Numbers" [RFC-1700]. Implementors wishing a number indicated as "unassigned" MUST request the number from IANA. Initial values are assigned as follows: Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Thu Nov 2 04:38:54 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15594 (5.65c/IDA-1.4.4 for ); Wed, 1 Nov 1995 23:49:49 -0500 Received: by interlock.ans.net id AA20528 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 1 Nov 1995 23:39:03 -0500 Message-Id: <199511020439.AA20528@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 1 Nov 1995 23:39:03 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 1 Nov 1995 23:39:03 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 1 Nov 1995 23:39:03 -0500 Date: Wed, 1 Nov 1995 23:38:54 -0500 From: Theodore Ts'o To: "William Allen Simpson" Cc: ipsec@ans.net In-Reply-To: William Allen Simpson's message of Thu, 2 Nov 95 00:05:45 GMT, <199511020118.AA17417@interlock.ans.net> Subject: Re: photuris-06.txt Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 2450 Date: Thu, 2 Nov 95 00:05:45 GMT From: "William Allen Simpson" > From: Ran Atkinson > 1.6: Please replace the string "in Multi-Level Secure > environments," > with the string "for multi-user systems," > Not intended for plain-old multi-user systems. Too many holes. Cannot guarantee correct operation of the protocol. Folks have already indicated some of the holes on this list. Also, if there are no "levels" of security (that is, all users are authorized to the same access control or the access control is not mandatory), then there is no reason for separate user-level keying. They can read each others' traffic. The generally accepted meaning of "Multi-Level Secure" environments, at least in the security world, is environments where there is non-discrentionary access controls --- that is, data is tagged with labels such as "Secret", "Top-Secret", etc. and data which is labelled as "Top-Secret" may not be displayed on devices which are labelled "Secret". Thus, using the term "Multi-Level Secure" in your document is extremely confusing, because this is not what is meant. What we are talking about is a system where you have a multi-user where the operating system actually tries to protect user A from being able to do things to user B, and vice versa. Unix, for example, attempts to have this property, although in practice there seems to always be one more way to break in as root. For plain-old multi-user operating systems, node-node keying is the only technique available. This secures IP from _outside_ interference, even when the end-systems themselves are not secure. What you call "plain-old multi-user operating systems", by which I would assume mean systems like Windows NT and ITS, I would merely call them "single-user operating systems", or "insecure multi-user operating systems". Any secure multi-user system worth its salt must be able to protect its resources from hostile users, and protect one hostile user from being able to damage the resources controlled by another hostile user. At the heart of this, I think we have a terminology problem; we can come up with different terms, but we really should avoid the use of Multi-Level Secure systems unless we mean a system which enforces non-discrentional access control. There's no point in bucking 3 decades worth of usage..... - Ted From ipsec-request@ans.net Thu Nov 2 12:49:54 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14833 (5.65c/IDA-1.4.4 for ); Thu, 2 Nov 1995 08:01:58 -0500 Received: by interlock.ans.net id AA25551 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 2 Nov 1995 07:52:03 -0500 Message-Id: <199511021252.AA25551@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 2 Nov 1995 07:52:03 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 2 Nov 1995 07:52:03 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 2 Nov 1995 07:52:03 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 2 Nov 1995 07:52:03 -0500 X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 02 Nov 1995 07:49:54 -0500 To: "William Allen Simpson" , ipsec@ans.net From: Robert Moskowitz Subject: Re: scenario: Authenticated Firewall Traversal At 02:10 PM 10/25/95 GMT, William Allen Simpson wrote: >An administrator has one or more networks, and a number of mobile users. >It is desirable to restrict access to authorized external users. The >boundary router is 3.0.0.3. > >Each user adds commands to tunnel and authenticate. > > route addp 3.0.0.0/8 tunnel 3.0.0.3 > secure 3.0.0.3 authenticate-only > I want to walk through this example a lot slower with some 'real world' flavor to it. First off, the external reachable address is not on the same network as the internal stuff (firewall is a CIDR block, internal is a registered B and some 1597 nets). So: route addp 129.9.0.0/16 tunnel 198.100.100.1 route addp 172.16.0.0/16 tunnel 198.100.100.1 route addp 192.168.0.0/22 tunnel 198.100.100.1 secure 198.100.100.1 authenticate-only Correct? Next, of course the public DNS knows nothing about these systems behind the firewall so resolv.conf needs: domain foo.com nameserver 1.1.1.1 ; ISP's DNS nameserver 129.9.241.19 ; internal DNS A resolve of host.fin.foo.com would result in two UDP attempts. The first to 1.1.1.1 that would not know of this name. Would resolve then actually try the 2nd address (well Novell's LWP would becuase it does the whole list at once, not waiting for failures). Assuming that the 2nd request went out, it would result in an encrypted pass through the firewall. If this is the first shot at the internal net, this packet might timeout resulting in a second one. Is all of this correct? Now I am ready to access TCP and UDP apps inside the firewalled net... BTW, there is a BIG market for this in Corporate US (I've grown from 100 to 3000 remote PPP users this year; next might double the total). Robert Moskowitz Chrysler Corporation (810) 758-8212 From ipsec-request@ans.net Thu Nov 2 12:50:08 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA04338 (5.65c/IDA-1.4.4 for ); Thu, 2 Nov 1995 08:01:58 -0500 Received: by interlock.ans.net id AA25558 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 2 Nov 1995 07:52:33 -0500 Message-Id: <199511021252.AA25558@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 2 Nov 1995 07:52:33 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 2 Nov 1995 07:52:33 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 2 Nov 1995 07:52:33 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 2 Nov 1995 07:52:33 -0500 X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 02 Nov 1995 07:50:08 -0500 To: David_A Wagner , ipsec@ans.net From: Robert Moskowitz Subject: Re: major areas needing work At 05:03 PM 10/8/95 -0700, David_A Wagner wrote: >I'd like to know what critical IPSEC projects still need work done. >In other words, what does IP security need to move forward that we're >still lacking? Compression for remote users! >I need a medium-sized (200+ hours) project for an operating systems >class, and I'd like to spend it on something useful. If the working >group is searching for a volunteer to implement some piece of IPSEC, >please let me know. (Or if anybody has any suggestions or wish lists >outside of IPSEC, I'd love to hear from you!) This %^&%%&^& legal threatening on compression patents needs to be settle in Dallas. I guess that I am going to have to just bring it up to the IAB ;) Robert Moskowitz Chrysler Corporation (810) 758-8212 From ipsec-request@ans.net Thu Nov 2 15:31:58 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12614 (5.65c/IDA-1.4.4 for ); Thu, 2 Nov 1995 10:45:07 -0500 Received: by interlock.ans.net id AA29347 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 2 Nov 1995 10:32:07 -0500 Message-Id: <199511021532.AA29347@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 2 Nov 1995 10:32:07 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 2 Nov 1995 10:32:07 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 2 Nov 1995 10:32:07 -0500 X-Mailer: exmh version 1.6.2 7/18/95 To: "William Allen Simpson" Cc: ipsec@ans.net, Theodore Ts'o Subject: Re: photuris-06.txt In-Reply-To: tytso's message of Wed, 01 Nov 1995 23:38:54 -0500. <199511020439.AA20528@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 02 Nov 1995 10:31:58 -0500 From: Bill Sommerfeld -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii I'd like to make a few assertions in the name of forward progress: Assertion 1: - The current Photuris draft is not adequate for systems which support multiple cryptographic identities and which *attempt* to segregate users from each other. Assertion 2: - The text in the current drafts regarding MLS systems encourages people to *think* that assertion 1 may be false until after they spend considerable time attempting to work out scenarios for using Photuris and IPSec within networks of multi-user systems. This has led to a fair amount of thrashing about on this list and in private mail. Assertion 3: - I don't see this limitation as a fundamental limit of photuris; I think that some relatively *MINOR* adjustments and extensions can be made to the protocol to securely support multi-user systems. Most likely, these adjustments would come in the form of additional attributes. Suggestion: - The current photuris draft should admit that Photuris as currently specified is only adequate for systems supporting a single cryptographic entity at a time; this entity could viewed as either a "host" or a "user". - Defer work on multi-cryptographic-entity systems to a separate draft, to be titled something like "extensions to photuris for multi-user systems". - Bill -----BEGIN PGP SIGNATURE----- Version: 2.6.1 iQCVAwUBMJjka1pj/0M1dMJ/AQHv+gP9HkgCRJVGK4tmHijNiJsuMBTJhSPQy6XV qLQNGVIspBEqdHErDh08zw6zCimu6NCqr+CQ1dfpmU5qjoeJAI9f/Sp+iXSnFfCc ASflGF97BQrFVfWqWUy+5qj5YOXqLUQC1IdaLMR4D0zjfE2rrq+U5lKARdqpzxlk uGlZrgZGo78= =wTuF -----END PGP SIGNATURE----- From ipsec-request@ans.net Fri Nov 3 14:18:21 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18849 (5.65c/IDA-1.4.4 for ); Fri, 3 Nov 1995 09:39:45 -0500 Received: by interlock.ans.net id AA02638 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 3 Nov 1995 09:31:12 -0500 Message-Id: <199511031431.AA02638@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 3 Nov 1995 09:31:12 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 3 Nov 1995 09:31:12 -0500 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ipsec-skip-04.txt Date: Fri, 03 Nov 95 09:18:21 -0500 Sender: cclark@CNRI.Reston.VA.US --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 Filename : draft-ietf-ipsec-skip-04.txt Pages : 57 Date : 11/02/1995 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, IP 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 IP or IPv6. We also describe a simple extension of this protocol to provide scalable groupkey-management for Internet multicasting protocols. 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-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-04.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-skip-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951103084215.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-skip-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-skip-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951103084215.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Fri Nov 3 14:17:01 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA04262 (5.65c/IDA-1.4.4 for ); Fri, 3 Nov 1995 09:39:46 -0500 Received: by interlock.ans.net id AA02605 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 3 Nov 1995 09:30:26 -0500 Message-Id: <199511031430.AA02605@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 3 Nov 1995 09:30:26 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 3 Nov 1995 09:30:26 -0500 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ipsec-isakmp-02.txt, .ps Date: Fri, 03 Nov 95 09:17:01 -0500 Sender: cclark@CNRI.Reston.VA.US --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 : Internet Security Association and Key Management Protocol (ISAKMP) Author(s) : D. Maughan, B. Patrick, M. Schertler Filename : draft-ietf-ipsec-isakmp-02.txt, .ps Pages : 38 Date : 11/02/1995 This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and cryptographic keys in an Internet environment. A Security Association protocol that negotiates, establishes, modifies and deletes Security Associations and their attributes is required for an evolving Internet, where there will be numerous security mechanisms and several options for each security mechanism. The key management protocol must be robust in order to handle public key generation for the Internet community at large and private key requirements for those private networks with that requirement. The Internet Security Association and Key Management Protocol (ISAKMP) defines the procedures for authenticating a communicating peer, creation and management of Security Associations, key generation techniques, and threat mitigation (e.g. denial of service and replay attacks). All of these are necessary to establish and maintain secure communications (via IP Security Service or any other security protocol) in an Internet environment. 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-isakmp-02.txt". Or "get draft-ietf-ipsec-isakmp-02.ps". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-02.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-02.txt". Or "FILE /internet-drafts/draft-ietf-ipsec-isakmp-02.ps". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951102092349.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951102092349.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Sat Nov 4 23:22:32 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18863 (5.65c/IDA-1.4.4 for ); Sat, 4 Nov 1995 23:22:32 -0500 Received: by interlock.ans.net id AA20385 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 4 Nov 1995 23:16:02 -0500 Message-Id: <199511050416.AA20385@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Sat, 4 Nov 1995 23:16:02 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 4 Nov 1995 23:16:02 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 4 Nov 1995 23:16:02 -0500 Date: Sat, 4 Nov 1995 21:15:39 -0700 From: Hilarie Orman To: ipsec@ans.net Subject: YAWP (yes --- Yet Another Web Page) This web page might be of interest if you are looking for a guide to what's on-line and relevant to this WG http://www.cs.arizona.edu/xkernel/www/ipsec/ipsec.html I find it useful if only for the URLs pointing at the RFC's and drafts (which I try to keep current). From ipsec-request@ans.net Sun Nov 5 16:25:06 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13732 (5.65c/IDA-1.4.4 for ); Sun, 5 Nov 1995 11:44:51 -0500 Received: by interlock.ans.net id AA26037 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 5 Nov 1995 11:39:25 -0500 Message-Id: <199511051639.AA26037@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 5 Nov 1995 11:39:25 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 5 Nov 1995 11:39:25 -0500 Date: Sun, 5 Nov 95 16:25:06 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: photuris-06.txt > From: Bill Sommerfeld > Assertion 1: > > - The current Photuris draft is not adequate for systems which > support multiple cryptographic identities and which *attempt* to > segregate users from each other. > Counter assertion. Photuris _requires_ that the _attempt_ be successful, in which case Photuris is more than adequate for generating user keys. Photuris is a key management protocol, not a secure operating system. Photuris is admittedly not useful for segregating user keys when the operating system fails to do so. Photuris is not process-oriented. Detailed wording has been added to elucidate this "failing". Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Sun Nov 5 16:17:28 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18086 (5.65c/IDA-1.4.4 for ); Sun, 5 Nov 1995 11:44:52 -0500 Received: by interlock.ans.net id AA26031 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 5 Nov 1995 11:39:22 -0500 Message-Id: <199511051639.AA26031@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 5 Nov 1995 11:39:22 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 5 Nov 1995 11:39:22 -0500 Date: Sun, 5 Nov 95 16:17:28 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: major areas needing work > From: Robert Moskowitz > At 05:03 PM 10/8/95 -0700, David_A Wagner wrote: > >I'd like to know what critical IPSEC projects still need work done. > >In other words, what does IP security need to move forward that we're > >still lacking? > > Compression for remote users! > Already in Photuris Extensions. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Sun Nov 5 16:08:42 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18857 (5.65c/IDA-1.4.4 for ); Sun, 5 Nov 1995 11:44:53 -0500 Received: by interlock.ans.net id AA26025 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 5 Nov 1995 11:39:20 -0500 Message-Id: <199511051639.AA26025@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 5 Nov 1995 11:39:20 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 5 Nov 1995 11:39:20 -0500 Date: Sun, 5 Nov 95 16:08:42 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: photuris-06.txt Catching up on IP Sec, > From: "Theodore Ts'o" > Thus, using the term "Multi-Level Secure" in your document is extremely > confusing, because this is not what is meant. Actually, it means what it says. I don't consider Unix, based on its history, a secure multi-user operating system, and wanted to limit the debate to systems with well-defined security using well-defined terminology. Waste of time arguing about how to partially secure insecure operating systems. > What you call "plain-old multi-user operating systems", by which I would > assume mean systems like Windows NT and ITS, I would merely call them > "single-user operating systems", or "insecure multi-user operating > systems". > Fine. I will change the wording to "secure multi-user operating systems with mandatory access controls". > Any secure multi-user system worth its salt must be able to protect its > resources from hostile users, and protect one hostile user from being > able to damage the resources controlled by another hostile user. > Have incorporated your text with Karn's as follows: Internet Security protects against threats that come from the external network, not from mutually hostile users of the nodes themselves. Any secure multi-user operating system MUST be able to protect its resources from hostile users, and protect one hostile user from damaging the resources controlled by another hostile user. And in Notes: Successful use of user-oriented keying requires a significant level of operating system support. If the operating system itself is not secure, or there are no "levels" of security (that is, all users are authorized to the same access control or the access control is not mandatory), then there is no basis for separate user-oriented keying. Use of multi-user segregated exchanges likely requires added functionality in the transport API of the implementation operating system. Such a mechanism is outside the scope of this document. > At the heart of this, I think we have a terminology problem; we can come > up with different terms, but we really should avoid the use of > Multi-Level Secure systems unless we mean a system which enforces > non-discrentional access control. There's no point in bucking 3 decades > worth of usage..... > Wasn't trying to do that. It is Sommerfeld who didn't like the fact that it was inapplicable to his insecure operating system. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Sun Nov 5 22:01:10 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18807 (5.65c/IDA-1.4.4 for ); Sun, 5 Nov 1995 17:10:38 -0500 Received: by interlock.ans.net id AA28200 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 5 Nov 1995 17:01:15 -0500 Message-Id: <199511052201.AA28200@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Sun, 5 Nov 1995 17:01:15 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 5 Nov 1995 17:01:15 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 5 Nov 1995 17:01:15 -0500 To: ipsec@ans.net Subject: ip addresses as domain names Date: Sun, 05 Nov 1995 17:01:10 -0500 From: "Donald E. Eastlake 3rd" Just a quick note to point out that all possible IPv4 addresses have been mapped into domain names in the in-addr.arpa domain (just as, for example, all possible telephone numbers have been mapped into the tpc.int domain and draft-ietf-dnssec-as-map-02.txt gives a mapping of all Autonomous System numbers into domain names). From ipsec-request@ans.net Mon Nov 6 01:09:29 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14816 (5.65c/IDA-1.4.4 for ); Sun, 5 Nov 1995 20:21:16 -0500 Received: by interlock.ans.net id AA29619 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 5 Nov 1995 20:09:38 -0500 Message-Id: <199511060109.AA29619@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Sun, 5 Nov 1995 20:09:38 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 5 Nov 1995 20:09:38 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 5 Nov 1995 20:09:38 -0500 Date: Sun, 5 Nov 1995 20:09:29 -0500 From: Theodore Ts'o To: "William Allen Simpson" Cc: ipsec@ans.net In-Reply-To: William Allen Simpson's message of Sun, 5 Nov 95 16:08:42 GMT, <199511051639.AA26025@interlock.ans.net> Subject: Re: photuris-06.txt Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 2854 Date: Sun, 5 Nov 95 16:08:42 GMT From: "William Allen Simpson" > What you call "plain-old multi-user operating systems", by which I would > assume mean systems like Windows NT and ITS, I would merely call them > "single-user operating systems", or "insecure multi-user operating > systems". Fine. I will change the wording to "secure multi-user operating systems with mandatory access controls". [You keep using terms like "inconceivable"... errr, "mandatory access controls" and "multi-level systems"; I'm don't think it means what you think it means.....] You should remove "mandatory access controls" from the draft. Photoris will work fine on a properly implemented, secure operating systems with non-discrentionary access controls --- which means access controls which are under the control of the owner of the object. That is, if I own a file, I can decide whether or not Bob or Alice is allowed to look at it, and the operating system will respect my wishes, and not allow an attacker to circumvent the access controls which I placed on that object. "Mandatory access controls" means that even if I own the file, I may not be allowed to let Bob or Alice look at it. I won't be able to mail it to them, or print it on a printer which they might be able to get access to. If I'm running X-11 windows, it means that the operating system has to keep track of whether I'm allowed to cut from one window to another, lest I be able to send a top-secret file to Bob or Alice, who only secret clearance. There are those who claim that the only reason why mandatory access controls are at all useful on modern computer systems is because generals want to be able to play (non-classified) Tetris on the same system where they have top-secret files stored. Many years ago, it might have been useful when it costed millions of dollars to purchase and operate mainframe-style systems in a data center. However, given how cheap hardware is today, it's much simpler and cheaper to have one computer that's only used for top-secret data, and another computer that's only used for non-classified data, instead of going to amazing lengths to try to segregate top-seceret and non-classified data on one machine. Whether or not MLS systems are only useful for enriching Beltway Bandits, and should be considered in the same category as $50,000 coffee machines, I will leave to others to debate. However, there is absolutely no reason why Photoris needs to make any requirements on an operating systems to provide "mandatory access controls." Bill, if you really believe that Photoris requires this level of protection before it's useful, could you please explain your reasoning? My guess is that you didn't really mean "mandatory access controls" in the sense which I described it above. - Ted From ipsec-request@ans.net Mon Nov 6 02:59:21 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12735 (5.65c/IDA-1.4.4 for ); Sun, 5 Nov 1995 22:10:36 -0500 Received: by interlock.ans.net id AA00958 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 5 Nov 1995 21:59:26 -0500 Message-Id: <199511060259.AA00958@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Sun, 5 Nov 1995 21:59:26 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 5 Nov 1995 21:59:26 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 5 Nov 1995 21:59:26 -0500 Date: Sun, 5 Nov 1995 21:59:21 -0500 From: Theodore Ts'o To: Theodore Ts'o Cc: "William Allen Simpson" , ipsec@ans.net In-Reply-To: Theodore Ts'o's message of Sun, 5 Nov 1995 20:09:29 -0500, <9511060109.AA05655@dcl.MIT.EDU> Subject: Re: photuris-06.txt Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 551 Date: Sun, 5 Nov 1995 20:09:29 -0500 From: Theodore Ts'o You should remove "mandatory access controls" from the draft. Photoris will work fine on a properly implemented, secure operating systems with non-discrentionary access controls --- which means access ^^^^ controls which are under the control of the owner of the object. Oops! There was a serious typo in my previous message to the list. "non-discretionary access controls" should have read "discretionary access controls". - Ted From ipsec-request@ans.net Tue Nov 7 05:02:00 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17764 (5.65c/IDA-1.4.4 for ); Tue, 7 Nov 1995 00:12:10 -0500 Received: by interlock.ans.net id AA28993 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 7 Nov 1995 00:02:07 -0500 Message-Id: <199511070502.AA28993@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 7 Nov 1995 00:02:07 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 7 Nov 1995 00:02:07 -0500 Date: Mon, 6 Nov 1995 21:02:00 -0800 (PST) From: Phil Karn To: tytso@MIT.EDU Cc: bsimpson@morningstar.com, ipsec@ans.net In-Reply-To: <199511060109.AA29619@interlock.ans.net> (tytso@MIT.EDU) Subject: Re: photuris-06.txt >There are those who claim that the only reason why mandatory access >controls are at all useful on modern computer systems is because >generals want to be able to play (non-classified) Tetris on the same >system where they have top-secret files stored. Many years ago, it >might have been useful when it costed millions of dollars to purchase >and operate mainframe-style systems in a data center. However, given With the trend toward personal workstations, one could make the exact same argument about civilian computer systems. All of the computers I directly use regularly each day, one at work and several at home, run multitasking operating systems of various kinds but they are dedicated to me. I think I can trust me not to hack myself. :-) So I'm only worried about other tasks when they're spawned by an outside attacker of the kind that Photuris *is* designed to block. Phil From ipsec-request@ans.net Tue Nov 7 13:21:29 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17754 (5.65c/IDA-1.4.4 for ); Tue, 7 Nov 1995 08:28:32 -0500 Received: by interlock.ans.net id AA03944 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 7 Nov 1995 08:22:08 -0500 Message-Id: <199511071322.AA03944@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 7 Nov 1995 08:22:08 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 7 Nov 1995 08:22:08 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 7 Nov 1995 08:22:08 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 7 Nov 1995 08:22:08 -0500 X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 07 Nov 1995 08:21:29 -0500 To: Phil Karn , tytso@MIT.EDU From: Robert Moskowitz Subject: Re: photuris-06.txt Cc: bsimpson@morningstar.com, ipsec@ans.net At 09:02 PM 11/6/95 -0800, Phil Karn wrote: > >With the trend toward personal workstations, one could make the exact >same argument about civilian computer systems. All of the computers I >directly use regularly each day, one at work and several at home, run >multitasking operating systems of various kinds but they are dedicated >to me. I think I can trust me not to hack myself. :-) > >So I'm only worried about other tasks when they're spawned by an >outside attacker of the kind that Photuris *is* designed to block. I'm puzzled by this thread. Help me a little. I 'trust' my desktop and notebook (well I better be a little careful, as they are both NT 3.51 :). But that SPARC 2000 that has one of my key databases on that I need to interact with? There is over 200Gb on that system now with 50 databases. Even the production SPARCs have a handful of people allowed to do direct logins for maintanance.... Robert Moskowitz Chrysler Corporation (810) 758-8212 From ipsec-request@ans.net Tue Nov 7 13:21:28 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13656 (5.65c/IDA-1.4.4 for ); Tue, 7 Nov 1995 08:28:32 -0500 Received: by interlock.ans.net id AA03943 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 7 Nov 1995 08:22:08 -0500 Message-Id: <199511071322.AA03943@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 7 Nov 1995 08:22:08 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 7 Nov 1995 08:22:08 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 7 Nov 1995 08:22:08 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 7 Nov 1995 08:22:08 -0500 X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 07 Nov 1995 08:21:28 -0500 To: "William Allen Simpson" , ipsec@ans.net From: Robert Moskowitz Subject: Re: major areas needing work At 04:17 PM 11/5/95 GMT, William Allen Simpson wrote: >> From: Robert Moskowitz >> At 05:03 PM 10/8/95 -0700, David_A Wagner wrote: >> >I'd like to know what critical IPSEC projects still need work done. >> >In other words, what does IP security need to move forward that we're >> >still lacking? >> >> Compression for remote users! >> >Already in Photuris Extensions. > OK. I grabbed the current draft. Yes compression is covered as an attribute value in Photuris. Big deal. What good is it (hooks are valuable, yes) to allow for negotiating compression when there is no compression defined for that IPSP protocol itself? Well fortunately, it looks like POISED is coming to some reality on this patent problem. Robert Moskowitz Chrysler Corporation (810) 758-8212 From ipsec-request@ans.net Tue Nov 7 14:02:43 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18117 (5.65c/IDA-1.4.4 for ); Tue, 7 Nov 1995 09:12:17 -0500 Received: by interlock.ans.net id AA04466 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 7 Nov 1995 09:02:32 -0500 Message-Id: <199511071402.AA04466@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Tue, 7 Nov 1995 09:02:32 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 7 Nov 1995 09:02:32 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 7 Nov 1995 09:02:32 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 7 Nov 1995 09:02:32 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 7 Nov 1995 09:02:32 -0500 Date: Tue, 7 Nov 1995 08:02:43 -0600 From: Tom Markham To: karn@qualcomm.com, tytso@MIT.EDU Cc: ipsec@ans.net Subject: RE: photuris-06.txt >There are those who claim that the only reason why mandatory access >controls are at all useful on modern computer systems is because >generals want to be able to play (non-classified) Tetris on the same >system where they have top-secret files stored. Many years ago, it >might have been useful when it costed millions of dollars to purchase >and operate mainframe-style systems in a data center. I agree that the cost of computing hardware has dropped significantly and will probably continue to drop. More and more of our society (commercial and Government) is now dependent upon computers in part because of the improved cost/performance of these systems. Are computers inexpensive enough that the Government could buy 2 systems instead of one for those users which must deal with data at two different security levels? I would say yes. (Congress may disagree.) Would this substitute for multi-level systems? No. Buying two single level systems which are never connected does provide strong separation. However, it does not provide what multilevel systems are designed for - controlled sharing. Computer systems (as opposed to stand alone machines) are useful because they can be networked together. Thus, we are able to exchange messages, browse the web, and receive up to the minute information. (I do not need to explain the value of networking to this group.) Multi-level systems will continue to be important because they provide controlled sharing of information in a timely manner. They can be networked to classified and unclassified networks. This provides decision makers with up to the minute information and allows two way communication with entities at different security levels. Tom Markham From ipsec-request@ans.net Tue Nov 7 17:22:20 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17728 (5.65c/IDA-1.4.4 for ); Tue, 7 Nov 1995 12:33:00 -0500 Received: by interlock.ans.net id AA09873 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 7 Nov 1995 12:23:11 -0500 Message-Id: <199511071723.AA09873@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 7 Nov 1995 12:23:11 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 7 Nov 1995 12:23:11 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: Phil Karn Cc: tytso@mit.edu, bsimpson@morningstar.com, ipsec@ans.net Subject: Re: photuris-06.txt In-Reply-To: Your message of "Mon, 06 Nov 1995 21:02:00 PST." <199511070502.AA28993@interlock.ans.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 07 Nov 1995 12:22:20 -0500 From: "Perry E. Metzger" Phil Karn writes: > With the trend toward personal workstations, one could make the exact > same argument about civilian computer systems. All of the computers I > directly use regularly each day, one at work and several at home, run > multitasking operating systems of various kinds but they are dedicated > to me. I think I can trust me not to hack myself. :-) One of the major users of security systems is going to be large corporations. In large corporate environments, the desktop machines tend to be personal, but servers tend to have lots of different users, and they tend to be the places where the data that most needs safeguarding resides. Perry From ipsec-request@ans.net Tue Nov 7 20:14:27 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12701 (5.65c/IDA-1.4.4 for ); Tue, 7 Nov 1995 15:23:35 -0500 Received: by interlock.ans.net id AA14619 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 7 Nov 1995 15:14:49 -0500 Message-Id: <199511072014.AA14619@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 7 Nov 1995 15:14:49 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 7 Nov 1995 15:14:49 -0500 From: gwz@geek.ocsg.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 7 Nov 1995 15:14:49 -0500 X-Mailer: exmh version 1.6.2 7/18/95 To: "Theodore Ts'o" Cc: ipsec@ans.net Subject: Re: photuris-06.txt In-Reply-To: Your message of "Wed, 01 Nov 1995 23:38:54 EST." <199511020439.AA20528@interlock.ans.net> Mime-Version: 1.0 Content-Type: application/pgp; format=mime; x-action=signclear; x-originator=80081029 Content-Transfer-Encoding: 7bit Date: Tue, 07 Nov 1995 12:14:27 -0800 -----BEGIN PGP SIGNED MESSAGE----- Content-Type: text/plain; charset=us-ascii ... > What you call "plain-old multi-user operating systems", by which I would > assume mean systems like Windows NT and ITS, I would merely call them > "single-user operating systems", or "insecure multi-user operating > systems". > Just a nit, but I don't believe that Windows NT can be reasonably cahracterized as a "multi-user" system, at least in the same sense as VAX/VMS on Unix. There are provisions in NT for multiple user IDs, but only one person can use the system at a time. > Any secure multi-user system worth its salt must be able to protect its > resources from hostile users, and protect one hostile user from being > able to damage the resources controlled by another hostile user. > > At the heart of this, I think we have a terminology problem; we can come > up with different terms, but we really should avoid the use of > Multi-Level Secure systems unless we mean a system which enforces > non-discrentional access control. There's no point in bucking 3 decades > worth of usage..... > > - Ted How true. ~ gwz Glen Zorn Senior Scientist Voice: 206-883-8721 gwz@cybersafe.com CyberSAFE Corporation FAX: 206-883-6951 Since I was forced to write it by the alien parasite which attached itself to my brain stem during my recent visit to an isolated area of Northern Arizona, it could hardly be construed that this message would reflect either the opinions or the policies of my employer. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMJ++GTUVUtyACBApAQG7RQP/dJ+dpX6yH6DohELYxA2I/f6u+/G5Xpiq fl+Pc5fDf3ClH/UIrsBBmCg6FCL2fsX4PVszWNrl7qyViSIksKKzzR0vW89Hc9pn D7EhztRVh7hkJ7BcR2y/o/6/+qZ5fzkeOe/fFRfdSfA0RWn7QPhnqatQQrL8GR9M SQju775c6uQ= =cAs2 -----END PGP SIGNATURE----- From ipsec-request@ans.net Tue Nov 7 13:41:59 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14697 (5.65c/IDA-1.4.4 for ); Tue, 7 Nov 1995 18:50:26 -0500 Received: by interlock.ans.net id AA20247 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 7 Nov 1995 18:43:14 -0500 Message-Id: <199511072343.AA20247@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 7 Nov 1995 18:43:14 -0500 From: smb@research.att.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 7 Nov 1995 18:43:14 -0500 To: ipsec@ans.net Subject: Re: Nodes and Users Date: Tue, 07 Nov 95 18:41:59 EST I sent this out a few days ago, but I was having some mailer troubles and it may not have made it. My apologies to any who have seen it twice. (And I apologize even more that I won't be able to reply to any comments for a few days; I'll be out of town and offline.) --- For the most part, I'm coming to the conclusion that Photuris per se is adequate (at least in this respect). The disagreements seem to be about naming, which doesn't surprise me, since as I've often said, I've never yet been in a naming discussion that was at all pleasant -- and most of the unpleasantness comes not just because everyone thinks they're right, but because everyone *is* right. I suspect that what's needed is yet another RFC, on Names. For now, the Photuris RFC should punt on that issue, and say only that all end systems SHOULD (or is it MUST?) support multiple local names, and that all Photuris negotiations MUST specify the names of both parties, and that the responder MUST reply using a name (and hence key) belonging to an entity at least as specific as was requested. The latter language is intended to support systems that bind a particular key to the random port number assigned this time, even though the initiator hasn't asked for that much specificity. Put another way, if the name space is lattice-structured, the responder can use any key that is less than or equal to the requested key. Another concrete example would be a response signed by root@foo.bar, when the initiator just asked for bar. Or maybe that whole question should be deferred to the naming RFC. Note that I'm *not* worried about syntax, I'm worried about semantics. The fact, for example, that IP address can be mapped into the DNS name space is monumentally uninteresting, because they're in a different tree than the the names, the mapping between the trees is unauthenticated, and users see names while kernels see addresses. Btw -- no, I'm not volunteering to write it; apart from the fact that my writing queue overfloweth, I'm quite certain I don't know the answer. --Steve Bellovin From ipsec-request@ans.net Wed Nov 8 01:42:19 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14691 (5.65c/IDA-1.4.4 for ); Tue, 7 Nov 1995 20:48:00 -0500 Received: by interlock.ans.net id AA22596 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 7 Nov 1995 20:42:27 -0500 Message-Id: <199511080142.AA22596@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 7 Nov 1995 20:42:27 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 7 Nov 1995 20:42:27 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 7 Nov 1995 20:42:27 -0500 Date: Tue, 7 Nov 1995 18:42:19 -0700 From: Hilarie Orman To: smb@research.att.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <199511072343.AA20247@interlock.ans.net> Subject: Re: Nodes and Users > all Photuris negotiations MUST specify the names of both parties, > and that the responder MUST reply using a name (and hence key) belonging > to an entity at least as specific as was requested. This seems like a good idea. I'm not entirely sure how to define name specificity, but I know what I like. From ipsec-request@ans.net Wed Nov 8 02:27:51 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA04290 (5.65c/IDA-1.4.4 for ); Tue, 7 Nov 1995 21:34:11 -0500 Received: by interlock.ans.net id AA23271 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 7 Nov 1995 21:28:00 -0500 Message-Id: <199511080228.AA23271@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 7 Nov 1995 21:28:00 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 7 Nov 1995 21:28:00 -0500 Date: Tue, 7 Nov 1995 18:27:51 -0800 (PST) From: Phil Karn To: markham@sctc.com Cc: tytso@MIT.EDU, ipsec@ans.net In-Reply-To: <199511071402.AA04466@interlock.ans.net> (message from Tom Markham on Tue, 7 Nov 1995 08:02:43 -0600) Subject: RE: photuris-06.txt Never having worked in a classified environment I have only minimal knowledge of the rules that apply there, and the threat models on which they're based. But it does seem that many of those threat models are far more concerned about "internal" attacks, i.e., attacks from users with enough authority to obtain some access to the system but who are not specifically authorized to access the data in question. Is this true? If so, I'd posit that in the commercial world this isn't as often the case. More often the problem is entirely external, i.e., keeping people out of a system who don't belong there at all. This is not to say that there are no internal threats, only that they're much more subtle and difficult to deal with because, unlike the military world, even the policies haven't been fully established. Since I am not concerned about the military world (they can take care of themselves) I am tempted to conclude that these issues are all beyond the immediate scope of the document for now. Phil From ipsec-request@ans.net Wed Nov 8 02:20:21 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17966 (5.65c/IDA-1.4.4 for ); Tue, 7 Nov 1995 22:05:50 -0500 Received: by interlock.ans.net id AA23763 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 7 Nov 1995 21:59:24 -0500 Message-Id: <199511080259.AA23763@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 7 Nov 1995 21:59:24 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 7 Nov 1995 21:59:24 -0500 Date: Tue, 7 Nov 1995 18:20:21 -0800 (PST) From: Phil Karn To: rgm3@is.chrysler.com Cc: tytso@MIT.EDU, bsimpson@morningstar.com, ipsec@ans.net In-Reply-To: <199511071322.AA03944@interlock.ans.net> (message from Robert Moskowitz on Tue, 07 Nov 1995 08:21:29 -0500) Subject: Re: photuris-06.txt >But that SPARC 2000 that has one of my key databases on that I need to >interact with? There is over 200Gb on that system now with 50 databases. >Even the production SPARCs have a handful of people allowed to do direct >logins for maintanance.... I guess I don't know enough about how big database machines are structured and used. Can ordinary users run arbitrary tasks on the database machine, or does it only run dedicated server software? Phil From ipsec-request@ans.net Wed Nov 8 03:28:49 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15447 (5.65c/IDA-1.4.4 for ); Tue, 7 Nov 1995 22:35:46 -0500 Received: by interlock.ans.net id AA24115 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 7 Nov 1995 22:29:26 -0500 Message-Id: <199511080329.AA24115@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 7 Nov 1995 22:29:26 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 7 Nov 1995 22:29:26 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 7 Nov 1995 22:29:26 -0500 Date: Tue, 7 Nov 1995 20:28:49 -0700 From: Hilarie Orman To: karn@qualcomm.com Cc: markham@sctc.com, ipsec@ans.net, tytso@MIT.EDU In-Reply-To: Yourmessage <199511080228.AA23271@interlock.ans.net> Subject: RE: photuris-06.txt > But it does seem that many of those threat models > are far more concerned about "internal" attacks, i.e., attacks from > users with enough authority to obtain some access to the system > but who are not specifically authorized to access the data in question. > Is this true? > If so, I'd posit that in the commercial world this isn't as often the > case. I think the military may have had the lead in defining a formal policy, but the problem is as old as commerce itself* --- you might hear about it as "embezzlement" or "rogue trading" or "white collar computer crime", but the internal problems cost companies more than the external ones, I'll bet. * E.g., Phoenician traders used to store tokens in sealed clay containers to be used as signed bills of lading, carried by sea captains to distant merchants. Does this mean Photuris should worry about it? Don't know, it's all Greek to me. From ipsec-request@ans.net Wed Nov 8 04:01:52 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12721 (5.65c/IDA-1.4.4 for ); Tue, 7 Nov 1995 23:08:28 -0500 Received: by interlock.ans.net id AA24529 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 7 Nov 1995 23:02:12 -0500 Message-Id: <199511080402.AA24529@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 7 Nov 1995 23:02:12 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 7 Nov 1995 23:02:12 -0500 Date: Tue, 7 Nov 1995 20:01:52 -0800 (PST) From: Phil Karn To: ho@cs.arizona.edu Cc: markham@sctc.com, ipsec@ans.net, tytso@MIT.EDU In-Reply-To: <9511080328.AA14194@uncial.CS.Arizona.EDU> (message from Hilarie Orman on Tue, 7 Nov 1995 20:28:49 -0700) Subject: RE: photuris-06.txt >I think the military may have had the lead in defining a formal >policy, but the problem is as old as commerce itself* --- you might >hear about it as "embezzlement" or "rogue trading" or "white collar >computer crime", but the internal problems cost companies more than >the external ones, I'll bet. I don't dispute this at all, I'm only saying that I'd prefer to punt on this issue at the moment in order to solve an existing problem that has a much clearer and simpler solution -- defense against external attacks. Phil From ipsec-request@ans.net Wed Nov 8 04:46:17 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17925 (5.65c/IDA-1.4.4 for ); Tue, 7 Nov 1995 23:49:04 -0500 Received: by interlock.ans.net id AA25131 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 7 Nov 1995 23:46:44 -0500 Message-Id: <199511080446.AA25131@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 7 Nov 1995 23:46:44 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 7 Nov 1995 23:46:44 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 7 Nov 1995 23:46:44 -0500 Date: Tue, 7 Nov 1995 23:46:17 -0500 From: Theodore Ts'o To: Phil Karn Cc: markham@sctc.com, ipsec@ans.net In-Reply-To: Phil Karn's message of Tue, 7 Nov 1995 18:27:51 -0800 (PST), <199511080227.SAA22694@servo.qualcomm.com> Subject: Re: photuris-06.txt Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 1024 Date: Tue, 7 Nov 1995 18:27:51 -0800 (PST) From: Phil Karn Since I am not concerned about the military world (they can take care of themselves) I am tempted to conclude that these issues are all beyond the immediate scope of the document for now. Yet the current wording which Bill is proposing says that Photoris only works on systems where the military-style mandatory access controls is present. Surely that's not correct! However, presumably we are still worried about the case where you have two mutually suspicious users on the same host --- which means you should avoid per-host keying to avoid the attacks which Steve Bellovin talked about at Danvers (I think) IETF meeting. Are we agreed this is something we want to worry about? I think we should, since avoiding it seems relatively easy. I just want to make sure that we are all agreed on the general goals and scope of Photoris; if so, then we can work on the wording which states our common understanding. - Ted From ipsec-request@ans.net Wed Nov 8 05:15:56 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA04219 (5.65c/IDA-1.4.4 for ); Wed, 8 Nov 1995 00:22:29 -0500 Received: by interlock.ans.net id AA25700 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 8 Nov 1995 00:16:05 -0500 Message-Id: <199511080516.AA25700@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 8 Nov 1995 00:16:05 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Nov 1995 00:16:05 -0500 Date: Tue, 7 Nov 1995 21:15:56 -0800 (PST) From: Phil Karn To: tytso@MIT.EDU Cc: markham@sctc.com, ipsec@ans.net In-Reply-To: <9511080446.AA10825@dcl.MIT.EDU> (tytso@MIT.EDU) Subject: Re: photuris-06.txt >Yet the current wording which Bill is proposing says that Photoris only >works on systems where the military-style mandatory access controls is >present. Surely that's not correct! Didn't he say that was a typo? I *do not* oppose attempts to enhance Photuris to protect mutually suspicious users from each other. I just don't want those attempts to slow down the deployment of the basic system, which was conceived only with external threats in mind. Phil From ipsec-request@ans.net Wed Nov 8 12:44:29 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17938 (5.65c/IDA-1.4.4 for ); Wed, 8 Nov 1995 07:53:04 -0500 Received: by interlock.ans.net id AA29401 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 8 Nov 1995 07:45:27 -0500 Message-Id: <199511081245.AA29401@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 8 Nov 1995 07:45:27 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 8 Nov 1995 07:45:27 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 8 Nov 1995 07:45:27 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Nov 1995 07:45:27 -0500 X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 08 Nov 1995 07:44:29 -0500 To: Phil Karn From: Robert Moskowitz Subject: Re: photuris-06.txt Cc: tytso@MIT.EDU, bsimpson@morningstar.com, ipsec@ans.net At 06:20 PM 11/7/95 -0800, Phil Karn wrote: >>But that SPARC 2000 that has one of my key databases on that I need to >>interact with? There is over 200Gb on that system now with 50 databases. >>Even the production SPARCs have a handful of people allowed to do direct >>logins for maintanance.... > >I guess I don't know enough about how big database machines are structured and >used. Can ordinary users run arbitrary tasks on the database machine, or >does it only run dedicated server software? In theory, the user can only submit requests to the database engine on the designated port. In practice, there needs to be lots of support IDs on these systems: UNIX maint, SQL engine maint, Data maint. So Telnet and RLOGIN sessions are fairly common. Then there is automated data movement. Traditionally done by scripted FTPs, commonly from MVS batch jobs. We are beginning to see replication services, but I have not ripped any of them apart to study their comm mechinisms. Finally, there has been no code review of these SQL engines to determine if they leave the hosts open to any attacks, ala the CERN HTTPD >4096 URL attack. Robert Moskowitz Chrysler Corporation (810) 758-8212 From ipsec-request@ans.net Wed Nov 8 12:44:30 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15377 (5.65c/IDA-1.4.4 for ); Wed, 8 Nov 1995 07:53:04 -0500 Received: by interlock.ans.net id AA29405 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 8 Nov 1995 07:45:28 -0500 Message-Id: <199511081245.AA29405@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 8 Nov 1995 07:45:28 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 8 Nov 1995 07:45:28 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 8 Nov 1995 07:45:28 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Nov 1995 07:45:28 -0500 X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 08 Nov 1995 07:44:30 -0500 To: Phil Karn , tytso@MIT.EDU From: Robert Moskowitz Subject: Re: photuris-06.txt Cc: markham@sctc.com, ipsec@ans.net At 09:15 PM 11/7/95 -0800, Phil Karn wrote: >>Yet the current wording which Bill is proposing says that Photoris only >>works on systems where the military-style mandatory access controls is >>present. Surely that's not correct! > >Didn't he say that was a typo? > >I *do not* oppose attempts to enhance Photuris to protect mutually >suspicious users from each other. I just don't want those attempts to >slow down the deployment of the basic system, which was conceived only >with external threats in mind. This is thought provoking. As the lead technical person in the automotive industry action group's (AIAG) network design effort, I am faced with creating a virtual network for 'mutually suspicious users'. Our trust models are quite screwy. A FORD division won the contract to design a Chrysler instrument panel. The FORD MIS people have SU privleges on those design systems. They have to be indirectly trusted not to move those designs to the FORD people that design instrument panels for competing FORD products. Basically, incestuous trust. Bud and Dana might be design partners on a welding system for GM and competing furiously for the same business at Mazda. And they want we to define the security protocols and methodologies for this network! ARGH!!!! 'mutually suspicious users' is a GOOD definition for the "extended enterprise". Robert Moskowitz Chrysler Corporation (810) 758-8212 From ipsec-request@ans.net Wed Nov 8 12:44:29 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14598 (5.65c/IDA-1.4.4 for ); Wed, 8 Nov 1995 09:40:04 -0500 Message-Id: <199511081440.AA14598@ftp.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@ftp.ans.net); Wed, 8 Nov 1995 09:35:05 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 8 Nov 1995 09:35:05 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 8 Nov 1995 09:35:05 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 8 Nov 1995 09:35:05 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Nov 1995 09:35:05 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Wed, 8 Nov 1995 09:35:05 -0500 X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 08 Nov 1995 07:44:29 -0500 To: Phil Karn From: Robert Moskowitz Subject: Re: photuris-06.txt Cc: tytso@MIT.EDU, bsimpson@morningstar.com, ipsec@ans.net At 06:20 PM 11/7/95 -0800, Phil Karn wrote: >>But that SPARC 2000 that has one of my key databases on that I need to >>interact with? There is over 200Gb on that system now with 50 databases. >>Even the production SPARCs have a handful of people allowed to do direct >>logins for maintanance.... > >I guess I don't know enough about how big database machines are structured and >used. Can ordinary users run arbitrary tasks on the database machine, or >does it only run dedicated server software? In theory, the user can only submit requests to the database engine on the designated port. In practice, there needs to be lots of support IDs on these systems: UNIX maint, SQL engine maint, Data maint. So Telnet and RLOGIN sessions are fairly common. Then there is automated data movement. Traditionally done by scripted FTPs, commonly from MVS batch jobs. We are beginning to see replication services, but I have not ripped any of them apart to study their comm mechinisms. Finally, there has been no code review of these SQL engines to determine if they leave the hosts open to any attacks, ala the CERN HTTPD >4096 URL attack. Robert Moskowitz Chrysler Corporation (810) 758-8212 From ipsec-request@ans.net Wed Nov 8 14:00:22 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA04177 (5.65c/IDA-1.4.4 for ); Wed, 8 Nov 1995 10:07:22 -0500 Received: by interlock.ans.net id AA01137 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 8 Nov 1995 09:55:52 -0500 Message-Id: <199511081455.AA01137@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 8 Nov 1995 09:55:52 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 8 Nov 1995 09:55:52 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 8 Nov 1995 09:55:52 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 8 Nov 1995 09:55:52 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Nov 1995 09:55:52 -0500 Date: Wed, 8 Nov 1995 08:00:22 -0600 From: Tom Markham To: karn@qualcomm.com Cc: ipsec@ans.net, rgm3@is.chrysler.com Subject: RE: photuris-06.txt >I *do not* oppose attempts to enhance Photuris to protect mutually >suspicious users from each other. I just don't want those attempts to >slow down the deployment of the basic system, which was conceived only >with external threats in mind. I think we are in agreement. 1. We want to get Photuris into the field as soon as possible to protect sites from well known external threats. 2. We want to make it easy to add support for 'mutually suspicious users' after we get some experience with the base Photuris. I do not intend to delay achieving step 1, I just want to make sure we can meet the needs of customers who require support for 'mutually suspicious users'. Tom Markham From ipsec-request@ans.net Wed Nov 8 12:44:30 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18003 (5.65c/IDA-1.4.4 for ); Wed, 8 Nov 1995 10:07:23 -0500 Message-Id: <199511081507.AA18003@ftp.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@ftp.ans.net); Wed, 8 Nov 1995 10:05:11 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 8 Nov 1995 10:05:11 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 8 Nov 1995 10:05:11 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 8 Nov 1995 10:05:11 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Nov 1995 10:05:11 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Wed, 8 Nov 1995 10:05:11 -0500 X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 08 Nov 1995 07:44:30 -0500 To: Phil Karn , tytso@MIT.EDU From: Robert Moskowitz Subject: Re: photuris-06.txt Cc: markham@sctc.com, ipsec@ans.net At 09:15 PM 11/7/95 -0800, Phil Karn wrote: >>Yet the current wording which Bill is proposing says that Photoris only >>works on systems where the military-style mandatory access controls is >>present. Surely that's not correct! > >Didn't he say that was a typo? > >I *do not* oppose attempts to enhance Photuris to protect mutually >suspicious users from each other. I just don't want those attempts to >slow down the deployment of the basic system, which was conceived only >with external threats in mind. This is thought provoking. As the lead technical person in the automotive industry action group's (AIAG) network design effort, I am faced with creating a virtual network for 'mutually suspicious users'. Our trust models are quite screwy. A FORD division won the contract to design a Chrysler instrument panel. The FORD MIS people have SU privleges on those design systems. They have to be indirectly trusted not to move those designs to the FORD people that design instrument panels for competing FORD products. Basically, incestuous trust. Bud and Dana might be design partners on a welding system for GM and competing furiously for the same business at Mazda. And they want we to define the security protocols and methodologies for this network! ARGH!!!! 'mutually suspicious users' is a GOOD definition for the "extended enterprise". Robert Moskowitz Chrysler Corporation (810) 758-8212 From ipsec-request@ans.net Wed Nov 8 11:06:55 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA04275 (5.65c/IDA-1.4.4 for ); Wed, 8 Nov 1995 16:18:01 -0500 Received: by interlock.ans.net id AA11034 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 8 Nov 1995 16:07:02 -0500 Message-Id: <199511082107.AA11034@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 8 Nov 1995 16:07:02 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Nov 1995 16:07:02 -0500 Date: Wed, 8 Nov 95 16:06:55 EST From: mjo@tycho.ncsc.mil (Michael J. Oehler) To: ipsec-dev@eit.com Subject: Re: Interop Cc: ipsec@ans.net At the San Jose IPSEC WG meeting, the group discussed having an ESP/AH bake off at the Dallas IETF. Although I do not think this will occur in the official sense, I would like to know if anyone is interested in bringing their design to Dallas. We could try two tests. We could connect some laptops together. We could also connect them in the terminal and communicate with our respective test sites. It can be argued that manual keying is trivial, but I believe that this demonstration is still needed. I am sure the tests will be much more complicated than I describe too. We plan to demonstrate our ESP/AH prototype at Dallas and would prefer to test with others. To do this, I would want to test with you before then. If you are interested in arranging some tests, please contact me. I have included this message to ipsec mailing list for those who may be interested in seeing the demonstrations. I expect them to be informative and not very colorful. I also expect most queries from the developer's list. Regards -Mike Oehler From ipsec-request@ans.net Thu Nov 9 04:17:05 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18201 (5.65c/IDA-1.4.4 for ); Wed, 8 Nov 1995 23:24:42 -0500 Received: by interlock.ans.net id AA21876 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 8 Nov 1995 23:17:10 -0500 Message-Id: <199511090417.AA21876@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 8 Nov 1995 23:17:10 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Nov 1995 23:17:10 -0500 Date: Wed, 8 Nov 1995 20:17:05 -0800 (PST) From: Phil Karn To: mjo@tycho.ncsc.mil Cc: ipsec-dev@eit.COM, ipsec@ans.net In-Reply-To: <9511082106.AA17402@tarius.tycho.ncsc.mil> (mjo@tycho.ncsc.mil) Subject: Re: Interop I plan to have my ESP/AH implementation in hand at Dallas, so I'd like to participate. It's part of my KA9Q NOS implementation that runs under DOS, so we can run it on my laptop. Phil From ipsec-request@ans.net Thu Nov 9 12:30:43 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18259 (5.65c/IDA-1.4.4 for ); Thu, 9 Nov 1995 07:39:25 -0500 Received: by interlock.ans.net id AA27310 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 9 Nov 1995 07:31:53 -0500 Message-Id: <199511091231.AA27310@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 9 Nov 1995 07:31:53 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 9 Nov 1995 07:31:53 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 9 Nov 1995 07:31:53 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 9 Nov 1995 07:31:53 -0500 X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 09 Nov 1995 07:30:43 -0500 To: "William Allen Simpson" , ipsec@ans.net From: Robert Moskowitz Subject: Re: scenario: Authenticated Firewall Traversal At 07:49 AM 11/2/95 -0500, Robert Moskowitz wrote: >At 02:10 PM 10/25/95 GMT, William Allen Simpson wrote: >>An administrator has one or more networks, and a number of mobile users. >>It is desirable to restrict access to authorized external users. The >>boundary router is 3.0.0.3. >> >>Each user adds commands to tunnel and authenticate. >> >> route addp 3.0.0.0/8 tunnel 3.0.0.3 >> secure 3.0.0.3 authenticate-only >> >I want to walk through this example a lot slower with some 'real world' >flavor to it. > >First off, the external reachable address is not on the same network as the >internal stuff (firewall is a CIDR block, internal is a registered B and >some 1597 nets). So: > We did a 'walk' through on this yesterday and came up with the following methodology: Couple the access server with NAT functionality. The DNS question will require testing, but I hope that listing the internal DNS first is the way to go. Robert Moskowitz Chrysler Corporation (810) 758-8212 From ipsec-request@ans.net Thu Nov 9 12:30:43 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18005 (5.65c/IDA-1.4.4 for ); Thu, 9 Nov 1995 07:39:25 -0500 Received: by interlock.ans.net id AA27306 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 9 Nov 1995 07:31:51 -0500 Message-Id: <199511091231.AA27306@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 9 Nov 1995 07:31:51 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 9 Nov 1995 07:31:51 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 9 Nov 1995 07:31:51 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 9 Nov 1995 07:31:51 -0500 X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 09 Nov 1995 07:30:43 -0500 To: mjo@tycho.ncsc.mil (Michael J. Oehler), ipsec-dev@eit.com From: Robert Moskowitz Subject: Re: Interop Cc: ipsec@ans.net At 04:06 PM 11/8/95 EST, Michael J. Oehler wrote: > >I have included this message to ipsec mailing list for those who may be interested >in seeing the demonstrations. I expect them to be informative and not very colorful. >I also expect most queries from the developer's list. I want to see the demonstrations. Please inform the list as to the when and where. Robert Moskowitz Chrysler Corporation (810) 758-8212 From ipsec-request@ans.net Thu Nov 9 09:37:07 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18342 (5.65c/IDA-1.4.4 for ); Thu, 9 Nov 1995 14:52:28 -0500 Received: by interlock.ans.net id AA07569 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 9 Nov 1995 14:37:15 -0500 Message-Id: <199511091937.AA07569@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 9 Nov 1995 14:37:15 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 9 Nov 1995 14:37:15 -0500 Date: Thu, 9 Nov 95 14:37:07 EST From: atkinson@itd.nrl.navy.mil (Ran Atkinson) To: ipsec@ans.net Subject: naming and terminology Folks, As co-chair, my understanding of consensus is roughly what Ted T'so described -- namely the "mutually suspicious users" problem is one that MUST be addressed in pass 1. I do NOT think this is hard to do -- if one simply supports PGP keys (which name users not systems) in Photuris and has the ability to pass the name string between the two parties to the Photuris exchange the basic requirement is met. I believe there is consensus that support for this MUST be implemented on multi-user systems. Bill and Phil, you should take this as WG chair direction to edit your document accordingly so that the document conforms with WG consensus. Secondly, Bill Simpson is flat out wrong in the way he is using "mandatory access control", "multi-level secure", and similar terms. The revised note from Ted T'so is correct in use of language. Phrasing such as "multi-user systems having discretionary access controls" is OK and technically correct. Phrasing such as "secure multi-user systems" or "multi-level secure multi-user systems" or "MLS systems" is not correct. Bill Simpson has telephoned me to talk about this recently. Perhaps I've educated him on this matter of language (not sure), but I'm not sure. Again, the chair directs that the language of the draft conform to standard usage in this area and that we defer the MLS cases for the base draft for the present. Having MLS things in the extensions draft is fine and reasonable for the present. Phil is being reasonable in trying to avoid MLS-specific issues at the moment. I disagree strongly with Phil that the commercial sector doesn't care about the "mutually suspicious users" problem on their mainstream OSs (e.g. VMS, UNIX, MPE). The "mutually suspicious users" problem is COMMON in the commercial sector. It was absolutely an issue when I worked in commercial real-time controls for a GE subsidiary in the past, to give a concrete example. Bob Moscowitz has kindly provided another example of real systems having mutually suspicious users. This is really a COMMERCIAL problem, not a military unique problem and needs to be addressed on the first pass. Ran rja@cs.nrl.navy.mil PS 1: For those of you who aren't familiar with the conventional language in the computer security/network security world, here are some simplified term definitions (better definitions are available elsewhere): Multi-level Secure (MLS): Describes a system (e.g. computer, router) that is trusted to keep users and objects at different sensitivity levels (e.g. Unclassified, Secret) separate where it is believed the system is not subvertible by any unprivileged process or user. These are typically used in military environments. Discretionary Access Controls (DAC): Access controls on an object (e.g. file) that are at the discretion of the owner of that object (e.g. file). This includes MOST commercial operating systems. DOS and Windows and MacOS are examples of systems that lack DAC. Mandatory Access Controls: Access controls on an object that are NOT at the discretion of the owner of that object. For example, on an MLS system no user can give an "unclassified" user access to a "Top Secret" file, even if the user owns the file in question. PS2: Each of the IPsec chairs are (separately and purely by coincidence) in the process of changing jobs just now. This means that our electronic presence is not entirely dependable temporarily. New email addresses will be posted to the list once we have them working. Mail to the old email addresses might or might not work. From ipsec-request@ans.net Thu Nov 9 21:50:56 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12768 (5.65c/IDA-1.4.4 for ); Thu, 9 Nov 1995 16:59:09 -0500 Received: by interlock.ans.net id AA11535 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 9 Nov 1995 16:50:47 -0500 Message-Id: <199511092150.AA11535@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 9 Nov 1995 16:50:47 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 9 Nov 1995 16:50:47 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 9 Nov 1995 16:50:47 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 9 Nov 1995 16:50:47 -0500 From: markson@osmosys.incog.com (Tom Markson) Subject: SKIP: Interoperability proposal To: ipsec@ans.net Date: Thu, 9 Nov 1995 13:50:56 -0800 (PST) Cc: markson@osmosys.incog.com (Tom Markson) X-Mailer: ELM [version 2.4 PL24 PGP5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, Some notes for SKIP interoperability testing at Dallas IETF. Here's what I propose for SKIP interoperability testing. Comments are welcome. Interoperability will be SKIP as described in the "04" draft. Algorithm discovery will not be tested. All implementations will support the ESP protocol under IPv4. Testing will be of encapsulation mode (Next Header=IP in the ESP header) Public Keys will be distributed as hashed public keys either through the certificate discovery protocol, or with files. Implementations will therefore implement NSID 8. In the worst case, manual kij keying is also acceptable. Interopability will be with DES for key encryption and DES-CBC (RFC 1829) for traffic encryption. If time permits, we can also test Triple DES (RFC1851). RC4 (or RC3.9) can also be used. The transform will be as described in Germano Caronni's mail to ipsec. The traffic encryption algorithm for RC4 will be transform 251. Since 250-255 are only for local use, this is compliant with the draft. Simplecrypt (for rudimentary protocol testing) will be transform 252. Again, comments are welcome. --tom From ipsec-request@ans.net Sun Nov 10 01:24:08 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14707 (5.65c/IDA-1.4.4 for ); Thu, 9 Nov 1995 23:32:33 -0500 Received: by interlock.ans.net id AA18620 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 9 Nov 1995 23:26:17 -0500 Message-Id: <199511100426.AA18620@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 9 Nov 1995 23:26:17 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 9 Nov 1995 23:26:17 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 9 Nov 1995 23:26:17 -0500 Date: 09 Nov 95 17:24:08 -0800 From: "PALAMBER.US.ORACLE.COM" To: ipsec@ans.net Subject: New Job Mime-Version: 1.0 After fifteen years at Motorola I have a new position with Oracle in Redwood City California. Please note my new address and kindly excuse any dropped correspondence over the last month. Regards, 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 -------------------------------------------------------------- From ipsec-request@ans.net Fri Nov 10 14:16:53 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA16582 (5.65c/IDA-1.4.4 for ); Fri, 10 Nov 1995 09:29:34 -0500 Received: by interlock.ans.net id AA26714 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 10 Nov 1995 09:18:18 -0500 Message-Id: <199511101418.AA26714@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 10 Nov 1995 09:18:18 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 10 Nov 1995 09:18:18 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: markson@osmosys.incog.com (Tom Markson) Cc: ipsec@ans.net Subject: Re: SKIP: Interoperability proposal In-Reply-To: Your message of "Thu, 09 Nov 1995 13:50:56 PST." <199511100249.VAA03693@geech.gnu.ai.mit.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 10 Nov 1995 09:16:53 -0500 From: "Perry E. Metzger" This message brings to mind something I've been meaning to ask for some time. Could the SKIP people perhaps get their own mailing list? Your work isn't mainstream ipsec or key management any more, so perhaps you guys could branch off your discussions? The fact that you are setting up your own working group probably means that would be good form anyway. Tom Markson writes: > Some notes for SKIP interoperability testing at Dallas IETF. Here's what > I propose for SKIP interoperability testing. Comments are welcome. From ipsec-request@ans.net Thu Nov 9 13:42:51 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18276 (5.65c/IDA-1.4.4 for ); Fri, 10 Nov 1995 10:55:55 -0500 Received: by interlock.ans.net id AA28670 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 10 Nov 1995 10:43:45 -0500 Message-Id: <199511101543.AA28670@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Fri, 10 Nov 1995 10:43:45 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 10 Nov 1995 10:43:45 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 10 Nov 1995 10:43:45 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 10 Nov 1995 10:43:45 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 10 Nov 1995 10:43:45 -0500 Date: Thu, 9 Nov 1995 14:42:51 +0100 Errors-To: caronni@tik.ee.ethz.ch Reply-To: skip-info@tik.ee.ethz.ch Originator: skip-info@tik.ee.ethz.ch Sender: cschneid@amiga.icu.net.ch Precedence: bulk From: "Christian Schneider" To: schneide@tik.ee.ethz.ch Subject: Re: comments on draft 03 of SKIP X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: text Content-Length: 1438 A comment on draft-ietf-ipsec-skip-04.txt concerning 1.3.1 Zero Message Master key Update with Diffie-Hellman: Why not remove this and use the scheme described in 1.3.2 (hashing Kij with n) for Diffie-Hellman generated keys as well? THIS WOULD BE HIGHLY DESIRABLE! We started implementing draft 04 and ran into the following problem: There is large number computation involved in generating Kijn for 1.3.1 and there are (mainly) two ways to do it: - Calc Kijn as you need it (which means 1. the key is not ready when you need it, no packet transmission is possible until the computation is finished and 2. (_even worse_) you can't rely on having Kij(n-1) to get Kijn which may force you to exponentiate. - Keep all entries up-to-date, i.e. calc Kij(n+1) _every hour for every entry you have_. Certainly better but still pretty stupid IMHO. You even could see a possible problem with a denial-of-service attack if doing 1.3.1 since more (and as far as I can see unneccessary) large number computation has to be done on a SKIP-host. Always using the hashing mode to get Kijn would eliminate all troubles and I don't see any security problem with this. I think all current and future implementors would agree with me that the removal of 1.3.1 is an improvement to SKIP :-) - Chris -- Chris Schneider - cschneid@amiga.icu.net.ch BIX: hschneider IRC: cschneid Computers are not intelligent. They only think they are. From ipsec-request@ans.net Fri Nov 10 14:16:53 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13627 (5.65c/IDA-1.4.4 for ); Fri, 10 Nov 1995 12:24:03 -0500 Message-Id: <199511101724.AA13627@ftp.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@ftp.ans.net); Fri, 10 Nov 1995 12:18:49 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 10 Nov 1995 12:18:49 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 10 Nov 1995 12:18:49 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Fri, 10 Nov 1995 12:18:49 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: markson@osmosys.incog.com (Tom Markson) Cc: ipsec@ans.net Subject: Re: SKIP: Interoperability proposal In-Reply-To: Your message of "Thu, 09 Nov 1995 13:50:56 PST." <199511100249.VAA03693@geech.gnu.ai.mit.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 10 Nov 1995 09:16:53 -0500 From: "Perry E. Metzger" This message brings to mind something I've been meaning to ask for some time. Could the SKIP people perhaps get their own mailing list? Your work isn't mainstream ipsec or key management any more, so perhaps you guys could branch off your discussions? The fact that you are setting up your own working group probably means that would be good form anyway. Tom Markson writes: > Some notes for SKIP interoperability testing at Dallas IETF. Here's what > I propose for SKIP interoperability testing. Comments are welcome. From ipsec-request@ans.net Thu Nov 9 13:42:51 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA16493 (5.65c/IDA-1.4.4 for ); Fri, 10 Nov 1995 12:59:24 -0500 Message-Id: <199511101759.AA16493@ftp.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@ftp.ans.net); Fri, 10 Nov 1995 12:54:15 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Fri, 10 Nov 1995 12:54:15 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 10 Nov 1995 12:54:15 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 10 Nov 1995 12:54:15 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 10 Nov 1995 12:54:15 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 10 Nov 1995 12:54:15 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Fri, 10 Nov 1995 12:54:15 -0500 Date: Thu, 9 Nov 1995 14:42:51 +0100 Errors-To: caronni@tik.ee.ethz.ch Reply-To: skip-info@tik.ee.ethz.ch Originator: skip-info@tik.ee.ethz.ch Sender: cschneid@amiga.icu.net.ch Precedence: bulk From: "Christian Schneider" To: schneide@tik.ee.ethz.ch Subject: Re: comments on draft 03 of SKIP X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas Content-Type: text Content-Length: 1438 A comment on draft-ietf-ipsec-skip-04.txt concerning 1.3.1 Zero Message Master key Update with Diffie-Hellman: Why not remove this and use the scheme described in 1.3.2 (hashing Kij with n) for Diffie-Hellman generated keys as well? THIS WOULD BE HIGHLY DESIRABLE! We started implementing draft 04 and ran into the following problem: There is large number computation involved in generating Kijn for 1.3.1 and there are (mainly) two ways to do it: - Calc Kijn as you need it (which means 1. the key is not ready when you need it, no packet transmission is possible until the computation is finished and 2. (_even worse_) you can't rely on having Kij(n-1) to get Kijn which may force you to exponentiate. - Keep all entries up-to-date, i.e. calc Kij(n+1) _every hour for every entry you have_. Certainly better but still pretty stupid IMHO. You even could see a possible problem with a denial-of-service attack if doing 1.3.1 since more (and as far as I can see unneccessary) large number computation has to be done on a SKIP-host. Always using the hashing mode to get Kijn would eliminate all troubles and I don't see any security problem with this. I think all current and future implementors would agree with me that the removal of 1.3.1 is an improvement to SKIP :-) - Chris -- Chris Schneider - cschneid@amiga.icu.net.ch BIX: hschneider IRC: cschneid Computers are not intelligent. They only think they are. From ipsec-request@ans.net Fri Nov 10 18:14:03 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18369 (5.65c/IDA-1.4.4 for ); Fri, 10 Nov 1995 13:22:37 -0500 Received: by interlock.ans.net id AA02865 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 10 Nov 1995 13:15:26 -0500 Message-Id: <199511101815.AA02865@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 10 Nov 1995 13:15:26 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 10 Nov 1995 13:15:26 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 10 Nov 1995 13:15:26 -0500 Date: Fri, 10 Nov 1995 11:14:03 -0700 From: Hilarie Orman To: perry@piermont.com Cc: markson@osmosys.incog.com, ipsec@ans.net In-Reply-To: Yourmessage <199511101757.AA14946@optima.cs.arizona.edu> Subject: Re: SKIP: Interoperability proposal The SKIP work seems as mainstream ipsec as anything else. I hope they continue to include the ipsec mailing list in their discussions. From ipsec-request@ans.net Fri Nov 10 18:24:52 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18908 (5.65c/IDA-1.4.4 for ); Fri, 10 Nov 1995 13:34:12 -0500 Received: by interlock.ans.net id AA03210 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 10 Nov 1995 13:26:36 -0500 Message-Id: <199511101826.AA03210@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 10 Nov 1995 13:26:36 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 10 Nov 1995 13:26:36 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: Hilarie Orman Cc: markson@osmosys.incog.com, ipsec@ans.net Subject: Re: SKIP: Interoperability proposal In-Reply-To: Your message of "Fri, 10 Nov 1995 11:14:03 MST." <9511101814.AA31163@uncial.CS.Arizona.EDU> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 10 Nov 1995 13:24:52 -0500 From: "Perry E. Metzger" Hilarie Orman writes: > The SKIP work seems as mainstream ipsec as anything else. Its largely to completely incompatible. Given that, I'd say it isn't IPSEC. > I hope they continue to include the ipsec mailing list in their > discussions. I don't want to see them stopping their discussions, but I don't see why they can't be conducted elsewhere. Those that want to monitor them are free to. Perry From ipsec-request@ans.net Fri Nov 10 18:38:40 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18301 (5.65c/IDA-1.4.4 for ); Fri, 10 Nov 1995 15:00:27 -0500 Received: by interlock.ans.net id AA05644 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 10 Nov 1995 14:53:15 -0500 Message-Id: <199511101953.AA05644@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 10 Nov 1995 14:53:15 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 10 Nov 1995 14:53:15 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 10 Nov 1995 14:53:15 -0500 Date: 10 Nov 95 10:38:40 -0800 From: "PALAMBER.US.ORACLE.COM" To: perry@piermont.com Subject: Re: SKIP: Interoperability proposal Cc: ipsec@ans.net X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:perry@piermont.com's message of 10-Nov-95 14:24 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Boundary-1548447-0-0 --Boundary-1548447-0-0 Perry, SKIP is part of IPSEC. The SKIP implementors and editor are working hard at making SKIP compatable with AH/ESP. It does represent an alternative to the original working group concept of only supporting an application layer key management protocol. I must complement the individuals working on SKIP for their thoughful contributions, organized development, and responsiveness to editorial comments. SKIP is not the "best" technical solution in terms of meeting the IPSEC requirements. They are making considerable progress because they are "easy" to work with as a development and editing team. There is a lesson to be learned here ... Regards, Paul --Boundary-1548447-0-0 Content-Type: message/rfc822 Date: 10 Nov 95 13:24:52 From:"Perry E. Metzger" To: Hilarie,Orman,ho@cs.arizona.edu Subject: Re: SKIP: Interoperability proposal Cc: markson@osmosys.incog.com,ipsec@ans.net Reply-to: perry@piermont.com X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol X-Orcl-Application: In-Reply-To: Your message of "Fri, 10 Nov 1995 11:14:03 MST." X-Orcl-Application: In-Reply-To: <9511101814.AA31163@uncial.CS.Arizona.EDU> X-Reposting-Policy: redistribute only with permission Hilarie Orman writes: > The SKIP work seems as mainstream ipsec as anything else. Its largely to completely incompatible. Given that, I'd say it isn't IPSEC. > I hope they continue to include the ipsec mailing list in their > discussions. I don't want to see them stopping their discussions, but I don't see why they can't be conducted elsewhere. Those that want to monitor them are free to. Perry --Boundary-1548447-0-0-- From ipsec-request@ans.net Fri Nov 10 22:54:22 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14646 (5.65c/IDA-1.4.4 for ); Fri, 10 Nov 1995 18:00:51 -0500 Received: by interlock.ans.net id AA09953 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 10 Nov 1995 17:54:34 -0500 Message-Id: <199511102254.AA09953@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 10 Nov 1995 17:54:34 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 10 Nov 1995 17:54:34 -0500 From: Germano Caronni Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 10 Nov 1995 17:54:34 -0500 Subject: Re: SKIP: Interoperability proposal To: perry@piermont.com Date: Fri, 10 Nov 1995 23:54:22 +0100 (MET) Cc: markson@osmosys.incog.com, ipsec@ans.net In-Reply-To: <199511101959.UAA05668@ktik0> from "Perry E. Metzger" at Nov 10, 95 09:16:53 am X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Content-Length: 918 Perry E. Metzger wrote: > This message brings to mind something I've been meaning to ask for > some time. Could the SKIP people perhaps get their own mailing list? [...] Hello Perry, the 'SKIP people' certainly have their own mailing list. On it we discuss things that usually do not interest the wider IPSEC forum like how we do padding in non-ESP, what performance we achieve, problems with the imple- mentations and similar stuff. Once or twice we even announced a new SKIP release on it. In my opinion, the fact that we will try interoperability at the next IETF might indeed be of more general interest, as were the comments to the various draft-ietf-ipsec-skip versions, and some other security relevant issues that have been rised. Friendly greetings, Germano Caronni P.S.: IMHO SKIP is quite close to mainstream IPSEC, and no alternate WG is being formed. I might be wrong on this, but I doubt it. From ipsec-request@ans.net Fri Nov 10 23:18:36 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14718 (5.65c/IDA-1.4.4 for ); Fri, 10 Nov 1995 18:25:14 -0500 Received: by interlock.ans.net id AA10563 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 10 Nov 1995 18:18:46 -0500 Message-Id: <199511102318.AA10563@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 10 Nov 1995 18:18:46 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 10 Nov 1995 18:18:46 -0500 From: Germano Caronni Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 10 Nov 1995 18:18:46 -0500 Subject: Re: SKIP: Interoperability proposal To: perry@piermont.com Date: Sat, 11 Nov 1995 00:18:36 +0100 (MET) Cc: ho@cs.arizona.edu, markson@osmosys.incog.com, ipsec@ans.net In-Reply-To: <199511101826.AA03210@interlock.ans.net> from "Perry E. Metzger" at Nov 10, 95 01:24:52 pm X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Content-Length: 424 Perry E. Metzger wrote: > Hilarie Orman writes: > > The SKIP work seems as mainstream ipsec as anything else. > Its largely to completely incompatible. Given that, I'd say it isn't > IPSEC. Perry, I strongly disagree with you. skip-04 bases itself heavily on RFC1825, and is firmly coupled with both 1826 and 1827, making 1828 and 1829 mandatory to implement. This looks quite like being in the line of IPSEC. Germano From ipsec-request@ans.net Fri Nov 10 18:36:49 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18092 (5.65c/IDA-1.4.4 for ); Fri, 10 Nov 1995 18:36:49 -0500 Received: by interlock.ans.net id AA10804 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 10 Nov 1995 18:31:23 -0500 Message-Id: <199511102331.AA10804@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 10 Nov 1995 18:31:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 10 Nov 1995 18:31:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 10 Nov 1995 18:31:23 -0500 Date: Fri, 10 Nov 95 13:19:23 From: "Housley, Russ" Encoding: 1451 Text To: schneide@tik.ee.ethz.ch, ipsec@ans.net Subject: Re: comments on draft 03 of SKIP Chris wrote: > We started implementing draft 04 and ran into the following problem: > There is large number computation involved in generating Kijn for 1.3.1 and > there are (mainly) two ways to do it: > - Calc Kijn as you need it (which means 1. the key is not ready when you need > it, no packet transmission is possible until the computation is finished > and 2. (_even worse_) you can't rely on having Kij(n-1) to get Kijn which > may force you to exponentiate. > - Keep all entries up-to-date, i.e. calc Kij(n+1) _every hour for every > entry you have_. Certainly better but still pretty stupid IMHO. The ANSI X9.F.1 committe is looking at a variant of Diffie-Hellman that may help. The shared secret is computed in the normal way. I guess SKIP calls that Kij. The ANSI X9.F.1 variant hashes the shared secret with randoms that are provided by each party and a counter. Each value of the counter yields a different traffic key. To support e-mail, a constant is used instead of a random for the recipient. For SKIP, constants could be used for both parties or they could be omitted. The idea of hashing Kij concatenated with a counter should be more efficient than the multiply associated with the current Kijn. Also, with the hash-based scheme you do not need Kij(n-1) to efficiently compute Kijn. To summarize the alternative: Kijn = hash (Kij || n) Food for thought, Russ From ipsec-request@ans.net Sat Nov 11 01:12:50 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18324 (5.65c/IDA-1.4.4 for ); Fri, 10 Nov 1995 20:15:38 -0500 Received: by interlock.ans.net id AA12237 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 10 Nov 1995 20:09:37 -0500 Message-Id: <199511110109.AA12237@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 10 Nov 1995 20:09:37 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 10 Nov 1995 20:09:37 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 10 Nov 1995 20:09:37 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 10 Nov 1995 20:09:37 -0500 Date: Sat, 11 Nov 1995 10:12:50 +0900 To: ip4v6@rinfo.sumiden.co.jp, tsuno@arai.ssy.sumiden.co.jp From: murase@rinfo.sumiden.co.jp (Toru Murase) X-Sender: murase@133.153.176.9 Subject: Re: Interop Cc: ipsec@ans.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp X-Mailer: Eudora-J(1.3.8.5-J13) $BB<@%$G$9!%(B $B0J2<$N$h$&$J%a%C%;!<%8$,$"$j$^$7$?!%(B At 4:06 PM 95.11.8 -0500, Michael J. Oehler wrote: Michael>At the San Jose IPSEC WG meeting, the group discussed having an ESP/AH bake off Michael>at the Dallas IETF. Although I do not think this will occur in the official sense, Michael>I would like to know if anyone is interested in bringing their design to Dallas. Michael>We could try two tests. We could connect some laptops together. We could also Michael>connect them in the terminal and communicate with our respective test sites. Michael>It can be argued that manual keying is trivial, but I believe that this Michael>demonstration is still needed. I am sure the tests will be much more Michael>complicated than I describe too. Michael> Michael>We plan to demonstrate our ESP/AH prototype at Dallas and would prefer to test Michael>with others. To do this, I would want to test with you before then. If you are Michael>interested in arranging some tests, please contact me. Michael> Michael>I have included this message to ipsec mailing list for those who may be interested Michael>in seeing the demonstrations. I expect them to be informative and not very colorful. Michael>I also expect most queries from the developer's list. Michael> Michael>Regards Michael>-Mike Oehler ************************************ Toru Murase ($BB<@%!!5|(B) murase@rinfo.sumiden.co.jp Systems and Electronics R & D Center Sumitomo Electric Industries, Ltd. Phone +81-6-466-5601 Fax +81-6-462-4586 ************************************ From ipsec-request@ans.net Sat Nov 11 01:21:12 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13741 (5.65c/IDA-1.4.4 for ); Fri, 10 Nov 1995 20:26:35 -0500 Received: by interlock.ans.net id AA12482 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 10 Nov 1995 20:21:43 -0500 Message-Id: <199511110121.AA12482@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 10 Nov 1995 20:21:43 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 10 Nov 1995 20:21:43 -0500 Date: Fri, 10 Nov 1995 17:21:12 -0800 (PST) From: Phil Karn To: atkinson@itd.nrl.navy.mil Cc: ipsec@ans.net In-Reply-To: <199511091937.AA07569@interlock.ans.net> (atkinson@itd.nrl.navy.mil) Subject: Re: naming and terminology > As co-chair, my understanding of consensus is roughly what Ted >T'so described -- namely the "mutually suspicious users" problem is >one that MUST be addressed in pass 1. I do NOT think this is hard to >do -- if one simply supports PGP keys (which name users not systems) >in Photuris and has the ability to pass the name string between the >two parties to the Photuris exchange the basic requirement is met. I Ran, if that's all there is, then I have no problem with it at all. I just didn't want an extended philosophical debate to stall work on the basic mechanisms. Phil From ipsec-request@ans.net Sat Nov 11 02:49:24 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17754 (5.65c/IDA-1.4.4 for ); Fri, 10 Nov 1995 21:56:09 -0500 Received: by interlock.ans.net id AA13506 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 10 Nov 1995 21:49:33 -0500 Message-Id: <199511110249.AA13506@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 10 Nov 1995 21:49:33 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 10 Nov 1995 21:49:33 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: "PALAMBER.US.ORACLE.COM" Cc: ipsec@ans.net Subject: Re: SKIP: Interoperability proposal In-Reply-To: Your message of "10 Nov 1995 10:38:40 PST." <199511101953.AA05644@interlock.ans.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 10 Nov 1995 21:49:24 -0500 From: "Perry E. Metzger" "PALAMBER.US.ORACLE.COM" writes: > SKIP is part of IPSEC. Thats news to me. The IPSEC documents don't mention SKIP anywhere. I know -- I was one of the people that edited and wrote them. > The SKIP implementors and editor are working hard at making SKIP > compatable with AH/ESP. Thats a different story. However, so far as I can tell, its not possible. A SKIP implementation necessarily is not compatible with the base transforms in IPSEC or with the way IPSEC modularly handles key negotiation. The only reason I can see that the SKIP people want to move to similar formats is so that they can claim in the press that it has something to do with IPSEC. > It does represent an alternative to the original working group > concept of only supporting an application layer key management > protocol. Actually, we didn't speak of only supporting application layer or allowing other things. However, the SKIP model is so totally different from the IPSEC model that they bear no resemblance. I'm not saying that the folks doing SKIP work should stop. However, they shouldn't claim its IPSEC related. It really isn't. Perry From ipsec-request@ans.net Sat Nov 11 04:32:41 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18860 (5.65c/IDA-1.4.4 for ); Sat, 11 Nov 1995 00:13:21 -0500 Received: by interlock.ans.net id AA15188 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 11 Nov 1995 00:07:59 -0500 Message-Id: <199511110507.AA15188@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 11 Nov 1995 00:07:59 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 11 Nov 1995 00:07:59 -0500 Date: Sat, 11 Nov 95 04:32:41 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: naming and terminology > From: atkinson@itd.nrl.navy.mil (Ran Atkinson) > As co-chair, my understanding of consensus is roughly what Ted > T'so described -- namely the "mutually suspicious users" problem is > one that MUST be addressed in pass 1. I do NOT think this is hard to > do -- if one simply supports PGP keys (which name users not systems) > in Photuris and has the ability to pass the name string between the > two parties to the Photuris exchange the basic requirement is met. I have no idea what you are talking about. PGP is not supported in the base spec. And PGP can and does in fact name systems as well as users. Passing a name string as an Identity is already supported in the base spec. > Secondly, Bill Simpson is flat out wrong in the way he is > using "mandatory access control", "multi-level secure", and similar > terms. The revised note from Ted T'so is correct in use of language. It has been thusly revised: Internet Security protects against threats that come from the external network, not from mutually hostile users of the nodes themselves. Any secure multi-user operating system MUST be able to protect its resources from hostile users, and protect one hostile user from damaging the resources controlled by another hostile user. When required for secure multi-user environments with discretionary access controls, the Photuris Identification can be used to provide separate limited authentication from each user of one node when communicating with another common node. To provide user-oriented keying, the nodes can initiate multiple concurrent Photuris exchanges. These may provide separate user Identification from the Initiator to the Responder in each direction. Each secure multi-user operating system MUST be capable of separately maintaining multiple Identification Exchange SPI values for each Value Exchange calculated shared-secret. It is the responsibility of the Source to internally segregate the shared-secret and different session-keys provided per Destination, and select an appropriate SPI for each datagram transmission. And in the implementation notes: Successful use of user-oriented keying requires a significant level of operating system support. If the operating system has a security vulnerability, then there is no basis for separate user-oriented keying. Use of multi-user segregated exchanges likely requires added functionality in the transport API of the implementation operating system. Such a mechanism is outside the scope of this document. It has been suggested that the Photuris exchange could also be established between particular application or transport processes associated with a user of a node. Such a mechanism is emphatically outside the scope of this document. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Sat Nov 11 18:06:35 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18183 (5.65c/IDA-1.4.4 for ); Sat, 11 Nov 1995 13:23:39 -0500 Received: by interlock.ans.net id AA22436 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 11 Nov 1995 13:17:50 -0500 Message-Id: <199511111817.AA22436@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 11 Nov 1995 13:17:50 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 11 Nov 1995 13:17:50 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: Germano Caronni Cc: ipsec@ans.net Subject: Re: SKIP: Interoperability proposal In-Reply-To: Your message of "Sat, 11 Nov 1995 00:18:36 +0100." <199511102318.AAA01312@ktik6> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Sat, 11 Nov 1995 13:06:35 -0500 From: "Perry E. Metzger" Germano Caronni writes: > Perry E. Metzger wrote: > > Hilarie Orman writes: > > > The SKIP work seems as mainstream ipsec as anything else. > > Its largely to completely incompatible. Given that, I'd say it isn't > > IPSEC. > > Perry, I strongly disagree with you. skip-04 bases itself heavily on > RFC1825, and is firmly coupled with both 1826 and 1827, making 1828 > and 1829 mandatory to implement. This looks quite like being in the > line of IPSEC. I have heard you and others say this sort of thing before. I can disagree all day long with you, but it won't do any good. Suffice it to say, I believe that the claim is specious. SKIP is "compatible" in name only. A SKIP packet will not "work" with, say, an NRL IPSEC implementation. It makes different assumptions about the whole world, and assumes you have bought into the whole SKIP key management mechanism. I think that the fact that SKIP exists at all demonstrates that SKIP isn't the same as IPSEC. If it was, then why would anyone bother writing drafts about it, since it would be the same thing? The fact remains that the direction we have selected is the IPSEC documents, which are now standards track, and Photuris-like mechanisms, of which Photuris is the one currently under greatest study and development. SKIP is *not* the direction that the mainstream standardization effort is going in. Perry From ipsec-request@ans.net Sat Nov 11 23:57:35 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12793 (5.65c/IDA-1.4.4 for ); Sat, 11 Nov 1995 19:01:32 -0500 Received: by interlock.ans.net id AA25272 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 11 Nov 1995 18:57:49 -0500 Message-Id: <199511112357.AA25272@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 11 Nov 1995 18:57:49 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 11 Nov 1995 18:57:49 -0500 From: Germano Caronni Subject: Re: SKIP: Interoperability proposal To: perry@piermont.com Date: Sun, 12 Nov 1995 00:57:35 +0100 (MET) Cc: ipsec@ans.net In-Reply-To: <199511111806.NAA23843@jekyll.piermont.com> from "Perry E. Metzger" at Nov 11, 95 01:06:35 pm X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Content-Length: 2277 Perry E. Metzger wrote: > ... I believe that the claim is specious. SKIP is "compatible" in > name only. A SKIP packet will not "work" with, say, an NRL IPSEC > implementation. It makes different assumptions about the whole world, > and assumes you have bought into the whole SKIP key management > mechanism. Sure. What exactly is an IPSEC implementation? Or do you rather refer to a combination of Photuris/AH/ESP as opposed to say ISAKMP/AH/ESP or SKIP/AH/ESP as _THE_ IPSEC implementation? That IMNSHO is quite narrow a view. > I think that the fact that SKIP exists at all demonstrates that SKIP > isn't the same as IPSEC. If it was, then why would anyone bother > writing drafts about it, since it would be the same thing? SKIP is not the same as Photuris. The charter of the ipsec working group fits both of them, if I remember correctly. > The fact remains that the direction we have selected is the IPSEC > documents, which are now standards track, and Photuris-like > mechanisms, of which Photuris is the one currently under greatest > study and development. SKIP is *not* the direction that the mainstream > standardization effort is going in. Thank you for telling me what is going to be standard and what not. As the case is now brilliantly clear, there sure would be no problem for bearing a little longer with SKIP, until it dies its natural death? It certainly would not cost you anything to simply wait it out. Photuris and SKIP both use AH/ESP to provide security on the IP layer. Although Photuris has many advantages, it is perhaps not the best solution in all possible situations. Neither is SKIP. How about creating the three different draft protocols (as there seems to be substantial interest in each of them), make Photuris mandatory or whatever, and the others optional. Then let the public play with the different approaches, and let it decide. I suggest you bear with the 'skippies' just a little bit longer. Greetings, Germano p.s. I will restrain myself from further escalating this discussion as I feel Dallas will be an appropriate point in time and space to continue it. So hopefully this is my last reply to yur suggestion to move SKIP off ipsec. Please remember the can of worms you mentioned in your mail from Jul 1st... From ipsec-request@ans.net Sun Nov 12 21:25:17 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17743 (5.65c/IDA-1.4.4 for ); Sun, 12 Nov 1995 16:30:38 -0500 Received: by interlock.ans.net id AA04926 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 12 Nov 1995 16:25:42 -0500 Message-Id: <199511122125.AA04926@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 12 Nov 1995 16:25:42 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 12 Nov 1995 16:25:42 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: Germano Caronni Cc: ipsec@ans.net Subject: Re: SKIP: Interoperability proposal In-Reply-To: Your message of "Sun, 12 Nov 1995 00:57:35 +0100." <199511112357.AAA00977@ktik0> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Sun, 12 Nov 1995 16:25:17 -0500 From: "Perry E. Metzger" Germano Caronni writes: > Perry E. Metzger wrote: > > ... I believe that the claim is specious. SKIP is "compatible" in > > name only. A SKIP packet will not "work" with, say, an NRL IPSEC > > implementation. It makes different assumptions about the whole world, > > and assumes you have bought into the whole SKIP key management > > mechanism. > > Sure. What exactly is an IPSEC implementation? Say, the NRL implementation for 4.4BSD. > Or do you rather refer to a > combination of Photuris/AH/ESP as opposed to say ISAKMP/AH/ESP or > SKIP/AH/ESP as _THE_ IPSEC implementation? That IMNSHO is quite narrow > a view. I am not assuming the use of Photuris. Thats not relevant to what I'm saying. The fact is that you cannot use SKIP on top of NRL's implementation. SKIP doesn't play nicely with conventional AH/ESP implementations. SKIP doesn't follow the model, period. No amount of wishing on your part would make it so. > > I think that the fact that SKIP exists at all demonstrates that SKIP > > isn't the same as IPSEC. If it was, then why would anyone bother > > writing drafts about it, since it would be the same thing? > > SKIP is not the same as Photuris. The charter of the ipsec working group > fits both of them, if I remember correctly. Look, let me be brutal here. Ran said at Danvers, in no uncertain terms, that we were following the direction of Photuris and the defined AH/ESP formats, according to the model listed in the RFC. That means SKIP isn't standards track, isn't going to be standards track, can't be standards track. Jeff Schiller said, at the BOF you guys had, that SKIP might become what gets adopted if the IPSEC folks drop be ball very badly. However, thus far we haven't. There are now commercial implementations of the ESP and AH stuff, and lots of people will have them in products by spring. Photuris is being implemented by multiple independent groups. You can keep pretending that SKIP is under consideration if you like, but it isn't. Form your own working group to make SKIP an elective standard that will only be used by Sun, or drop it. Don't pretend its mainstream. > Photuris and SKIP both use AH/ESP to provide security on the IP layer. SKIP does NOT NOT NOT use the defined AH and ESP except in the most literal sense. You've forced it to look similar so you can claim compatibility but in reality there is no basis for compatibility at all. Quit pretending. SKIP is not just a modular key management protocol -- it changes the whole model. Claims to the contrary are simply false. > Although Photuris has many advantages, it is perhaps not the best solution > in all possible situations. Neither is SKIP. How about creating the three > different draft protocols (as there seems to be substantial interest in each > of them), make Photuris mandatory or whatever, and the others > optional. You are free to form a new working group to make SKIP an elective standard. That was the approach that you guys seemed to be taking. No one is stopping you. Just quit pretending it has anything to do with our work here. Perry From ipsec-request@ans.net Mon Nov 13 01:37:00 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12593 (5.65c/IDA-1.4.4 for ); Sun, 12 Nov 1995 20:45:05 -0500 Received: by interlock.ans.net id AA06989 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 12 Nov 1995 20:37:36 -0500 Message-Id: <199511130137.AA06989@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 12 Nov 1995 20:37:36 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 12 Nov 1995 20:37:36 -0500 Date: Sun, 12 Nov 1995 17:37:00 -0800 (PST) From: Phil Karn To: perry@piermont.com Cc: caronni@tik.ee.ethz.ch, ipsec@ans.net In-Reply-To: <199511111817.AA22436@interlock.ans.net> (perry@piermont.com) Subject: Re: SKIP: Interoperability proposal Perry et al, I think there's plenty of room for multiple approaches. To the extent that we can have multiple groups working on parallel approaches that cross-fertilize each other, I see nothing wrong with this. I welcome the continued participation of the SKIP folks on the ipsec mailing list. After all, we are all trying to accomplish much the same things. Phil From ipsec-request@ans.net Mon Nov 13 17:28:26 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15509 (5.65c/IDA-1.4.4 for ); Mon, 13 Nov 1995 13:41:17 -0500 Received: by interlock.ans.net id AA21706 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 13 Nov 1995 13:32:50 -0500 Message-Id: <199511131832.AA21706@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 13 Nov 1995 13:32:50 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 13 Nov 1995 13:32:50 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 13 Nov 1995 13:32:50 -0500 Date: 13 Nov 95 09:28:26 -0800 From: "PALAMBER.US.ORACLE.COM" To: perry@piermont.com Subject: Re: SKIP: Interoperability proposal Cc: ipsec@ans.net X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:perry@piermont.com's message of 10-Nov-95 22:49 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Boundary-1576884-0-0 --Boundary-1576884-0-0 Perry, One last time: SKIP is a work item of the IPSEC group. There was a SKIP BOF in Stockholm, but the work has been pulled into this mailing list because of the many shared goals. Please quite cluttering the mail list with your impressions of the IPSEC groups scope. In the "Internet Model" of development we need to be open to the evolution of new approaches if they are well documented and supported by implementations. It is true that SKIP does not meet the some of the original requirements for key management. These are important requirements that include critical capabilities for negotiation. SKIP does "support" and build on the base AH/ESP encapsulation protocol. Since it builds on AH/ESP it helps if this work is part of the IPSEC working group. If you are not happy with SKIP, try to improve the viability of other specifications. 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 -------------------------------------------------------------- --Boundary-1576884-0-0 Content-Type: message/rfc822 Date: 10 Nov 95 21:49:24 From:"Perry E. Metzger" To: PALAMBER@us.oracle.com Subject: Re: SKIP: Interoperability proposal Cc: ipsec@ans.net Reply-to: perry@piermont.com X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol X-Orcl-Application: In-Reply-To: Your message of "10 Nov 1995 10:38:40 PST." X-Orcl-Application: In-Reply-To: <199511101953.AA05644@interlock.ans.net> X-Reposting-Policy: redistribute only with permission "PALAMBER.US.ORACLE.COM" writes: > SKIP is part of IPSEC. Thats news to me. The IPSEC documents don't mention SKIP anywhere. I know -- I was one of the people that edited and wrote them. > The SKIP implementors and editor are working hard at making SKIP > compatable with AH/ESP. Thats a different story. However, so far as I can tell, its not possible. A SKIP implementation necessarily is not compatible with the base transforms in IPSEC or with the way IPSEC modularly handles key negotiation. The only reason I can see that the SKIP people want to move to similar formats is so that they can claim in the press that it has something to do with IPSEC. > It does represent an alternative to the original working group > concept of only supporting an application layer key management > protocol. Actually, we didn't speak of only supporting application layer or allowing other things. However, the SKIP model is so totally different from the IPSEC model that they bear no resemblance. I'm not saying that the folks doing SKIP work should stop. However, they shouldn't claim its IPSEC related. It really isn't. Perry --Boundary-1576884-0-0-- From ipsec-request@ans.net Mon Nov 13 19:44:39 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17943 (5.65c/IDA-1.4.4 for ); Mon, 13 Nov 1995 14:45:57 -0500 Received: by interlock.ans.net id AA23395 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 13 Nov 1995 14:36:26 -0500 Message-Id: <199511131936.AA23395@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 13 Nov 1995 14:36:26 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 13 Nov 1995 14:36:26 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 13 Nov 1995 14:36:26 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 13 Nov 1995 14:36:26 -0500 Date: Mon, 13 Nov 1995 11:44:39 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) To: schneide@tik.ee.ethz.ch, ipsec@ans.net, housley@spyrus.com Subject: Re: comments on draft 03 of SKIP X-Sun-Charset: US-ASCII >From: "Housley, Russ" > > The ANSI X9.F.1 committe is looking at a variant of Diffie-Hellman that may > help. The shared secret is computed in the normal way. I guess SKIP calls > that Kij. > > The ANSI X9.F.1 variant hashes the shared secret with randoms that are > provided by each party and a counter. Each value of the counter yields a > different traffic key. To support e-mail, a constant is used instead of a > random for the recipient. > > For SKIP, constants could be used for both parties or they could be > omitted. The idea of hashing Kij concatenated with a counter should be > more efficient than the multiply associated with the current Kijn. Also, > with the hash-based scheme you do not need Kij(n-1) to efficiently compute > Kijn. > > To summarize the alternative: > > Kijn = hash (Kij || n) > Russ, Thanks for your comments. In fact, an earlier draft of SKIP, (and the SKIP paper we presented at INET '95) has precisely this mechanism for computing Kijn. Also, this is the same Kijn scheme that is used in SKIP when relying on manual Kij distribution. I think that your suggestion has a lot of merit. As you note, it doesn't require the (n-1)th value to be efficient. Let me explain the reason why we went to the g^ijn scheme, instead of the hash based scheme. This was to not pose an implementation burden on smart cards vendors. It was problematic for some smart cards to implement MD5 in the card (limited code space, etc.). We figured that a simpler alternative would be to use the key-agreement algorithm (in this case DH) to update the master key. Since a card has to implement the key-agreement algorithm in any case, we thought it might be easier to rely on the key-agreement algorithm for the Kijn calculation. However, I am open to changing this mechanism to rely only on a hash based approach, as you suggest. Let's keep in mind that the tradeoff is that any smart card implementing this will also have to implement the hash algorithm (e.g. MD5) inside the smart card. If this is an acceptable tradeoff, (given Spyrus's product line, you are especially qualified to give feedback on this) and the rest of the WG concurs, then I will modify the draft to reflect this. The other SKIP implementors have also indicated that they prefer this approach as well. Kind regards, Ashar. From ipsec-request@ans.net Mon Nov 13 19:44:12 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15397 (5.65c/IDA-1.4.4 for ); Mon, 13 Nov 1995 14:49:09 -0500 Received: by interlock.ans.net id AA23646 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 13 Nov 1995 14:44:19 -0500 Message-Id: <199511131944.AA23646@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 13 Nov 1995 14:44:19 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 13 Nov 1995 14:44:19 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: "PALAMBER.US.ORACLE.COM" Cc: ipsec@ans.net Subject: Re: SKIP: Interoperability proposal In-Reply-To: Your message of "Mon, 13 Nov 1995 10:30:36 PST." <9511131830.AA24181@maildig1.us.oracle.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 13 Nov 1995 14:44:12 -0500 From: "Perry E. Metzger" Perhaps I should give a bit of context. My original comments came because I was informed by a reporter that there were people from Sun going around claiming that SKIP was destined to be *the* standard for IP security and trying to bludgeon other manufacturers into following it since after all it was going to be *the* standard. The reporter knew me and asked for comment. I stated that the assertion that SKIP was to be *the* standard was news to me, and so far as I knew SKIP was, at best, destined for elective status, and certainly wasn't the mainstream of the current working group direction, so any statement that it was certain to be *the* standard was at the very most optimistic level highly premature and probably totally inaccurate. Now, as for the mailing list discussion, I had decided to quit arguing given that mailing list bandwidth is fairly high and that the SKIP people aren't badly behaved, and that folks like Phil had weighed in and said "oh, let them talk". However, I think I ought to answer Paul Lambert's comments, given that they have just arrived. "PALAMBER.US.ORACLE.COM" writes: > SKIP is a work item of the IPSEC group. SKIP was a proposal being considered by the IPSEC group for the original IPSEC work. It was rejected when the compromise proposal was accepted. SKIP was also a proposal considered for the key management phase of the working group's agenda. It was also rejected when the decision was announced by Ran that the group would work towards a photuris-like protocol. SKIP is not currently under consideration for any work item under the IPSEC working group's charter, so I don't know how one can refer to it as a "work item" of the IPSEC group. > Please quite cluttering the mail list with your impressions of the IPSEC > groups scope. I believe my "clutter" is based on an accurate reading of the charter and the agenda. If my reading is inaccurate, then why not discuss NLSP or other past rejected proposals as well? Why not discuss the IEEE's key management protocol, which I believe isn't under consideration any longer. > In the "Internet Model" of development we need to be open to the evolution of > new approaches if they are well documented and supported by implementations. Did I say they shouldn't have a working group or even an IETF elective standard if they liked? I merely said that they weren't on the table any more in the IPSEC working group so far as I could tell. > It is true that SKIP does not meet the some of the original requirements for > key management. These are important requirements that include critical > capabilities for negotiation. SKIP does "support" and build on the base > AH/ESP encapsulation protocol. SKIP does not "build on" AH/ESP. I get the impression it was shoehorned in to AH/ESP so that it could be said to be compatible with it on checklists. This is much like claiming that CLNP is "compatible with" IP because you can come up with an encapsulation for it in IP. > If you are not happy with SKIP, try to improve the viability of other > specifications. The other specifications quite viable. I believe my laptop will be running some of them in Dallas and using them for day to day work in communicating with my home network. Perry From ipsec-request@ans.net Mon Nov 13 20:37:31 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13763 (5.65c/IDA-1.4.4 for ); Mon, 13 Nov 1995 15:47:05 -0500 Received: by interlock.ans.net id AA25231 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 13 Nov 1995 15:37:39 -0500 Message-Id: <199511132037.AA25231@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 13 Nov 1995 15:37:39 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 13 Nov 1995 15:37:39 -0500 Date: Mon, 13 Nov 1995 15:37:31 -0500 From: "Perry E. Metzger" To: ipsec@ans.net Subject: SKIP talk Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission As I said in my last message replying to Paul, the SKIP talk doesn't bother me so much that it would be worthwhile continuing to make an issue of it, especially given that folks like Phil and others feel it has a place here. I also don't have any personal reason not to see SKIP move forward (preferably in my opinion in its own working group, which I thought was the desire given the BOF in Stockholm) and become an elective standard if people wish. I just feel it isn't really IPSEC working group material any longer, and I was a bit annoyed about the claims I heard that people from Sun were stating that SKIP was about to become *the* IETF standard for IP security, which perhaps made me more cranky than I normally am. Perry From ipsec-request@ans.net Mon Nov 13 07:48:05 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17300 (5.65c/IDA-1.4.4 for ); Mon, 13 Nov 1995 21:25:25 -0500 Received: by interlock.ans.net id AA02556 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 13 Nov 1995 21:17:41 -0500 Message-Id: <199511140217.AA02556@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 13 Nov 1995 21:17:41 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 13 Nov 1995 21:17:41 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 13 Nov 1995 21:17:41 -0500 X-Msmail-Message-Id: BD14C282 X-Msmail-Conversation-Id: C044C80A X-Msmail-Parent-Message-Id: C044C80A From: Paul Leach To: ipsec@ans.net Date: Mon, 13 Nov 95 15:48:05 PST Subject: FW: naming and terminology X-Msxmtid: red-16-msg951113234508MTP[01.51.01]000000a1-188283 Ran suggested to me that the attached might be of interest to the whole list. I sent it in response to his post on terminology, relevant portions excerpted below... ---------- From: Paul Leach To: atkinson@itd.nrl.navy.mil Subject: RE: naming and terminology Date: Friday, November 10, 1995 11:07AM Just FYI -- Windows NT has full DAC (passes C2 in appropriate configs) and Windows 95 has optional DAC on volumes when accessed over the network (the relevant case for IPSEC). So, PCs these days care about authenticating users making remote requests. ---------- ] From: Ran Atkinson ] To: ] Subject: naming and terminology ] Date: Thursday, November 09, 1995 2:37PM ] ] ] Folks, [ snip, snip snip...] ] ] ] Discretionary Access Controls (DAC): Access controls on an object ] (e.g. file) that are at the discretion of the owner ] of that object (e.g. file). This includes MOST ] commercial operating systems. DOS and Windows ] and MacOS are examples of systems that lack ] DAC. From ipsec-request@ans.net Tue Nov 14 05:02:01 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12553 (5.65c/IDA-1.4.4 for ); Tue, 14 Nov 1995 00:08:40 -0500 Received: by interlock.ans.net id AA05849 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Nov 1995 00:02:37 -0500 Message-Id: <199511140502.AA05849@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Nov 1995 00:02:37 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Nov 1995 00:02:37 -0500 Date: Mon, 13 Nov 1995 21:02:01 -0800 (PST) From: Phil Karn To: perry@piermont.com Cc: caronni@tik.ee.ethz.ch, ipsec@ans.net In-Reply-To: <199511122125.AA04926@interlock.ans.net> (perry@piermont.com) Subject: Re: SKIP: Interoperability proposal Perry, Please relax. With supporters like you I don't need very many detractors. As the originator of Photuris I welcome the SKIP people here. We're both trying to do the same thing, we may have some differences in our priorities, and if we stop sticking our tongues out at each other we may very well discover some common ground -- that is if the people involved haven't built up so much face that there's no chance of backing down in such an event. Don't forget the *real* enemy out there -- the NSA, the world's largest and best funded hacker organization. :-) Phil From ipsec-request@ans.net Tue Nov 14 05:34:36 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12603 (5.65c/IDA-1.4.4 for ); Tue, 14 Nov 1995 00:40:03 -0500 Received: by interlock.ans.net id AA06208 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Nov 1995 00:34:43 -0500 Message-Id: <199511140534.AA06208@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Nov 1995 00:34:43 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Nov 1995 00:34:43 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: Phil Karn Cc: ipsec@ans.net Subject: Re: SKIP: Interoperability proposal In-Reply-To: Your message of "Mon, 13 Nov 1995 21:02:01 PST." <199511140502.VAA22384@servo.qualcomm.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 14 Nov 1995 00:34:36 -0500 From: "Perry E. Metzger" Phil Karn writes: > Don't forget the *real* enemy out there -- the NSA, the world's largest > and best funded hacker organization. :-) I suspect that Mark Schertler and the ISAKMP crowd doesn't like thinking of themselves as the enemy :) Perry From ipsec-request@ans.net Tue Nov 14 08:55:18 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17403 (5.65c/IDA-1.4.4 for ); Tue, 14 Nov 1995 04:01:42 -0500 Received: by interlock.ans.net id AA07714 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Nov 1995 03:55:35 -0500 Message-Id: <199511140855.AA07714@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 14 Nov 1995 03:55:35 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Nov 1995 03:55:35 -0500 From: Germano Caronni Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Nov 1995 03:55:35 -0500 Subject: Reporter claiming SKIP... To: perry@piermont.com Date: Tue, 14 Nov 1995 09:55:18 +0100 (MET) Cc: ipsec@ans.net In-Reply-To: <199511131944.AA23646@interlock.ans.net> from "Perry E. Metzger" at Nov 13, 95 02:44:12 pm X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Content-Length: 347 Perry E. Metzger wrote: > My original comments came because I was informed by a reporter that > there were people from Sun going around claiming that SKIP was > destined to be *the* standard for IP security and trying to bludgeon [...] Uh. That would be very nasty. Could you please tell me who this guy is? I would like to talk to him. Germano From ipsec-request@ans.net Tue Nov 14 14:43:40 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13611 (5.65c/IDA-1.4.4 for ); Tue, 14 Nov 1995 10:11:48 -0500 Received: by interlock.ans.net id AA12340 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Nov 1995 09:45:22 -0500 Message-Id: <199511141445.AA12340@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Nov 1995 09:45:22 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Nov 1995 09:45:22 -0500 Date: 14 Nov 1995 09:43:40 -0500 From: "Jonathan Millen" Subject: Re: FW- naming and terminolo To: "ipsec" X-Mailer: Mail*Link SMTP-QM 3.0.2 Reply: RE>FW: naming and terminology MacOS also has DAC for file sharing over the network. Shared folders are read/modify controlled on a UNIX-like owner/group/other basis. -Jon Millen --------In response to------------- From: Paul Leach ... Just FYI -- Windows NT has full DAC (passes C2 in appropriate configs) and Windows 95 has optional DAC on volumes when accessed over the network (the relevant case for IPSEC). So, PCs these days care about authenticating users making remote requests. ---------- ] From: Ran Atkinson ... ] Discretionary Access Controls (DAC): Access controls on an object ] (e.g. file) that are at the discretion of the owner ] of that object (e.g. file). This includes MOST ] commercial operating systems. DOS and Windows ] and MacOS are examples of systems that lack ] DAC. From ipsec-request@ans.net Tue Nov 14 16:03:04 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18340 (5.65c/IDA-1.4.4 for ); Tue, 14 Nov 1995 11:10:23 -0500 Received: by interlock.ans.net id AA14338 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Nov 1995 11:06:50 -0500 Message-Id: <199511141606.AA14338@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Nov 1995 11:06:50 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Nov 1995 11:06:50 -0500 X-Sender: kent@eudora.bbn.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 14 Nov 1995 11:03:04 -0500 To: Paul Leach From: Stephen Kent Subject: Re: FW: naming and terminology Cc: ipsec@ans.net Paul, In the Mac OS context, Apple actually does provide DAC for Apple Share file access, even though the OS does not provide DAC for local access. This lack is understandable since the Mac is viewed as a single-user OS environment, expect in the context of file sharing. Steve From ipsec-request@ans.net Tue Nov 14 11:10:24 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12710 (5.65c/IDA-1.4.4 for ); Tue, 14 Nov 1995 11:10:24 -0500 Received: by interlock.ans.net id AA14137 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Nov 1995 11:01:26 -0500 Message-Id: <199511141601.AA14137@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 14 Nov 1995 11:01:26 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Nov 1995 11:01:26 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Nov 1995 11:01:26 -0500 Date: Tue, 14 Nov 95 07:25:58 From: "Housley, Russ" Encoding: 3230 Text To: schneide@tik.ee.ethz.ch, ipsec@ans.net, ashar@osmosys.incog.com (Ashar Aziz) Subject: Re: comments on draft 03 of SKIP Ashar: At SPYRUS, we have always included MD5 within our commercial PCMCIA crypto token, the LYNKS Privacy Card. We originally put the MD5 hash into the card to support digital signature applications, and it would be a trivial modification to use it for key update in the manner that I suggested in my original note. In fact, we already have plans to add the X9.42 scheme once the ANSI X9.F.1 committee comes to consensus on the remaining open details. I think the SKIP users and developers will be better served by the hash approach. Russ ______________________________ Reply Separator _________________________________ Subject: Re: comments on draft 03 of SKIP Author: ashar@osmosys.incog.com (Ashar Aziz) at internet Date: 11/13/95 11:45 AM >From: "Housley, Russ" > > The ANSI X9.F.1 committe is looking at a variant of Diffie-Hellman that may > help. The shared secret is computed in the normal way. I guess SKIP calls > that Kij. > > The ANSI X9.F.1 variant hashes the shared secret with randoms that are > provided by each party and a counter. Each value of the counter yields a > different traffic key. To support e-mail, a constant is used instead of a > random for the recipient. > > For SKIP, constants could be used for both parties or they could be > omitted. The idea of hashing Kij concatenated with a counter should be > more efficient than the multiply associated with the current Kijn. Also, > with the hash-based scheme you do not need Kij(n-1) to efficiently compute > Kijn. > > To summarize the alternative: > > Kijn = hash (Kij || n) > Russ, Thanks for your comments. In fact, an earlier draft of SKIP, (and the SKIP paper we presented at INET '95) has precisely this mechanism for computing Kijn. Also, this is the same Kijn scheme that is used in SKIP when relying on manual Kij distribution. I think that your suggestion has a lot of merit. As you note, it doesn't require the (n-1)th value to be efficient. Let me explain the reason why we went to the g^ijn scheme, instead of the hash based scheme. This was to not pose an implementation burden on smart cards vendors. It was problematic for some smart cards to implement MD5 in the card (limited code space, etc.). We figured that a simpler alternative would be to use the key-agreement algorithm (in this case DH) to update the master key. Since a card has to implement the key-agreement algorithm in any case, we thought it might be easier to rely on the key-agreement algorithm for the Kijn calculation. However, I am open to changing this mechanism to rely only on a hash based approach, as you suggest. Let's keep in mind that the tradeoff is that any smart card implementing this will also have to implement the hash algorithm (e.g. MD5) inside the smart card. If this is an acceptable tradeoff, (given Spyrus's product line, you are especially qualified to give feedback on this) and the rest of the WG concurs, then I will modify the draft to reflect this. The other SKIP implementors have also indicated that they prefer this approach as well. Kind regards, Ashar. From ipsec-request@ans.net Tue Nov 14 15:21:30 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17943 (5.65c/IDA-1.4.4 for ); Tue, 14 Nov 1995 12:00:45 -0500 Received: by interlock.ans.net id AA15524 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Nov 1995 11:45:23 -0500 Message-Id: <199511141645.AA15524@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Nov 1995 11:45:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Nov 1995 11:45:23 -0500 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ipsec-photuris-07.txt Date: Tue, 14 Nov 95 10:21:30 -0500 Sender: cclark@CNRI.Reston.VA.US --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 : The Photuris Session Key Management Protocol Author(s) : P. Karn, W. Simpson Filename : draft-ietf-ipsec-photuris-07.txt Pages : 64 Date : 11/13/1995 Photuris is an experimental session-key management protocol intended for use with the IP Security Protocols (AH and ESP). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-photuris-07.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-photuris-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 (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-photuris-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@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951113110456.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-photuris-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-photuris-07.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951113110456.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Tue Nov 14 07:53:07 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA04245 (5.65c/IDA-1.4.4 for ); Tue, 14 Nov 1995 12:59:56 -0500 Received: by interlock.ans.net id AA17772 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Nov 1995 12:53:17 -0500 Message-Id: <199511141753.AA17772@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Nov 1995 12:53:17 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Nov 1995 12:53:17 -0500 Date: Tue, 14 Nov 95 12:53:07 EST From: atkinson@itd.nrl.navy.mil (Ran Atkinson) To: ipsec@ans.net Subject: SKIP Perry, You are mistaken as several folks have tried to say but you don't seem to understand. I _NEVER_ said that "SKIP was rejected" or anything like it. I said that the primary focus of the WG was to get the agreed upon approach meeting the agreed upon requirements (namely Photuris, which DOES provide Perfect Forward Secrecy which is a property that IS needed by the community) but that other approaches could also proceed. There was a SKIP BOF held and the conclusion was that SKIP would continue within the IPsec WG. The world is multiprotocol and always will be. SKIP has some community of interest and I want it to proceed. I think the recent steps towards AH/ESP compatibility are movement in the correct direction. Now as co-chair, I too have been very disappointed by the "quotes" from Sun in the trade press (Network World, Comm Week, etc) to the effect that the IETF and the IPsec WG had already picked SKIP to be "The Standard". Now I knew then and know now that such claims are false. However, it is not entirely clear where those misunderstandings arose. It is clear that the trade press makes mistakes just like other humans. Please DO relax and at least let the SKIP effort proceed without your recent distractions. Ran rja@cs.nrl.navy.mil From ipsec-request@ans.net Tue Nov 14 08:02:49 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18389 (5.65c/IDA-1.4.4 for ); Tue, 14 Nov 1995 13:05:45 -0500 Received: by interlock.ans.net id AA18127 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Nov 1995 13:02:54 -0500 Message-Id: <199511141802.AA18127@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Nov 1995 13:02:54 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Nov 1995 13:02:54 -0500 Date: Tue, 14 Nov 95 13:02:49 EST From: atkinson@itd.nrl.navy.mil (Ran Atkinson) To: ipsec@ans.net Subject: editorial on Photuris Bill, [My co-chair hat is on] % I have no idea what you are talking about. PGP is not supported in the % base spec. Then add it now. See recent note from Phil Karn to the IPsec list agreeing this was OK. % It has been thusly revised: Either you really don't seem to be willing to cooperate OR you really don't follow the discussions so far, so I am reluctantly providing VERY specific guidance on the text. Please go edit accordingly. % Internet Security protects against threats that come from the % external network, not from mutually hostile users of the nodes % themselves. Any secure multi-user operating system MUST be able to % protect its resources from hostile users, and protect one hostile % user from damaging the resources controlled by another hostile user. Delete above paragraph. % When required for secure multi-user environments with discretionary % access controls, the Photuris Identification can be used to provide % separate limited authentication from each user of one node when % communicating with another common node. To provide user-oriented % keying, the nodes can initiate multiple concurrent Photuris % exchanges. These may provide separate user Identification from the % Initiator to the Responder in each direction. Rephrase "secure multi-user environments" to "multi-user environments" in the above. % Each secure multi-user operating system MUST be capable of % separately maintaining multiple Identification Exchange SPI values % for each Value Exchange calculated shared-secret. It is the % responsibility of the Source to internally segregate the % shared-secret and different session-keys provided per Destination, % and select an appropriate SPI for each datagram transmission. Rephrase "secure multi-user operating system" to "multi-user operating system" (or if you prefer "multi-user operating systems having discretionary access controls") in the above. % And in the implementation notes: % Successful use of user-oriented keying requires a significant level % of operating system support. If the operating system has a security % vulnerability, then there is no basis for separate user-oriented % keying. Delete the word "significant". We built it in BSD already and it is _NOT_ that hard to do, sorry. % Use of multi-user segregated exchanges likely requires added % functionality in the transport API of the implementation operating % system. Such a mechanism is outside the scope of this document. Replace "likely" with "might" in the above. % It has been suggested that the Photuris exchange could also be % established between particular application or transport processes % associated with a user of a node. Such a mechanism is emphatically % outside the scope of this document. Delete above paragraph. Thanks very much. Ran rja@cs.nrl.navy.mil Co-chair, IP Security WG From ipsec-request@ans.net Tue Nov 14 18:59:57 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12564 (5.65c/IDA-1.4.4 for ); Tue, 14 Nov 1995 13:54:55 -0500 Received: by interlock.ans.net id AA19555 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Nov 1995 13:51:28 -0500 Message-Id: <199511141851.AA19555@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 14 Nov 1995 13:51:28 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 14 Nov 1995 13:51:28 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Nov 1995 13:51:28 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Nov 1995 13:51:28 -0500 Date: Tue, 14 Nov 1995 10:59:57 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) To: ipsec@ans.net Subject: SKIP & the press X-Sun-Charset: US-ASCII Folks, This is REALLY getting out of hand here. Just for the record: At NO time has Sun sought the press's attention on SKIP standardization issues. To the contrary, we have done everything possible to avoid it. Our FIRST and and only contact with the press (last week) was initiated BY the press. Sun has NEVER said to the press, ANYTHING to the effect that SKIP will be "the" standard, or "a" standard. In fact, the FIRST contact that Sun officials had with the press regarding SKIP was last week, when the press quoted OTHER IETF members saying SKIP had already lost. Even then, despite the press's efforts to elicit Sun officials' comments, we ABSOLUTELY refused to comment or speculate on the eventual outcome of the IETF standardization process. We limited ourselves ONLY to technical discussions on SKIP. The press initiated this discussion with my group at Sun, AFTER talking to other IETF members who were claiming that SKIP had already lost. If there are actual names or quotes that can be attributed to Sun officials, disputing any of the above, we would like to know. Regards, Ashar. From ipsec-request@ans.net Tue Nov 14 16:03:04 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA04226 (5.65c/IDA-1.4.4 for ); Tue, 14 Nov 1995 14:44:01 -0500 Message-Id: <199511141944.AA04226@ftp.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@ftp.ans.net); Tue, 14 Nov 1995 14:40:50 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Nov 1995 14:40:50 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Nov 1995 14:40:50 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Tue, 14 Nov 1995 14:40:50 -0500 X-Sender: kent@eudora.bbn.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 14 Nov 1995 11:03:04 -0500 To: Paul Leach From: Stephen Kent Subject: Re: FW: naming and terminology Cc: ipsec@ans.net Paul, In the Mac OS context, Apple actually does provide DAC for Apple Share file access, even though the OS does not provide DAC for local access. This lack is understandable since the Mac is viewed as a single-user OS environment, expect in the context of file sharing. Steve From ipsec-request@ans.net Tue Nov 14 15:04:20 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13733 (5.65c/IDA-1.4.4 for ); Tue, 14 Nov 1995 15:04:20 -0500 Message-Id: <199511142004.AA13733@ftp.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@ftp.ans.net); Tue, 14 Nov 1995 15:01:09 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 14 Nov 1995 15:01:09 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Nov 1995 15:01:09 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Nov 1995 15:01:09 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Tue, 14 Nov 1995 15:01:09 -0500 Date: Tue, 14 Nov 95 07:25:58 From: "Housley, Russ" Encoding: 3230 Text To: schneide@tik.ee.ethz.ch, ipsec@ans.net, ashar@osmosys.incog.com (Ashar Aziz) Subject: Re: comments on draft 03 of SKIP Ashar: At SPYRUS, we have always included MD5 within our commercial PCMCIA crypto token, the LYNKS Privacy Card. We originally put the MD5 hash into the card to support digital signature applications, and it would be a trivial modification to use it for key update in the manner that I suggested in my original note. In fact, we already have plans to add the X9.42 scheme once the ANSI X9.F.1 committee comes to consensus on the remaining open details. I think the SKIP users and developers will be better served by the hash approach. Russ ______________________________ Reply Separator _________________________________ Subject: Re: comments on draft 03 of SKIP Author: ashar@osmosys.incog.com (Ashar Aziz) at internet Date: 11/13/95 11:45 AM >From: "Housley, Russ" > > The ANSI X9.F.1 committe is looking at a variant of Diffie-Hellman that may > help. The shared secret is computed in the normal way. I guess SKIP calls > that Kij. > > The ANSI X9.F.1 variant hashes the shared secret with randoms that are > provided by each party and a counter. Each value of the counter yields a > different traffic key. To support e-mail, a constant is used instead of a > random for the recipient. > > For SKIP, constants could be used for both parties or they could be > omitted. The idea of hashing Kij concatenated with a counter should be > more efficient than the multiply associated with the current Kijn. Also, > with the hash-based scheme you do not need Kij(n-1) to efficiently compute > Kijn. > > To summarize the alternative: > > Kijn = hash (Kij || n) > Russ, Thanks for your comments. In fact, an earlier draft of SKIP, (and the SKIP paper we presented at INET '95) has precisely this mechanism for computing Kijn. Also, this is the same Kijn scheme that is used in SKIP when relying on manual Kij distribution. I think that your suggestion has a lot of merit. As you note, it doesn't require the (n-1)th value to be efficient. Let me explain the reason why we went to the g^ijn scheme, instead of the hash based scheme. This was to not pose an implementation burden on smart cards vendors. It was problematic for some smart cards to implement MD5 in the card (limited code space, etc.). We figured that a simpler alternative would be to use the key-agreement algorithm (in this case DH) to update the master key. Since a card has to implement the key-agreement algorithm in any case, we thought it might be easier to rely on the key-agreement algorithm for the Kijn calculation. However, I am open to changing this mechanism to rely only on a hash based approach, as you suggest. Let's keep in mind that the tradeoff is that any smart card implementing this will also have to implement the hash algorithm (e.g. MD5) inside the smart card. If this is an acceptable tradeoff, (given Spyrus's product line, you are especially qualified to give feedback on this) and the rest of the WG concurs, then I will modify the draft to reflect this. The other SKIP implementors have also indicated that they prefer this approach as well. Kind regards, Ashar. From ipsec-request@ans.net Tue Nov 14 04:04:48 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17370 (5.65c/IDA-1.4.4 for ); Tue, 14 Nov 1995 15:07:38 -0500 Received: by interlock.ans.net id AA02356 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Nov 1995 15:06:25 -0500 Message-Id: <199511142006.AA02356@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 14 Nov 1995 15:06:25 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 14 Nov 1995 15:06:25 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Nov 1995 15:06:25 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Nov 1995 15:06:25 -0500 X-Received: from red-16-msg by xnet1 with receive; Tue, 14 Nov 1995 12:04:36 -0800 X-Msmail-Message-Id: B5995B3E X-Msmail-Conversation-Id: B5995B3E From: Paul Leach To: kent@bbn.com Date: Tue, 14 Nov 95 12:04:48 PST Subject: Re: FW: naming and terminology Cc: ipsec@ans.net X-Msxmtid: red-16-msg951114200332MTP[01.51.01]000000a1-191834 I didn't mean to imply anything about the Mac -- that part is quoted from Ran. The net result is, though, that all major current OSes (by installed base count) care about authenticating users making requests that come in over the net. Paul ---------- ] From: Stephen Kent ] To: Paul Leach ] Cc: ] Subject: Re: FW: naming and terminology ] Date: Tuesday, November 14, 1995 11:03AM ] ] Paul, ] ] In the Mac OS context, Apple actually does provide DAC for Apple ] Share file access, even though the OS does not provide DAC for local ] access. This lack is understandable since the Mac is viewed as a ] single-user OS environment, expect in the context of file sharing. ] ] Steve ] ] From ipsec-request@ans.net Tue Nov 14 20:12:32 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18919 (5.65c/IDA-1.4.4 for ); Tue, 14 Nov 1995 15:18:49 -0500 Received: by interlock.ans.net id AA02595 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Nov 1995 15:14:23 -0500 Message-Id: <199511142014.AA02595@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 14 Nov 1995 15:14:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 14 Nov 1995 15:14:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Nov 1995 15:14:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Nov 1995 15:14:23 -0500 Sender: Charles Watt Subject: Re: editorial on Photuris To: atkinson@itd.nrl.navy.mil (Ran Atkinson) Date: Tue, 14 Nov 1995 15:12:32 -0500 (EST) From: Charles Watt Cc: ipsec@ans.net In-Reply-To: <199511141802.AA18127@interlock.ans.net> from "Ran Atkinson" at Nov 14, 95 01:02:49 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 3830 -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-Certificate: MIIBvzCCAWkCEFmOln6ip0w49CuyWr9vDVUwDQYJKoZIhvcNAQECBQAwWTELMAkG A1UEBhMCVVMxGDAWBgNVBAoTD1NlY3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2Vj dXJlV2FyZSBQQ0ExFzAVBgNVBAsTDkVuZ2luZWVyaW5nIENBMB4XDTk1MDUwODIw MjMzNVoXDTk3MDUwNzIwMjMzNVowcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1Nl Y3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2VjdXJlV2FyZSBQQ0ExFzAVBgNVBAsT DkVuZ2luZWVyaW5nIENBMRUwEwYDVQQDEwxDaGFybGVzIFdhdHQwWTAKBgRVCAEB AgICBANLADBIAkEM2ZSp7b6eqDqK5RbPFpd6DGSLjbpHOZU07pUcdgJXiduj9Ytf 1rsmf/adaplQr+X5FeoIdT/bVSv2MUi3gY0eFwIDAQABMA0GCSqGSIb3DQEBAgUA A0EApEjzeBjiSnGImJXgeY1K8HWSufpJ2DpLBF7DYqqIVAX9H7gmfOJhfeGEYVjK aTxjgASxqHhzkx7PkOnL4JrN+Q== MIC-Info: RSA-MD5,RSA, AKyfBsWbZ7U1FUIEuhJONDvzkaDXZiknbFTlab7v2i6FoYNnuV/3ImvJsQm4dB01 k1PlUsnAKtP7SWWCmvTZWAg= Ran Atkinson wrote: > > Bill, > > [My co-chair hat is on] > > % I have no idea what you are talking about. PGP is not supported in the > % base spec. > > Then add it now. See recent note from Phil Karn to the IPsec > list agreeing this was OK. I'm in complete agreement that an IETF standard key management protocol should support authentication and key management between any two arbitrary "principals" regardless of whether they be hosts or users. But a hurried inclusion of PGP into Photuris is a serious mistake for a number of reasons: 1) PGP is non-standard. You would face trouble advancing Photuris along the standards track referencing a non-IETF protocol. 2) It is far from clear that PGP is the best, or even a desirable approach. 3) PGP by itself is insufficient for solving the problem -- and it certainly isn't necessary for solving the problem at this stage of the specification process. What is needed are minor protocol changes to ensure that sufficient naming attributes are available to identify the intended principals associated with the Photuris exchange. How you verify this naming information -- i.e, whether we need PGP or any other form of certificates -- does not need to be part of the Photuris specification. There are two modes that a generic key management protocol should support: A) Specified Target: the initiator knows the identity of the target principal before initiating the Photuris exchange. B) Exploratory Mode: the initiator does not know the identity of the target principal, but is interested in completing the Photuris exchange so it can learn this identity and make any required access decisions. Currently Photuris doesn't support either mode for user level keying. To support A it must include an identification field for both the initiator and responder. This enables the responder to identify the target of the Photuris exchange. To support B it must be able to specify sufficient information in lieu of the responder's "name" in order to identify the responder -- e.g. target port number. There are additional considerations when supporting user level keying on multiuser hosts. For example, a user might be authorized for a particular service -- but only when accessing that service from a specific host. In order to enforce such a policy, the enforcement mechanism must be provided with both the authenticated user identity and the authenticated identity of the client host. SecureWare's HannaH product (http://www.secureware.com/) provides network security between any two arbitrary principals using a security protocol that sits on top of the transport (but within the kernel portion of the protocol stack so that it is transparent to the application). Its "Peer Authentication and Key Management Protocol" (PAKMP) provides one mode that is quite similar to Photuris, except that it exchanges sufficient information to support user level keying in a mixed environment of single user workstations and multiuser hosts. The protocol spec is online, and shows what little needs to be added to Photuris. Of course, if two implementations of Photuris are to be interoperable -- a good goal -- then at some point we must resolve two holy wars: - - naming - - how to bind a name to key material -- this would be where we might consider PGP, along with many other approaches. But these issues do not need to be resolved at this time for Bill and Phil to continue finalizing Photuris as a protocol specification. For the record, I would favor X.500 Distinguished Names and X.509 v3 certificates. Forget the X.400 and Directory Service baggage -- just use the flexibility these structures provide. This is the approach we used with HannaH, and have had no troubles at all. Charles Watt SecureWare, Inc. -----END PRIVACY-ENHANCED MESSAGE----- From ipsec-request@ans.net Tue Nov 14 20:35:53 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA04143 (5.65c/IDA-1.4.4 for ); Tue, 14 Nov 1995 15:42:11 -0500 Received: by interlock.ans.net id AA03346 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Nov 1995 15:37:05 -0500 Message-Id: <199511142037.AA03346@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Nov 1995 15:37:05 -0500 From: Ran Atkinson Date: Tue, 14 Nov 1995 15:35:53 -0500 In-Reply-To: Charles Watt "Re: editorial on Photuris" (Nov 14, 15:12) References: <9511142012.AA18116@mordred.sware.com> Reply-To: rja@cs.nrl.navy.mil X-Mailer: Z-Mail (3.2.1 10apr95) To: Charles Watt Subject: Re: editorial on Photuris Cc: ipsec@ans.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: rja@bodhi.cs.nrl.navy.mil Charles, Thanks for your note. There is no process problem with the IETF referencing PGP certificates. The IETF is not restricted to only referencing IETF specs. While I agree that it would be nice to also support other kinds of certificates eventually, I think there is rough (not necessarily smooth) consensus in the WG that PGP is important to support now. As a point of fact, PGP is already widely deployed and used in the Internet community. Rough consensus is the benchmark that the IETF specifies and that the chairs try to apply. If you have specific changes you want to see in any of the specs being discussed (SKIP, Photuris, etc), then it would be helpful if you made specific proposals to the entire mailing list. I _do_ generally sympathise with document editors when general comments are made that are not obvious to write up for the document. As editor for AH/ESP, I can say that folks who sent me proposed revised text almost always succeeded in getting me to change my text... Ran rja@cs.nrl.navy.mil From ipsec-request@ans.net Tue Nov 14 19:22:25 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17251 (5.65c/IDA-1.4.4 for ); Tue, 14 Nov 1995 16:00:52 -0500 Received: by interlock.ans.net id AA04188 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Nov 1995 15:53:10 -0500 Message-Id: <199511142053.AA04188@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 14 Nov 1995 15:53:10 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Nov 1995 15:53:10 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Nov 1995 15:53:10 -0500 Date: 14 Nov 95 11:22:25 -0800 From: "PALAMBER.US.ORACLE.COM" To: ipsec@ans.net Subject: WG Last Call for SKIP I-D Mime-Version: 1.0 This is the WG Last Call for the SKIP I-D (draft-ietf-ipsec-skip-04.txt), before it moves forward as an RFC. The WG Last Call ends Wednesday, Dec. 15, 1995. The editor of SKIP (Ashar Aziz) will be out of the country after the December IETF meeting and has requested this review to accelarate the editing. Please send your constructive comments to the list to facilitate this process. Note that the Working Group last call on the SKIP specification does not mean that SKIP meets the IPSEC requirements for "the" Internet Key Management Protocol. Paul A. Lambert IPSEC Co-Chair -------------------------------------------------------------- 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 -------------------------------------------------------------- From ipsec-request@ans.net Tue Nov 14 15:21:30 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18024 (5.65c/IDA-1.4.4 for ); Tue, 14 Nov 1995 16:01:56 -0500 Message-Id: <199511142101.AA18024@ftp.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@ftp.ans.net); Tue, 14 Nov 1995 15:59:53 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Nov 1995 15:59:53 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Nov 1995 15:59:53 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Tue, 14 Nov 1995 15:59:53 -0500 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ipsec-photuris-07.txt Date: Tue, 14 Nov 95 10:21:30 -0500 Sender: cclark@CNRI.Reston.VA.US --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 : The Photuris Session Key Management Protocol Author(s) : P. Karn, W. Simpson Filename : draft-ietf-ipsec-photuris-07.txt Pages : 64 Date : 11/13/1995 Photuris is an experimental session-key management protocol intended for use with the IP Security Protocols (AH and ESP). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-photuris-07.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-photuris-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 (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-photuris-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@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951113110456.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-photuris-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-photuris-07.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951113110456.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Tue Nov 14 07:53:07 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17323 (5.65c/IDA-1.4.4 for ); Tue, 14 Nov 1995 16:23:26 -0500 Message-Id: <199511142123.AA17323@ftp.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@ftp.ans.net); Tue, 14 Nov 1995 16:20:54 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Nov 1995 16:20:54 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Nov 1995 16:20:54 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Tue, 14 Nov 1995 16:20:54 -0500 Date: Tue, 14 Nov 95 12:53:07 EST From: atkinson@itd.nrl.navy.mil (Ran Atkinson) To: ipsec@ans.net Subject: SKIP Perry, You are mistaken as several folks have tried to say but you don't seem to understand. I _NEVER_ said that "SKIP was rejected" or anything like it. I said that the primary focus of the WG was to get the agreed upon approach meeting the agreed upon requirements (namely Photuris, which DOES provide Perfect Forward Secrecy which is a property that IS needed by the community) but that other approaches could also proceed. There was a SKIP BOF held and the conclusion was that SKIP would continue within the IPsec WG. The world is multiprotocol and always will be. SKIP has some community of interest and I want it to proceed. I think the recent steps towards AH/ESP compatibility are movement in the correct direction. Now as co-chair, I too have been very disappointed by the "quotes" from Sun in the trade press (Network World, Comm Week, etc) to the effect that the IETF and the IPsec WG had already picked SKIP to be "The Standard". Now I knew then and know now that such claims are false. However, it is not entirely clear where those misunderstandings arose. It is clear that the trade press makes mistakes just like other humans. Please DO relax and at least let the SKIP effort proceed without your recent distractions. Ran rja@cs.nrl.navy.mil From ipsec-request@ans.net Tue Nov 14 21:17:36 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA04272 (5.65c/IDA-1.4.4 for ); Tue, 14 Nov 1995 16:23:27 -0500 Received: by interlock.ans.net id AA05182 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Nov 1995 16:18:10 -0500 Message-Id: <199511142118.AA05182@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Nov 1995 16:18:10 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Nov 1995 16:18:10 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: Charles Watt Cc: atkinson@itd.nrl.navy.mil (Ran Atkinson), ipsec@ans.net Subject: Re: editorial on Photuris In-Reply-To: Your message of "Tue, 14 Nov 1995 15:12:32 EST." <199511142014.AA02595@interlock.ans.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 14 Nov 1995 16:17:36 -0500 From: "Perry E. Metzger" Charles Watt writes: > 1) PGP is non-standard. You would face trouble advancing > Photuris along the standards track referencing a non-IETF > protocol. There is a PGP formats draft in progress right now. > 2) It is far from clear that PGP is the best, or even a desirable > approach. Perhaps, but X.509 is certainly more part of the problem set than the solution set,and no one seems to be working on anything else right now. > 3) PGP by itself is insufficient for solving the problem -- and it > certainly isn't necessary for solving the problem at this stage > of the specification process. Well, it *does* solve some nice problems for us in the short run. .pm From ipsec-request@ans.net Tue Nov 14 21:27:43 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18363 (5.65c/IDA-1.4.4 for ); Tue, 14 Nov 1995 16:29:59 -0500 Received: by interlock.ans.net id AA05632 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Nov 1995 16:27:17 -0500 Message-Id: <199511142127.AA05632@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Nov 1995 16:27:17 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Nov 1995 16:27:17 -0500 X-Sender: kent@eudora.bbn.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 14 Nov 1995 16:27:43 -0500 To: rja@cs.nrl.navy.mil From: Stephen Kent Subject: Re: editorial on Photuris Cc: Charles Watt , ipsec@ans.net Ran, I respectfully disagree with your conclusions re use of PGP certificates with Photuris. While PGP is the most widely used secure email protocol in the Internet, its use is not all that widespread in the "grand scheme of things." Also, while it's true that IETF standards need not be restricted to making use of other IETF standards as underlyingt tools, there are potential problems whenever one elects to employ an "external" technology. In fairness, this concern also would apply to use of other certificate formats, but at least those that are formal standards with well documented change procedures etc. offer some greater assurance of stability. I think Charlie's point is a good one, i.e., to the greatest extent possible, Photuris and IP security protoco, access control ought to be defined in terms of principal identifiers one level removed from the certificate format(s) that might be used to convey the identifiers and associated public keys. Steve From ipsec-request@ans.net Tue Nov 14 08:02:49 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12759 (5.65c/IDA-1.4.4 for ); Tue, 14 Nov 1995 16:42:17 -0500 Message-Id: <199511142142.AA12759@ftp.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@ftp.ans.net); Tue, 14 Nov 1995 16:38:22 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Nov 1995 16:38:22 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Nov 1995 16:38:22 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Tue, 14 Nov 1995 16:38:22 -0500 Date: Tue, 14 Nov 95 13:02:49 EST From: atkinson@itd.nrl.navy.mil (Ran Atkinson) To: ipsec@ans.net Subject: editorial on Photuris Bill, [My co-chair hat is on] % I have no idea what you are talking about. PGP is not supported in the % base spec. Then add it now. See recent note from Phil Karn to the IPsec list agreeing this was OK. % It has been thusly revised: Either you really don't seem to be willing to cooperate OR you really don't follow the discussions so far, so I am reluctantly providing VERY specific guidance on the text. Please go edit accordingly. % Internet Security protects against threats that come from the % external network, not from mutually hostile users of the nodes % themselves. Any secure multi-user operating system MUST be able to % protect its resources from hostile users, and protect one hostile % user from damaging the resources controlled by another hostile user. Delete above paragraph. % When required for secure multi-user environments with discretionary % access controls, the Photuris Identification can be used to provide % separate limited authentication from each user of one node when % communicating with another common node. To provide user-oriented % keying, the nodes can initiate multiple concurrent Photuris % exchanges. These may provide separate user Identification from the % Initiator to the Responder in each direction. Rephrase "secure multi-user environments" to "multi-user environments" in the above. % Each secure multi-user operating system MUST be capable of % separately maintaining multiple Identification Exchange SPI values % for each Value Exchange calculated shared-secret. It is the % responsibility of the Source to internally segregate the % shared-secret and different session-keys provided per Destination, % and select an appropriate SPI for each datagram transmission. Rephrase "secure multi-user operating system" to "multi-user operating system" (or if you prefer "multi-user operating systems having discretionary access controls") in the above. % And in the implementation notes: % Successful use of user-oriented keying requires a significant level % of operating system support. If the operating system has a security % vulnerability, then there is no basis for separate user-oriented % keying. Delete the word "significant". We built it in BSD already and it is _NOT_ that hard to do, sorry. % Use of multi-user segregated exchanges likely requires added % functionality in the transport API of the implementation operating % system. Such a mechanism is outside the scope of this document. Replace "likely" with "might" in the above. % It has been suggested that the Photuris exchange could also be % established between particular application or transport processes % associated with a user of a node. Such a mechanism is emphatically % outside the scope of this document. Delete above paragraph. Thanks very much. Ran rja@cs.nrl.navy.mil Co-chair, IP Security WG From ipsec-request@ans.net Tue Nov 14 18:59:57 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18726 (5.65c/IDA-1.4.4 for ); Tue, 14 Nov 1995 17:12:16 -0500 Message-Id: <199511142212.AA18726@ftp.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@ftp.ans.net); Tue, 14 Nov 1995 17:08:31 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 14 Nov 1995 17:08:31 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 14 Nov 1995 17:08:31 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Nov 1995 17:08:31 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Nov 1995 17:08:31 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Tue, 14 Nov 1995 17:08:31 -0500 Date: Tue, 14 Nov 1995 10:59:57 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) To: ipsec@ans.net Subject: SKIP & the press X-Sun-Charset: US-ASCII Folks, This is REALLY getting out of hand here. Just for the record: At NO time has Sun sought the press's attention on SKIP standardization issues. To the contrary, we have done everything possible to avoid it. Our FIRST and and only contact with the press (last week) was initiated BY the press. Sun has NEVER said to the press, ANYTHING to the effect that SKIP will be "the" standard, or "a" standard. In fact, the FIRST contact that Sun officials had with the press regarding SKIP was last week, when the press quoted OTHER IETF members saying SKIP had already lost. Even then, despite the press's efforts to elicit Sun officials' comments, we ABSOLUTELY refused to comment or speculate on the eventual outcome of the IETF standardization process. We limited ourselves ONLY to technical discussions on SKIP. The press initiated this discussion with my group at Sun, AFTER talking to other IETF members who were claiming that SKIP had already lost. If there are actual names or quotes that can be attributed to Sun officials, disputing any of the above, we would like to know. Regards, Ashar. From ipsec-request@ans.net Tue Nov 14 12:10:31 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15403 (5.65c/IDA-1.4.4 for ); Tue, 14 Nov 1995 17:13:32 -0500 Received: by interlock.ans.net id AA07356 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Nov 1995 17:12:00 -0500 Message-Id: <199511142212.AA07356@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Nov 1995 17:12:00 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Nov 1995 17:12:00 -0500 To: rja@cs.nrl.navy.mil Cc: Charles Watt , ipsec@ans.net Subject: Re: editorial on Photuris In-Reply-To: Your message of "Tue, 14 Nov 1995 15:35:53 EST." <199511142037.AA03346@interlock.ans.net> Date: Tue, 14 Nov 1995 17:10:31 EST From: Derek Atkins > There is no process problem with the IETF referencing PGP certificates. > The IETF is not restricted to only referencing IETF specs. FYI: There is currently an I-D specifying the format of PGP version 2 (and version 3) packet formats. This specification includes the definition of public key certificates. Hopefully this draft will be lifted to an RFC in the near future. Please feel free to comment on it. It is currently called: draft-atkins-pgpformat-01.txt -derek From ipsec-request@ans.net Tue Nov 14 22:50:29 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18022 (5.65c/IDA-1.4.4 for ); Tue, 14 Nov 1995 17:54:57 -0500 Received: by interlock.ans.net id AA08738 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Nov 1995 17:50:51 -0500 Message-Id: <199511142250.AA08738@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Nov 1995 17:50:51 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Nov 1995 17:50:51 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: Stephen Kent Cc: rja@cs.nrl.navy.mil, Charles Watt , ipsec@ans.net Subject: Re: editorial on Photuris In-Reply-To: Your message of "Tue, 14 Nov 1995 16:27:43 EST." <199511142127.AA05632@interlock.ans.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 14 Nov 1995 17:50:29 -0500 From: "Perry E. Metzger" Stephen Kent writes: > I respectfully disagree with your conclusions re use of PGP > certificates with Photuris. While PGP is the most widely used secure email > protocol in the Internet, its use is not all that widespread in the "grand > scheme of things." Steve; I would suggest that X.509 certificates are also not widespread in the "grand scheme of things" and require a horrifying X.500 infrastructure for real world use -- an infrastructure that most people are unwilling to deploy -- and require the use of distinguished names which, for better or worse, are have proven unacceptable to the internet community. I, for one, would be happy to sit down around the virtual (or real) table with a bunch of other people in who have an interest in this and come up with a clean, "internet compatible" certificate format and infrastructure. I know that Don Eastlake was starting work on such a thing. Rather than trying to beat the dead X.509 horse, perhaps the concerned parties could all get into a dialog going. Perry From ipsec-request@ans.net Tue Nov 14 23:09:06 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15537 (5.65c/IDA-1.4.4 for ); Tue, 14 Nov 1995 18:18:34 -0500 Received: by interlock.ans.net id AA09502 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Nov 1995 18:12:43 -0500 Message-Id: <199511142312.AA09502@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 14 Nov 1995 18:12:43 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 14 Nov 1995 18:12:43 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Nov 1995 18:12:43 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Nov 1995 18:12:43 -0500 Sender: Charles Watt Subject: Re: editorial on Photuris To: perry@piermont.com Date: Tue, 14 Nov 1995 18:09:06 -0500 (EST) From: Charles Watt Cc: kent@bbn.com, rja@cs.nrl.navy.mil, watt@sware.com, ipsec@ans.net In-Reply-To: <199511142250.RAA06053@jekyll.piermont.com> from "Perry E. Metzger" at Nov 14, 95 05:50:29 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1875 -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-Certificate: MIIBvzCCAWkCEFmOln6ip0w49CuyWr9vDVUwDQYJKoZIhvcNAQECBQAwWTELMAkG A1UEBhMCVVMxGDAWBgNVBAoTD1NlY3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2Vj dXJlV2FyZSBQQ0ExFzAVBgNVBAsTDkVuZ2luZWVyaW5nIENBMB4XDTk1MDUwODIw MjMzNVoXDTk3MDUwNzIwMjMzNVowcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1Nl Y3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2VjdXJlV2FyZSBQQ0ExFzAVBgNVBAsT DkVuZ2luZWVyaW5nIENBMRUwEwYDVQQDEwxDaGFybGVzIFdhdHQwWTAKBgRVCAEB AgICBANLADBIAkEM2ZSp7b6eqDqK5RbPFpd6DGSLjbpHOZU07pUcdgJXiduj9Ytf 1rsmf/adaplQr+X5FeoIdT/bVSv2MUi3gY0eFwIDAQABMA0GCSqGSIb3DQEBAgUA A0EApEjzeBjiSnGImJXgeY1K8HWSufpJ2DpLBF7DYqqIVAX9H7gmfOJhfeGEYVjK aTxjgASxqHhzkx7PkOnL4JrN+Q== MIC-Info: RSA-MD5,RSA, AvLciATbk4mV7/EpUcDsscG1TV3xO3iodlu+VvoJp6PmyoEW0ApR0mGjgJvGvOwn 0c85EO8nXZTPp1oZ1zSfuvI= > > > Stephen Kent writes: > > I respectfully disagree with your conclusions re use of PGP > > certificates with Photuris. While PGP is the most widely used secure email > > protocol in the Internet, its use is not all that widespread in the "grand > > scheme of things." > > Steve; > > I would suggest that X.509 certificates are also not widespread in the > "grand scheme of things" and require a horrifying X.500 infrastructure > for real world use -- an infrastructure that most people are unwilling > to deploy -- and require the use of distinguished names which, for > better or worse, are have proven unacceptable to the internet > community. ... > > Perry Perry: The use of X.509 certificates in no way requires an X.500 infrastructure. Nor does the use of DNs ever have to be presented at the user or application level. For a very clean solution to the problem check out our HannaH product at http://www.secureware.com/. But as I've previously stated, this argument is being made out of turn. Photuris can be completely specified to support user level keying without any mention of PGP, X.509 or any other mechanism for binding a "name" to a key. Let's fix it first so it provides the support we need, advance it along the standards track, and then have the naming/certification Jihad. Support for user level keying should be a straight forward extension to what is currently present in the spec. Rather than a single identification field, have two, one identifying the local principal, one identifying the remote principal, if known. If the semantics are properly defined, the remote identification field could: - name the targeted principal - specify something more vague, such as "the principal on port #" - be absent, defaulting to the current behaviour of implying that the principal is the remote host. Charles Watt SecureWare -----END PRIVACY-ENHANCED MESSAGE----- From ipsec-request@ans.net Tue Nov 14 23:38:14 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18903 (5.65c/IDA-1.4.4 for ); Tue, 14 Nov 1995 18:40:17 -0500 Received: by interlock.ans.net id AA09995 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Nov 1995 18:37:45 -0500 Message-Id: <199511142337.AA09995@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Nov 1995 18:37:45 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Nov 1995 18:37:45 -0500 X-Sender: kent@eudora.bbn.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 14 Nov 1995 18:38:14 -0500 To: perry@piermont.com From: Stephen Kent Subject: Re: editorial on Photuris Cc: ipsec@ans.net Perry, You are right that X.509 also is not widespread in its deployment, in "the grand scheme of things," even though there are several million users in X.500 directories (on a worldwide basis). However, your comment about the "horrifying infrastructure" associated with X.509 seems ill founded. Perhaps you are referring to the certification hierarchy defined in RFC 1422, but that model is not equivalent to X.509. The use of X.500 DSAs to store certificates also is not strictly required to use X.509 certificates, any directory scheme will suffice. This is a requirement for any certificate scheme, at least to the extent that one needs to acquire certificates and CRLs by a means other than real time exchange. However, for IP security, realtime exchange might be adequate, unlike in email contexts. The one point I will concede from your criticism is that X.509 certificates do require the use of DNs as the base naming model, even though version 3 certificates also accommodate other name forms, e.g., DNS names. Yes, we could define an Internet certificate, but do we need to? My suggestion, seconding Charlie's, was to not make Photuris dependent on a specific certificate format, but to accommodate multiple formats. I still think that's a useful idea. Steve From ipsec-request@ans.net Tue Nov 14 21:30:05 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12559 (5.65c/IDA-1.4.4 for ); Tue, 14 Nov 1995 21:18:01 -0500 Received: by interlock.ans.net id AA12298 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Nov 1995 21:15:16 -0500 Message-Id: <199511150215.AA12298@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Nov 1995 21:15:16 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Nov 1995 21:15:16 -0500 Date: Tue, 14 Nov 95 21:30:05 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: Reporter claiming SKIP... > From: Germano Caronni > Perry E. Metzger wrote: > > My original comments came because I was informed by a reporter that > > there were people from Sun going around claiming that SKIP was > > destined to be *the* standard for IP security and trying to bludgeon > [...] > > Uh. That would be very nasty. Could you please tell me who this guy is? I > would like to talk to him. > I can see where the reporter might have gotten the idea. Aziz's slides (in today's presentation) states: "There was overwhelming consensus for SKIP to become an IETF standards track RFC at the July '95 IETF meeting in Stockholm." No mention that it was a BOF. No mention that it wasn't the working group, or more importantly a steering group final decision. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Wed Nov 15 02:34:34 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18314 (5.65c/IDA-1.4.4 for ); Tue, 14 Nov 1995 22:26:04 -0500 Received: by interlock.ans.net id AA13147 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Nov 1995 22:22:04 -0500 Message-Id: <199511150322.AA13147@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Nov 1995 22:22:04 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Nov 1995 22:22:04 -0500 Date: Wed, 15 Nov 95 02:34:34 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: editorial on Photuris > From: atkinson@itd.nrl.navy.mil (Ran Atkinson) > [My co-chair hat is on] > And therefore I will be particularly explicit: > % I have no idea what you are talking about. PGP is not supported in the > % base spec. > > Then add it now. See recent note from Phil Karn to the IPsec > list agreeing this was OK. > No. Phil said no such thing. He very carefully qualified his comment with "if that's all there is to it". In fact, it's much more complicated. Only certificate techniques required to be supported by all implementations forever are included in the base spec. There is no WG agreement on a particular form of RSA certificate. See recent (and many months of previous) messages. Only a simple MD5 "MAC" is required for initial deployment of Photuris. PGP, PKCS, DNS-SIG and X.509 are not required for correct operation of Photuris. > % It has been thusly revised: > > Either you really don't seem to be willing to cooperate OR you really > don't follow the discussions so far, so I am reluctantly providing > VERY specific guidance on the text. Please go edit accordingly. > I have very carefully followed and participated in the discussion. > % Internet Security protects against threats that come from the > % external network, not from mutually hostile users of the nodes > % themselves. Any secure multi-user operating system MUST be able to > % protect its resources from hostile users, and protect one hostile > % user from damaging the resources controlled by another hostile user. > > Delete above paragraph. > No. This is fundamental to IP Security itself, and this text has been agreed upon by the authors of Photuris. > % When required for secure multi-user environments with discretionary > % access controls, the Photuris Identification can be used to provide > % separate limited authentication from each user of one node when > % communicating with another common node. To provide user-oriented > % keying, the nodes can initiate multiple concurrent Photuris > % exchanges. These may provide separate user Identification from the > % Initiator to the Responder in each direction. > > Rephrase "secure multi-user environments" to "multi-user environments" > in the above. > No. Insecure multi-user environments are not within the scope. > % Each secure multi-user operating system MUST be capable of > % separately maintaining multiple Identification Exchange SPI values > % for each Value Exchange calculated shared-secret. It is the > % responsibility of the Source to internally segregate the > % shared-secret and different session-keys provided per Destination, > % and select an appropriate SPI for each datagram transmission. > > Rephrase "secure multi-user operating system" to "multi-user operating > system" (or if you prefer "multi-user operating systems having > discretionary access controls") in the above. > No. Insecure multi-user environments are not within the scope. > % And in the implementation notes: > > % Successful use of user-oriented keying requires a significant level > % of operating system support. If the operating system has a security > % vulnerability, then there is no basis for separate user-oriented > % keying. > > Delete the word "significant". We built it in BSD already and it is > _NOT_ that hard to do, sorry. > No. While I am glad to hear that all BSD applications suddenly support user-oriented keying without any significant change in API, I look forward to your demonstration of such at Dallas, including source. > % Use of multi-user segregated exchanges likely requires added > % functionality in the transport API of the implementation operating > % system. Such a mechanism is outside the scope of this document. > > Replace "likely" with "might" in the above. > Huh? Bad sentence, does not parse. > % It has been suggested that the Photuris exchange could also be > % established between particular application or transport processes > % associated with a user of a node. Such a mechanism is emphatically > % outside the scope of this document. > > Delete above paragraph. > No. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Wed Nov 15 04:54:33 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17201 (5.65c/IDA-1.4.4 for ); Tue, 14 Nov 1995 23:56:52 -0500 Received: by interlock.ans.net id AA14199 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Nov 1995 23:53:46 -0500 Message-Id: <199511150453.AA14199@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 14 Nov 1995 23:53:46 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Nov 1995 23:53:46 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Nov 1995 23:53:46 -0500 Date: Tue, 14 Nov 1995 21:54:33 -0700 From: Hilarie Orman To: bsimpson@morningstar.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <199511150322.AA13147@interlock.ans.net> Subject: Re: editorial on Photuris The phrase "secure multi-user OS" isn't what you mean, it's too ambiguous. Something like "strong suport for discretionary access control based on user ids" is closer to the point, or at least it's closer to the point that I think you are making. Bringing OS security into the discussion seems troublesome. From ipsec-request@ans.net Wed Nov 15 04:58:42 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18043 (5.65c/IDA-1.4.4 for ); Wed, 15 Nov 1995 02:21:17 -0500 Received: by interlock.ans.net id AA16212 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Nov 1995 02:17:11 -0500 Message-Id: <199511150717.AA16212@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Nov 1995 02:17:11 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Nov 1995 02:17:11 -0500 Date: Wed, 15 Nov 95 04:58:42 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: SKIP fails anonymity > Date: 14 Nov 95 11:22:25 -0800 > From: "PALAMBER.US.ORACLE.COM" > Subject: WG Last Call for SKIP I-D > SKIP fails to provide adequate anonymity. In order to scale, SKIP certificates will need to be widely available, making it easy to compile a world-wide database. The name space must be searchable for deployment to scale. Use of a hash, public-value, or other index to identify the master key is easily searched among all known master certificates. The type of certificate used is transparently identified in the SKIP header. Protection of anonymity by private manual configuration and/or assuming very large and unsearchable name spaces (page 15) is unacceptable. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Wed Nov 15 05:39:25 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18816 (5.65c/IDA-1.4.4 for ); Wed, 15 Nov 1995 02:21:18 -0500 Received: by interlock.ans.net id AA16226 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Nov 1995 02:17:16 -0500 Message-Id: <199511150717.AA16226@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Nov 1995 02:17:16 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Nov 1995 02:17:16 -0500 Date: Wed, 15 Nov 95 05:39:25 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: SKIP wastes bandwidth > Date: 14 Nov 95 11:22:25 -0800 > From: "PALAMBER.US.ORACLE.COM" > Subject: WG Last Call for SKIP I-D > SKIP headers range from 28 to 60 bytes, not including the IP Security headers (only 4 to 8 bytes). SKIP trades "zero-message" initialization with manual configuration -- or a few "optional" certificate discovery messages otherwise -- for continuous bandwidth degradation on every datagram. The Internet Protocol Security Working Group spent considerable time in designing the ESP and AH headers to be as small as possible. Considering that the average TCP payload is 13 bytes, and the average IP datagram is 124 or so bytes, bloating every datagram by an extra 50% to 200% is unacceptable. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Wed Nov 15 05:28:41 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17285 (5.65c/IDA-1.4.4 for ); Wed, 15 Nov 1995 02:21:22 -0500 Received: by interlock.ans.net id AA16218 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Nov 1995 02:17:14 -0500 Message-Id: <199511150717.AA16218@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Nov 1995 02:17:14 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Nov 1995 02:17:14 -0500 Date: Wed, 15 Nov 95 05:28:41 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: SKIP has no Perfect Forward Secrecy > Date: 14 Nov 95 11:22:25 -0800 > From: "PALAMBER.US.ORACLE.COM" > Subject: WG Last Call for SKIP I-D > SKIP admittedly does not provide "perfect forward secrecy" (back traffic protection). While it may be that authenticated traffic does not require this protection in certain instances (which are debatable), it is "a desirable and appealing goal" for privacy. SKIP lack of this protection for encryption is unacceptable. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Wed Nov 15 06:07:21 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18823 (5.65c/IDA-1.4.4 for ); Wed, 15 Nov 1995 02:21:22 -0500 Received: by interlock.ans.net id AA16232 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Nov 1995 02:17:20 -0500 Message-Id: <199511150717.AA16232@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Nov 1995 02:17:20 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Nov 1995 02:17:20 -0500 Date: Wed, 15 Nov 95 06:07:21 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: SKIP insecure > Date: 14 Nov 95 11:22:25 -0800 > From: "PALAMBER.US.ORACLE.COM" > Subject: WG Last Call for SKIP I-D > SKIP exhibits several serious insecurities. The SKIP master keys are extremely long term. No matter how many "reasonable safeguards", long term storage of keys carries a significant security risk. This problem has long been recognized for KDCs. The SKIP master keys are maintained on multiple systems. Although this may be appealing for rapid "fail-over and load-balancing", and "intermediate authentication", there is no IP Security requirement for these features. Every node that has the duplicate master keys is another potential security risk. This makes the security risk even worse than KDCs. The SKIP public-values are signed, but the generated session-keys are not signed. Current literature suggests that _both_ the public values and resulting session-keys be signed to prevent attacks. The signature operation is not known to be associative or commutative. These SKIP risks and vulnerabilities are unacceptable. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Wed Nov 15 02:59:34 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15497 (5.65c/IDA-1.4.4 for ); Wed, 15 Nov 1995 02:21:22 -0500 Received: by interlock.ans.net id AA16206 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Nov 1995 02:17:08 -0500 Message-Id: <199511150717.AA16206@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Nov 1995 02:17:08 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Nov 1995 02:17:08 -0500 Date: Wed, 15 Nov 95 02:59:34 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: SKIP fails anti-clogging > Date: 14 Nov 95 11:22:25 -0800 > From: "PALAMBER.US.ORACLE.COM" > Subject: WG Last Call for SKIP I-D > SKIP fails to provide adequate anti-clogging, at the protocol, computational and resource levels. SKIP also lacks graceful recovery mechanisms. For example, a WWW server which accepts traffic from arbitrary clients is easily clogged. As this is a principle application, such a failing is unacceptable. Whenever a packet arrives with a master-key for which it does not have the certificate precalculated, SKIP locates a certificate (requiring a certificate protocol exchange) and calculates a Modular Exponentiation. When SKIP scales to hundreds (or millions) of nodes, it will be a simple matter to completely swamp the target by sending a perfectly valid SKIP header with each of the world-wide master identifying numbers, triggering a search for the certificate, validation of the certificate signature, and calculation of the shared-secret. This is unacceptably protocol inefficient, as it generates a large number of extraneous certificate query exchanges. This is unacceptably computationally expensive, as the signature and shared-secret (Kijn) are calculated. The storage cache can easily be overflowed, likely causing loss of storage for other applications. In the even of loss of cache, this requires recalculation of other valid traffic master-keys -- yet another additional computational expense -- possibly resulting in lost traffic. This problem is due to the tremendous amount of long-term stored state required by SKIP, and the lack of LifeTime. Recovery (as stated in the draft) requires manual intervention by the system administrator to add each valid user to a "pre-compute cache". This is unacceptable. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Wed Nov 15 13:04:29 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18308 (5.65c/IDA-1.4.4 for ); Wed, 15 Nov 1995 08:16:12 -0500 Received: by interlock.ans.net id AA19085 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Nov 1995 08:06:04 -0500 Message-Id: <199511151306.AA19085@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Nov 1995 08:06:04 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Nov 1995 08:06:04 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: Charles Watt Cc: kent@bbn.com, rja@cs.nrl.navy.mil, ipsec@ans.net Subject: Re: editorial on Photuris In-Reply-To: Your message of "Tue, 14 Nov 1995 18:09:06 EST." <9511142309.AA19895@mordred.sware.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 15 Nov 1995 08:04:29 -0500 From: "Perry E. Metzger" Charles Watt writes (in response to me): > > Steve; > > > > I would suggest that X.509 certificates are also not widespread in the > > "grand scheme of things" and require a horrifying X.500 infrastructure > > for real world use -- an infrastructure that most people are unwilling > > to deploy -- and require the use of distinguished names which, for > > better or worse, are have proven unacceptable to the internet > > community. > > The use of X.509 certificates in no way requires an X.500 infrastructure. Nor does the use of bicycles require pneumatic tires, but they do make the thing much more pleasant. If you can't look up things by DN the situation becomes sticky fast. > Nor does the use of DNs ever have to be presented at the user or > application level. No, but again, things get ugly if what one is binding isn't what the user cares about. I understand that many of you folks have an emotional commitment to X.509, but I'll be blunt -- a good 60% of the IETF is totally opposed to the stuff, and another 20% will use it only with the greatest possible reluctance. You've probably spent most of your time with the 10% that are merely unhappy with the the thing and the 10% who actually like them. > But as I've previously stated, this argument is being made out of turn. > Photuris can be completely specified to support user level keying without > any mention of PGP, X.509 or any other mechanism for binding a "name" to > a key. I'd prefer to ignore the issue of whether or not that is possible and get back to my original point -- I think we will need, at some point, a certificate format. X.509 is unacceptable to the community. I'd like to invite the "smart people" around these parts to start working together to try to produce a good alternative. Perry From ipsec-request@ans.net Wed Nov 15 13:22:22 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17065 (5.65c/IDA-1.4.4 for ); Wed, 15 Nov 1995 08:37:41 -0500 Received: by interlock.ans.net id AA20081 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Nov 1995 08:22:37 -0500 Message-Id: <199511151322.AA20081@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Nov 1995 08:22:37 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Nov 1995 08:22:37 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: Stephen Kent Cc: ipsec@ans.net Subject: Re: editorial on Photuris In-Reply-To: Your message of "Tue, 14 Nov 1995 18:38:14 EST." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 15 Nov 1995 08:22:22 -0500 From: "Perry E. Metzger" Stephen Kent writes: > Yes, we could define an Internet certificate, but do we need to? > My suggestion, seconding Charlie's, was to not make Photuris dependent on a > specific certificate format, but to accommodate multiple formats. I still > think that's a useful idea. Regardless of whether Photuris can use multiple formats, or whether or not we define what format it uses any time soon, the fact remains that we will need a certificate format at some point, and that the bulk of the internet community doesn't like X.509 for all sorts of reasons -- good or bad is almost immaterial at this point. It would therefore be useful for those people who have experience with this matter, such as yourself, and others who are active in the community and have an interest, to work on producing a simplified and more internet-acceptable format. Perry From ipsec-request@ans.net Wed Nov 15 14:00:55 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13570 (5.65c/IDA-1.4.4 for ); Wed, 15 Nov 1995 09:18:22 -0500 Received: by interlock.ans.net id AA20578 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Nov 1995 09:03:23 -0500 Message-Id: <199511151403.AA20578@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Nov 1995 09:03:23 -0500 From: Ran Atkinson Date: Wed, 15 Nov 1995 09:00:55 -0500 In-Reply-To: "Perry E. Metzger" "Re: editorial on Photuris" (Nov 15, 8:04) References: <199511151304.IAA07921@jekyll.piermont.com> Reply-To: rja@cs.nrl.navy.mil X-Mailer: Z-Mail (3.2.1 10apr95) To: perry@piermont.com, Charles Watt Subject: Re: editorial on Photuris Cc: kent@bbn.com, rja@cs.nrl.navy.mil, ipsec@ans.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: rja@bodhi.cs.nrl.navy.mil Perry, Regardless of whether some folks have strong objections to X.509, there DOES exist a community of interest that wants to use it. There are known technical problems with putting X.509 into the DNS, hence DNS certificates are not X.509 format (neither are they PGP). It is legitimate for folks in the IPsec WG to work on adding X.509 support as extensions to the various key mgmt proposals. However, in my view the burden of producing the specific text changes desired for such X.509 support is on those folks who wish to use X.509. If the document editors are not provided with fairly specific comments on what changes are desired and why they are desired, then I cannot fault the editors. (The same principle on proposing specific text changes to drafts actually is widely true within the IETF). Ran rja@cs.nrl.navy.mil From ipsec-request@ans.net Wed Nov 15 14:28:22 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12072 (5.65c/IDA-1.4.4 for ); Wed, 15 Nov 1995 09:39:26 -0500 Received: by interlock.ans.net id AA21093 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Nov 1995 09:28:31 -0500 Message-Id: <199511151428.AA21093@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Nov 1995 09:28:31 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Nov 1995 09:28:31 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: rja@cs.nrl.navy.mil Cc: kent@bbn.com, ipsec@ans.net Subject: Re: editorial on Photuris In-Reply-To: Your message of "Wed, 15 Nov 1995 09:00:55 EST." <9511150900.ZM15211@bodhi> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 15 Nov 1995 09:28:22 -0500 From: "Perry E. Metzger" Ran Atkinson writes: > Regardless of whether some folks have strong objections to X.509, > there DOES exist a community of interest that wants to use it. There > are known technical problems with putting X.509 into the DNS, hence > DNS certificates are not X.509 format (neither are they PGP). > > It is legitimate for folks in the IPsec WG to work on adding X.509 > support as extensions to the various key mgmt proposals. I'm not arguing against that at all. I'm arguing something entirely different -- that it is time for us to work on a simplified certificate format. This is something that needs doing quite apart from the specific considerations of Photuris, MOSS, or whatever else might want to use such certificates. I realize that such a format isn't going to be ready soon and that work can't be delayed to work on it, and that people will want to use other formats as well. Perry From ipsec-request@ans.net Wed Nov 15 15:18:38 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18305 (5.65c/IDA-1.4.4 for ); Wed, 15 Nov 1995 10:19:55 -0500 Received: by interlock.ans.net id AA22517 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Nov 1995 10:15:25 -0500 Message-Id: <199511151515.AA22517@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 15 Nov 1995 10:15:25 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 15 Nov 1995 10:15:25 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Nov 1995 10:15:25 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Nov 1995 10:15:25 -0500 Sender: Charles Watt Subject: Re: editorial on Photuris To: perry@piermont.com Date: Wed, 15 Nov 1995 10:18:38 -0500 (EST) From: Charles Watt Cc: ipsec@ans.net In-Reply-To: <199511151304.IAA07921@jekyll.piermont.com> from "Perry E. Metzger" at Nov 15, 95 08:04:29 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 3623 -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-Certificate: MIIBvzCCAWkCEFmOln6ip0w49CuyWr9vDVUwDQYJKoZIhvcNAQECBQAwWTELMAkG A1UEBhMCVVMxGDAWBgNVBAoTD1NlY3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2Vj dXJlV2FyZSBQQ0ExFzAVBgNVBAsTDkVuZ2luZWVyaW5nIENBMB4XDTk1MDUwODIw MjMzNVoXDTk3MDUwNzIwMjMzNVowcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1Nl Y3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2VjdXJlV2FyZSBQQ0ExFzAVBgNVBAsT DkVuZ2luZWVyaW5nIENBMRUwEwYDVQQDEwxDaGFybGVzIFdhdHQwWTAKBgRVCAEB AgICBANLADBIAkEM2ZSp7b6eqDqK5RbPFpd6DGSLjbpHOZU07pUcdgJXiduj9Ytf 1rsmf/adaplQr+X5FeoIdT/bVSv2MUi3gY0eFwIDAQABMA0GCSqGSIb3DQEBAgUA A0EApEjzeBjiSnGImJXgeY1K8HWSufpJ2DpLBF7DYqqIVAX9H7gmfOJhfeGEYVjK aTxjgASxqHhzkx7PkOnL4JrN+Q== MIC-Info: RSA-MD5,RSA, CROdd/Q6nEYM6VFEP0Ya94XIVhzjrbXEmeYjLZ3EcUrls8v/4AenzWOxef/w1g8S +5Q6DaUoZqx/8rURLeMR6sc= Recent comments by Perry and Ran underscore the primary problem with the IETF process in its current state of near anarchy (please Perry and Ran, do not take this as a personal comment, it is simply meant as an observation of the process as a whole) -- if there is a group responsible for overall architecture and direction, none of the working groups seem to be aware of this or follow its recommendations. If I understand the two of you correctly, you share an implicit assumption that IP security requires a roll-your-own certificate based on domain names and stored in DNS. Well, the public key infrastructure and web security groups are independently working on infrastructures to support electronic commerce. They are competing against similar proposals from a wide variety of individual companies and commercial groups including Netscape, Visa, Microsoft, Mastercard and others. All of these proposals are based on X.509 certificates or some close variant. All of these groups have significantly more influence when it comes to final deployment of applications and end systems than the IETF. The web-based and electronic commerce applications are significant contributors to the recent explosive growth in the Internet. A sizeable percentage of all systems on the net ALREADY USE X.509 for some applications -- this will soon be a majority of all systems if the current growth rates for various applications continue. I'm sure it will come as a shock to Perry, but I have a strong dislike for ASN.1, X.509 certificates and DNs. But I am enough of a pragmatist to understand that not only will they not go away, they will soon be universally deployed within certain applications. I also understand that developing, maintaining and administering two parallel infrastructures is more complex and expensive than supporting just one, and that selling the second infrastructure to a customer that already has the first will be difficult. I also have sufficient experience developing and installing secure systems to foresee that: - domain names (without semantic extensions) provide insufficient flexibility to adequately identify the full variety of principals (users, hosts, printers, fax servers, etc...) that will require strong I&A in the future - if we clutter the DNS with all the additional information required to support a fully developed, distributed, secure infrastructure, it will look remarkably like an X.500 Directory Service. > > Nor does the use of DNs ever have to be presented at the user or > > application level. > > No, but again, things get ugly if what one is binding isn't what the > user cares about. True, but to the user neither: Charles.Watt@sware.com sware.com ga.gov nor CN=Charles Watt, O=SecureWare, C=US O=SecureWare, C=US O=Georgia Certificate Authority, C=US are as effective as a more formatted display. If you need to reformat anyway, what's the difference? > I'd prefer to ignore the issue of whether or not that is possible and > get back to my original point -- I think we will need, at some point, > a certificate format. X.509 is unacceptable to the community. I'd like > to invite the "smart people" around these parts to start working > together to try to produce a good alternative. It would not be difficult to come up with a better certificate format than X.509. We need the "smart people" to determine whether doing so is in the best interest of various communities of concern -- end users, developers, etc... -- taking into consideration develops and trends outside of IPSEC. Charles Watt SecureWare -----END PRIVACY-ENHANCED MESSAGE----- From ipsec-request@ans.net Wed Nov 15 16:15:19 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13582 (5.65c/IDA-1.4.4 for ); Wed, 15 Nov 1995 11:28:14 -0500 Received: by interlock.ans.net id AA24126 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Nov 1995 11:16:17 -0500 Message-Id: <199511151616.AA24126@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Nov 1995 11:16:17 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Nov 1995 11:16:17 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: Charles Watt Cc: ipsec@ans.net Subject: Re: editorial on Photuris In-Reply-To: Your message of "Wed, 15 Nov 1995 10:18:38 EST." <9511151518.AA21029@mordred.sware.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 15 Nov 1995 11:15:19 -0500 From: "Perry E. Metzger" Charles Watt writes: > Recent comments by Perry and Ran underscore the primary problem with > the IETF process in its current state of near anarchy (please Perry and > Ran, do not take this as a personal comment, it is simply meant as an > observation of the process as a whole) -- if there is a group responsible > for overall architecture and direction, none of the working groups seem > to be aware of this or follow its recommendations. This is a feature, not a bug. There is a reason that the ISO has been unable to achieve our success. I suppose I'm an anarchist. Let a thousand flowers bloom. > If I understand the two of you correctly, you share an implicit > assumption that IP security requires a roll-your-own certificate > based on domain names and stored in DNS. I will not comment on Ran's assumptions. My assumptions are that X.509 is a failure that I don't want to touch, and I'm interested in seeing something clean and simple replace it. Nothing is "required". Hell, breathing isn't "required". > They are competing against similar proposals from a wide variety of > individual companies and commercial groups including Netscape, Visa, > Microsoft, Mastercard and others. All of these proposals are based on > X.509 certificates or some close variant. None of them are wedded to X.509 certificates. If an alternatives showed up, they would probably be adopted. > The web-based and electronic commerce applications are significant > contributors to the recent explosive growth in the Internet. A sizeable > percentage of all systems on the net ALREADY USE X.509 for some > applications If you are refering to SSL, it uses certificates only in the most basic possible sense. There is no distribution mechanism for them -- they are hardcoded in to netscape -- and there is almost no use of the X.509 facilities, and there are no user certificates. I doubt that it would change Netscape's life significantly if they switched to any other certificate. > I'm sure it will come as a shock to Perry, but I have a strong dislike > for ASN.1, X.509 certificates and DNs. But I am enough of a pragmatist > to understand that not only will they not go away, they will soon be > universally deployed within certain applications. I don't agree. I think that they are pretty much only going to succeed if no alternative shows up, so I intend to see an alternative show up. > - if we clutter the DNS with all the additional information > required to support a fully developed, distributed, secure > infrastructure, it will look remarkably like an X.500 > Directory Service. I'm afraid that we already have a proposal for embedding certificates in the DNS that doesn't make it look like X.500. Don't assume everyone is as incapable of producing a clean and simple solution as the ISO. Perry From ipsec-request@ans.net Wed Nov 15 17:25:23 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18310 (5.65c/IDA-1.4.4 for ); Wed, 15 Nov 1995 12:27:28 -0500 Received: by interlock.ans.net id AA25923 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Nov 1995 12:22:13 -0500 Message-Id: <199511151722.AA25923@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 15 Nov 1995 12:22:13 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 15 Nov 1995 12:22:13 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Nov 1995 12:22:13 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Nov 1995 12:22:13 -0500 Sender: Charles Watt Subject: Re: editorial on Photuris To: perry@piermont.com Date: Wed, 15 Nov 1995 12:25:23 -0500 (EST) From: Charles Watt Cc: watt@sware.com, ipsec@ans.net In-Reply-To: <199511151615.LAA08150@jekyll.piermont.com> from "Perry E. Metzger" at Nov 15, 95 11:15:19 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1381 -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-Certificate: MIIBvzCCAWkCEFmOln6ip0w49CuyWr9vDVUwDQYJKoZIhvcNAQECBQAwWTELMAkG A1UEBhMCVVMxGDAWBgNVBAoTD1NlY3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2Vj dXJlV2FyZSBQQ0ExFzAVBgNVBAsTDkVuZ2luZWVyaW5nIENBMB4XDTk1MDUwODIw MjMzNVoXDTk3MDUwNzIwMjMzNVowcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1Nl Y3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2VjdXJlV2FyZSBQQ0ExFzAVBgNVBAsT DkVuZ2luZWVyaW5nIENBMRUwEwYDVQQDEwxDaGFybGVzIFdhdHQwWTAKBgRVCAEB AgICBANLADBIAkEM2ZSp7b6eqDqK5RbPFpd6DGSLjbpHOZU07pUcdgJXiduj9Ytf 1rsmf/adaplQr+X5FeoIdT/bVSv2MUi3gY0eFwIDAQABMA0GCSqGSIb3DQEBAgUA A0EApEjzeBjiSnGImJXgeY1K8HWSufpJ2DpLBF7DYqqIVAX9H7gmfOJhfeGEYVjK aTxjgASxqHhzkx7PkOnL4JrN+Q== MIC-Info: RSA-MD5,RSA, DIZJ+gls3W4AmocMnqiFawculyJHcfrMSDPszIWsv8tUlX3V4vDGPPi2Bok5fMqD dvyTM6rFgNudVZ3V2pbAKIo= > > - if we clutter the DNS with all the additional information > > required to support a fully developed, distributed, secure > > infrastructure, it will look remarkably like an X.500 > > Directory Service. > > I'm afraid that we already have a proposal for embedding certificates > in the DNS that doesn't make it look like X.500. Don't assume everyone > is as incapable of producing a clean and simple solution as the ISO. I'm not making this particular assumption. My assumption is that you are short sighted -- slam in certificates and our security problems are solved. Well, I would like this infrastructure to be useful for more than IP security, say for Electronic Commerce. This means that you need LOTS more stuff, like the CA's policy statement, a pointer to the CA's real-time electronic notary, the authorizations granted to me by my employer for EDI transactions, etc... DNS bloat == X.500. As these issues have no relevance to Photuris, the Photuris spec should be independent of the mechanism binding name and key. This frees you and your "smart people" to go off and design your new public key infrastructure. Please spend some time researching the larger requirements for such an infrastructure first. You might also touch base with the pkix working group, they seem to think that this infrastructure is their charter. Charles Watt SecureWare -----END PRIVACY-ENHANCED MESSAGE----- From ipsec-request@ans.net Wed Nov 15 17:39:40 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13735 (5.65c/IDA-1.4.4 for ); Wed, 15 Nov 1995 12:46:23 -0500 Received: by interlock.ans.net id AA26317 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Nov 1995 12:41:21 -0500 Message-Id: <199511151741.AA26317@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 15 Nov 1995 12:41:21 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 15 Nov 1995 12:41:21 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Nov 1995 12:41:21 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Nov 1995 12:41:21 -0500 X-Mailer: exmh version 1.6.3 10/3/95 X-Face: +o^+u7Z5}dB^gVlCgr.W/thrVG>63+@L&~6W3um$qzdHEf*o^b4g'.>AF*9jO,@sw.~gu*+ !Ld4U(yvY'QL7ZSB#r3zb[pTsR0K5ZHDs5.8'w.'$u(o;imk*Z-.g)V|2a-KM-waTKUvx'xM>xOlZL E=ghh49p2h$1`Vp&rOtYlnm{|ixN#45yL)*j$3>QbmWu-[)Nw;^P53@cMO[P#Q>k3Ut)?Vh^`IJYvB ZdB[z`5aM4Z"wW@l~~iWw0MY^%F$mP)~F\lBcgj`h^hOvIp< X-Uri: http://www.milkyway.com/People/Michael_Richardson/Bio.html To: rja@cs.nrl.navy.mil, ipsec@ans.net Subject: Re: editorial on Photuris References: <199511151304.IAA07921@jekyll.piermont.com> <199511151403.AA20578@interlock.ans.net> In-Reply-To: Your message of "Wed, 15 Nov 1995 09:00:55 EST." <199511151403.AA20578@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Nov 1995 12:39:40 -0500 From: Michael Richardson > It is legitimate for folks in the IPsec WG to work on adding X.509 > support as extensions to the various key mgmt proposals. However, in > my view the burden of producing the specific text changes desired for > such X.509 support is on those folks who wish to use X.509. If the The primary situation I see where X.509 certificates would be used would be when integrating with a GSSAPI that used X.509 certificates (e.g. Entrust). In this case, the key management would be taken care of by the GSSAPI already. (And may not even allow one to access to they keying routines. I am about to look and see if it is even possible to deal with out of order encrypted packets!) I would envision GSSAPIs being selected at the ESP/AH level, not at the keying layer. From ipsec-request@ans.net Wed Nov 15 18:57:22 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18230 (5.65c/IDA-1.4.4 for ); Wed, 15 Nov 1995 14:04:30 -0500 Received: by interlock.ans.net id AA00875 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Nov 1995 13:57:35 -0500 Message-Id: <199511151857.AA00875@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Nov 1995 13:57:35 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Nov 1995 13:57:35 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: Charles Watt Cc: ipsec@ans.net Subject: Re: editorial on Photuris In-Reply-To: Your message of "Wed, 15 Nov 1995 12:25:23 EST." <9511151725.AA21236@mordred.sware.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 15 Nov 1995 13:57:22 -0500 From: "Perry E. Metzger" Charles Watt writes: > > I'm afraid that we already have a proposal for embedding certificates > > in the DNS that doesn't make it look like X.500. Don't assume everyone > > is as incapable of producing a clean and simple solution as the ISO. > > I'm not making this particular assumption. My assumption is that you > are short sighted -- slam in certificates and our security problems > are solved. Well, I would like this infrastructure to be useful for > more than IP security, say for Electronic Commerce. This means that > you need LOTS more stuff, like the CA's policy statement, a pointer to > the CA's real-time electronic notary, the authorizations granted to me > by my employer for EDI transactions, etc... DNS bloat == X.500. None of that stuff at all needs to be in the DNS qua DNS -- you just need to be able to find it. Incidently, the problems with X.500 stem from its design and not from the amount of content. > As these issues have no relevance to Photuris, the Photuris spec should > be independent of the mechanism binding name and key. I've already said that. This is another topic. > You might also touch base with the pkix working > group, they seem to think that this infrastructure is their charter. I monitor their discussions. They are running on the assumption everyone loves X.509, so it isn't clear that they are going to actually get anywhere. IETF groups that don't have widespread community support often end up with no one listening -- which is as it should be. Perry From ipsec-request@ans.net Wed Nov 15 03:24:16 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13703 (5.65c/IDA-1.4.4 for ); Wed, 15 Nov 1995 14:32:43 -0500 Received: by interlock.ans.net id AA02003 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Nov 1995 14:22:07 -0500 Message-Id: <199511151922.AA02003@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 15 Nov 1995 14:22:07 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 15 Nov 1995 14:22:07 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Nov 1995 14:22:07 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Nov 1995 14:22:07 -0500 X-Received: from red-16-msg by xnet2 with receive; Wed, 15 Nov 1995 11:21:36 -0800 X-Msmail-Message-Id: 5C028ED0 X-Msmail-Conversation-Id: 5C028ED0 From: Paul Leach To: ipsec-request@ans.net, perry@piermont.com Date: Wed, 15 Nov 95 11:24:16 PST Subject: Re: editorial on Photuris Cc: ipsec@ans.net X-Msxmtid: red-16-msg951115192117MTP[01.51.01]000000a1-196035 Charles said: ] True, but to the user neither: ] ] Charles.Watt@sware.com ] sware.com ] ga.gov ] ] nor ] CN=Charles Watt, O=SecureWare, C=US ] O=SecureWare, C=US ] O=Georgia Certificate Authority, C=US ] ] are as effective as a more formatted display. If you need to reformat ] anyway, what's the difference? ] Reformatting for UI purposes is not the issue. If I make a connection to www.sware.com using (e.g.) SSL or PCT, and the certificate comes back and proves I've just contacted "O=SecureWare, C=US", have I contacted the correct server, or not? I can't determine this automatically in my browser (or better yet, in the secure connection layer), and if the user is relied upon to decide, then if I'm a spoofer, I'll for sure pick a name that is as close as possible to the one I'm spoofing so as to fool users into saying that it is the name to which they were trying to connect. My principle: if you're making a secure connection to a DNS-named entity, then the certificate MUST bind its DNS name to its key. (Something that can be trivially and algorithmically mapped to a DNS name would be OK -- but I've never seen anyone present an X.509 example, real or hypothetical, where that's true. One post to this list (or pkix -- I forget) showed the DN in a Verisign certificate of a real SSL-using web site, and the relation between its DN and it DNS name was not even as close as Charles' example above. The DN named the parent corporation of the entity that ran the web site...) From ipsec-request@ans.net Wed Nov 15 15:18:38 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12218 (5.65c/IDA-1.4.4 for ); Wed, 15 Nov 1995 15:03:28 -0500 Message-Id: <199511152003.AA12218@ftp.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@ftp.ans.net); Wed, 15 Nov 1995 14:58:35 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 15 Nov 1995 14:58:35 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 15 Nov 1995 14:58:35 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Nov 1995 14:58:35 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Nov 1995 14:58:35 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Wed, 15 Nov 1995 14:58:35 -0500 Sender: Charles Watt Subject: Re: editorial on Photuris To: perry@piermont.com Date: Wed, 15 Nov 1995 10:18:38 -0500 (EST) From: Charles Watt Cc: ipsec@ans.net In-Reply-To: <199511151304.IAA07921@jekyll.piermont.com> from "Perry E. Metzger" at Nov 15, 95 08:04:29 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 3623 -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-Certificate: MIIBvzCCAWkCEFmOln6ip0w49CuyWr9vDVUwDQYJKoZIhvcNAQECBQAwWTELMAkG A1UEBhMCVVMxGDAWBgNVBAoTD1NlY3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2Vj dXJlV2FyZSBQQ0ExFzAVBgNVBAsTDkVuZ2luZWVyaW5nIENBMB4XDTk1MDUwODIw MjMzNVoXDTk3MDUwNzIwMjMzNVowcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1Nl Y3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2VjdXJlV2FyZSBQQ0ExFzAVBgNVBAsT DkVuZ2luZWVyaW5nIENBMRUwEwYDVQQDEwxDaGFybGVzIFdhdHQwWTAKBgRVCAEB AgICBANLADBIAkEM2ZSp7b6eqDqK5RbPFpd6DGSLjbpHOZU07pUcdgJXiduj9Ytf 1rsmf/adaplQr+X5FeoIdT/bVSv2MUi3gY0eFwIDAQABMA0GCSqGSIb3DQEBAgUA A0EApEjzeBjiSnGImJXgeY1K8HWSufpJ2DpLBF7DYqqIVAX9H7gmfOJhfeGEYVjK aTxjgASxqHhzkx7PkOnL4JrN+Q== MIC-Info: RSA-MD5,RSA, CROdd/Q6nEYM6VFEP0Ya94XIVhzjrbXEmeYjLZ3EcUrls8v/4AenzWOxef/w1g8S +5Q6DaUoZqx/8rURLeMR6sc= Recent comments by Perry and Ran underscore the primary problem with the IETF process in its current state of near anarchy (please Perry and Ran, do not take this as a personal comment, it is simply meant as an observation of the process as a whole) -- if there is a group responsible for overall architecture and direction, none of the working groups seem to be aware of this or follow its recommendations. If I understand the two of you correctly, you share an implicit assumption that IP security requires a roll-your-own certificate based on domain names and stored in DNS. Well, the public key infrastructure and web security groups are independently working on infrastructures to support electronic commerce. They are competing against similar proposals from a wide variety of individual companies and commercial groups including Netscape, Visa, Microsoft, Mastercard and others. All of these proposals are based on X.509 certificates or some close variant. All of these groups have significantly more influence when it comes to final deployment of applications and end systems than the IETF. The web-based and electronic commerce applications are significant contributors to the recent explosive growth in the Internet. A sizeable percentage of all systems on the net ALREADY USE X.509 for some applications -- this will soon be a majority of all systems if the current growth rates for various applications continue. I'm sure it will come as a shock to Perry, but I have a strong dislike for ASN.1, X.509 certificates and DNs. But I am enough of a pragmatist to understand that not only will they not go away, they will soon be universally deployed within certain applications. I also understand that developing, maintaining and administering two parallel infrastructures is more complex and expensive than supporting just one, and that selling the second infrastructure to a customer that already has the first will be difficult. I also have sufficient experience developing and installing secure systems to foresee that: - domain names (without semantic extensions) provide insufficient flexibility to adequately identify the full variety of principals (users, hosts, printers, fax servers, etc...) that will require strong I&A in the future - if we clutter the DNS with all the additional information required to support a fully developed, distributed, secure infrastructure, it will look remarkably like an X.500 Directory Service. > > Nor does the use of DNs ever have to be presented at the user or > > application level. > > No, but again, things get ugly if what one is binding isn't what the > user cares about. True, but to the user neither: Charles.Watt@sware.com sware.com ga.gov nor CN=Charles Watt, O=SecureWare, C=US O=SecureWare, C=US O=Georgia Certificate Authority, C=US are as effective as a more formatted display. If you need to reformat anyway, what's the difference? > I'd prefer to ignore the issue of whether or not that is possible and > get back to my original point -- I think we will need, at some point, > a certificate format. X.509 is unacceptable to the community. I'd like > to invite the "smart people" around these parts to start working > together to try to produce a good alternative. It would not be difficult to come up with a better certificate format than X.509. We need the "smart people" to determine whether doing so is in the best interest of various communities of concern -- end users, developers, etc... -- taking into consideration develops and trends outside of IPSEC. Charles Watt SecureWare -----END PRIVACY-ENHANCED MESSAGE----- From ipsec-request@ans.net Wed Nov 15 16:15:19 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17400 (5.65c/IDA-1.4.4 for ); Wed, 15 Nov 1995 15:12:52 -0500 Message-Id: <199511152012.AA17400@ftp.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@ftp.ans.net); Wed, 15 Nov 1995 15:07:34 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Nov 1995 15:07:34 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Nov 1995 15:07:34 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Wed, 15 Nov 1995 15:07:34 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: Charles Watt Cc: ipsec@ans.net Subject: Re: editorial on Photuris In-Reply-To: Your message of "Wed, 15 Nov 1995 10:18:38 EST." <9511151518.AA21029@mordred.sware.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 15 Nov 1995 11:15:19 -0500 From: "Perry E. Metzger" Charles Watt writes: > Recent comments by Perry and Ran underscore the primary problem with > the IETF process in its current state of near anarchy (please Perry and > Ran, do not take this as a personal comment, it is simply meant as an > observation of the process as a whole) -- if there is a group responsible > for overall architecture and direction, none of the working groups seem > to be aware of this or follow its recommendations. This is a feature, not a bug. There is a reason that the ISO has been unable to achieve our success. I suppose I'm an anarchist. Let a thousand flowers bloom. > If I understand the two of you correctly, you share an implicit > assumption that IP security requires a roll-your-own certificate > based on domain names and stored in DNS. I will not comment on Ran's assumptions. My assumptions are that X.509 is a failure that I don't want to touch, and I'm interested in seeing something clean and simple replace it. Nothing is "required". Hell, breathing isn't "required". > They are competing against similar proposals from a wide variety of > individual companies and commercial groups including Netscape, Visa, > Microsoft, Mastercard and others. All of these proposals are based on > X.509 certificates or some close variant. None of them are wedded to X.509 certificates. If an alternatives showed up, they would probably be adopted. > The web-based and electronic commerce applications are significant > contributors to the recent explosive growth in the Internet. A sizeable > percentage of all systems on the net ALREADY USE X.509 for some > applications If you are refering to SSL, it uses certificates only in the most basic possible sense. There is no distribution mechanism for them -- they are hardcoded in to netscape -- and there is almost no use of the X.509 facilities, and there are no user certificates. I doubt that it would change Netscape's life significantly if they switched to any other certificate. > I'm sure it will come as a shock to Perry, but I have a strong dislike > for ASN.1, X.509 certificates and DNs. But I am enough of a pragmatist > to understand that not only will they not go away, they will soon be > universally deployed within certain applications. I don't agree. I think that they are pretty much only going to succeed if no alternative shows up, so I intend to see an alternative show up. > - if we clutter the DNS with all the additional information > required to support a fully developed, distributed, secure > infrastructure, it will look remarkably like an X.500 > Directory Service. I'm afraid that we already have a proposal for embedding certificates in the DNS that doesn't make it look like X.500. Don't assume everyone is as incapable of producing a clean and simple solution as the ISO. Perry From ipsec-request@ans.net Wed Nov 15 11:10:28 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA16922 (5.65c/IDA-1.4.4 for ); Wed, 15 Nov 1995 15:27:36 -0500 Received: by interlock.ans.net id AA04233 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Nov 1995 15:23:06 -0500 Message-Id: <199511152023.AA04233@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 15 Nov 1995 15:23:06 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 15 Nov 1995 15:23:06 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 15 Nov 1995 15:23:06 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Nov 1995 15:23:06 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Nov 1995 15:23:06 -0500 To: "Perry E. Metzger" , ipsec From: Charles Blauner Date: 15 Nov 95 15:10:28 EDT Subject: Re: editorial on Photuris Mime-Version: 1.0 Content-Type: Text/Plain At this point it is not clear that any certificate format has the backing to be the only one included in any standards work. Although PGP is clearly the most common encryption tool used by people on the net today, at least in the Financial industry, I don't know of anyone who would use PGP for commerical/ business transactions. Almost every company I know down here on Wall Street is looking at deploying public-key infrastructures over the next year or two. Every one of those firms, or at least the set with which I have regular contact, is basing that infrastructure on X.509 certificate based products. The format of the certificate and the trust model implied by version 3 certificates and certification authorities is the one of choice (at least for now) for financial firms. I also would suggest that you try and separate the debate over certificate format from the debate over where certificates can live. Why can't we use X.509 certificates without an X.500 directory. If I recall correctly, didn't the spec for DNS security include the ability to store an X.509 certificate in DNS? Charles Blauner Perry Metzger wrote in response to Stephen Kent: Stephen Kent writes: > I respectfully disagree with your conclusions re use of PGP > certificates with Photuris. While PGP is the most widely used secure email > protocol in the Internet, its use is not all that widespread in the "grand > scheme of things." Steve; I would suggest that X.509 certificates are also not widespread in the "grand scheme of things" and require a horrifying X.500 infrastructure for real world use -- an infrastructure that most people are unwilling to deploy -- and require the use of distinguished names which, for better or worse, are have proven unacceptable to the internet community. I, for one, would be happy to sit down around the virtual (or real) table with a bunch of other people in who have an interest in this and come up with a clean, "internet compatible" certificate format and infrastructure. I know that Don Eastlake was starting work on such a thing. Rather than trying to beat the dead X.509 horse, perhaps the concerned parties could all get into a dialog goin To: kent @ bbn.com (Stephen Kent) @ SMTP cc: rja @ cs.nrl.navy.mil @ SMTP, watt @ sware.com (Charles Watt) @ SMTP, ipsec @ ans.net @ SMTP From: perry @ piermont.com ("Perry E. Metzger") @ SMTP Sent: Tue 11/14/95 05:50:29 PM Subject: Re: editorial on Photuris Stephen Kent writes: > I respectfully disagree with your conclusions re use of PGP > certificates with Photuris. While PGP is the most widely used secure email > protocol in the Internet, its use is not all that widespread in the "grand > scheme of things." Steve; I would suggest that X.509 certificates are also not widespread in the "grand scheme of things" and require a horrifying X.500 infrastructure for real world use -- an infrastructure that most people are unwilling to deploy -- and require the use of distinguished names which, for better or worse, are have proven unacceptable to the internet community. I, for one, would be happy to sit down around the virtual (or real) table with a bunch of other people in who have an interest in this and come up with a clean, "internet compatible" certificate format and infrastructure. I know that Don Eastlake was starting work on such a thing. Rather than trying to beat the dead X.509 horse, perhaps the concerned parties could all get into a dialog goin From ipsec-request@ans.net Wed Nov 15 17:25:23 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17223 (5.65c/IDA-1.4.4 for ); Wed, 15 Nov 1995 15:32:50 -0500 Message-Id: <199511152032.AA17223@ftp.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@ftp.ans.net); Wed, 15 Nov 1995 15:30:30 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 15 Nov 1995 15:30:30 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 15 Nov 1995 15:30:30 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Nov 1995 15:30:30 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Nov 1995 15:30:30 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Wed, 15 Nov 1995 15:30:30 -0500 Sender: Charles Watt Subject: Re: editorial on Photuris To: perry@piermont.com Date: Wed, 15 Nov 1995 12:25:23 -0500 (EST) From: Charles Watt Cc: watt@sware.com, ipsec@ans.net In-Reply-To: <199511151615.LAA08150@jekyll.piermont.com> from "Perry E. Metzger" at Nov 15, 95 11:15:19 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1381 -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-Certificate: MIIBvzCCAWkCEFmOln6ip0w49CuyWr9vDVUwDQYJKoZIhvcNAQECBQAwWTELMAkG A1UEBhMCVVMxGDAWBgNVBAoTD1NlY3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2Vj dXJlV2FyZSBQQ0ExFzAVBgNVBAsTDkVuZ2luZWVyaW5nIENBMB4XDTk1MDUwODIw MjMzNVoXDTk3MDUwNzIwMjMzNVowcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1Nl Y3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2VjdXJlV2FyZSBQQ0ExFzAVBgNVBAsT DkVuZ2luZWVyaW5nIENBMRUwEwYDVQQDEwxDaGFybGVzIFdhdHQwWTAKBgRVCAEB AgICBANLADBIAkEM2ZSp7b6eqDqK5RbPFpd6DGSLjbpHOZU07pUcdgJXiduj9Ytf 1rsmf/adaplQr+X5FeoIdT/bVSv2MUi3gY0eFwIDAQABMA0GCSqGSIb3DQEBAgUA A0EApEjzeBjiSnGImJXgeY1K8HWSufpJ2DpLBF7DYqqIVAX9H7gmfOJhfeGEYVjK aTxjgASxqHhzkx7PkOnL4JrN+Q== MIC-Info: RSA-MD5,RSA, DIZJ+gls3W4AmocMnqiFawculyJHcfrMSDPszIWsv8tUlX3V4vDGPPi2Bok5fMqD dvyTM6rFgNudVZ3V2pbAKIo= > > - if we clutter the DNS with all the additional information > > required to support a fully developed, distributed, secure > > infrastructure, it will look remarkably like an X.500 > > Directory Service. > > I'm afraid that we already have a proposal for embedding certificates > in the DNS that doesn't make it look like X.500. Don't assume everyone > is as incapable of producing a clean and simple solution as the ISO. I'm not making this particular assumption. My assumption is that you are short sighted -- slam in certificates and our security problems are solved. Well, I would like this infrastructure to be useful for more than IP security, say for Electronic Commerce. This means that you need LOTS more stuff, like the CA's policy statement, a pointer to the CA's real-time electronic notary, the authorizations granted to me by my employer for EDI transactions, etc... DNS bloat == X.500. As these issues have no relevance to Photuris, the Photuris spec should be independent of the mechanism binding name and key. This frees you and your "smart people" to go off and design your new public key infrastructure. Please spend some time researching the larger requirements for such an infrastructure first. You might also touch base with the pkix working group, they seem to think that this infrastructure is their charter. Charles Watt SecureWare -----END PRIVACY-ENHANCED MESSAGE----- From ipsec-request@ans.net Wed Nov 15 17:39:40 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15454 (5.65c/IDA-1.4.4 for ); Wed, 15 Nov 1995 15:40:51 -0500 Message-Id: <199511152040.AA15454@ftp.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@ftp.ans.net); Wed, 15 Nov 1995 15:36:41 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 15 Nov 1995 15:36:41 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 15 Nov 1995 15:36:41 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Nov 1995 15:36:41 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Nov 1995 15:36:41 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Wed, 15 Nov 1995 15:36:41 -0500 X-Mailer: exmh version 1.6.3 10/3/95 X-Face: +o^+u7Z5}dB^gVlCgr.W/thrVG>63+@L&~6W3um$qzdHEf*o^b4g'.>AF*9jO,@sw.~gu*+ !Ld4U(yvY'QL7ZSB#r3zb[pTsR0K5ZHDs5.8'w.'$u(o;imk*Z-.g)V|2a-KM-waTKUvx'xM>xOlZL E=ghh49p2h$1`Vp&rOtYlnm{|ixN#45yL)*j$3>QbmWu-[)Nw;^P53@cMO[P#Q>k3Ut)?Vh^`IJYvB ZdB[z`5aM4Z"wW@l~~iWw0MY^%F$mP)~F\lBcgj`h^hOvIp< X-Uri: http://www.milkyway.com/People/Michael_Richardson/Bio.html To: rja@cs.nrl.navy.mil, ipsec@ans.net Subject: Re: editorial on Photuris References: <199511151304.IAA07921@jekyll.piermont.com> <199511151403.AA20578@interlock.ans.net> In-Reply-To: Your message of "Wed, 15 Nov 1995 09:00:55 EST." <199511151403.AA20578@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Nov 1995 12:39:40 -0500 From: Michael Richardson > It is legitimate for folks in the IPsec WG to work on adding X.509 > support as extensions to the various key mgmt proposals. However, in > my view the burden of producing the specific text changes desired for > such X.509 support is on those folks who wish to use X.509. If the The primary situation I see where X.509 certificates would be used would be when integrating with a GSSAPI that used X.509 certificates (e.g. Entrust). In this case, the key management would be taken care of by the GSSAPI already. (And may not even allow one to access to they keying routines. I am about to look and see if it is even possible to deal with out of order encrypted packets!) I would envision GSSAPIs being selected at the ESP/AH level, not at the keying layer. From ipsec-request@ans.net Wed Nov 15 21:52:54 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17184 (5.65c/IDA-1.4.4 for ); Wed, 15 Nov 1995 16:57:25 -0500 Received: by interlock.ans.net id AA06938 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Nov 1995 16:49:40 -0500 Message-Id: <199511152149.AA06938@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 15 Nov 1995 16:49:40 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 15 Nov 1995 16:49:40 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Nov 1995 16:49:40 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Nov 1995 16:49:40 -0500 Sender: Charles Watt Subject: Re: editorial on Photuris To: ipsec@ans.net Date: Wed, 15 Nov 1995 16:52:54 -0500 (EST) From: Charles Watt In-Reply-To: <199511151922.AA02003@interlock.ans.net> from "Paul Leach" at Nov 15, 95 11:24:16 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 2666 -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-Certificate: MIIBvzCCAWkCEFmOln6ip0w49CuyWr9vDVUwDQYJKoZIhvcNAQECBQAwWTELMAkG A1UEBhMCVVMxGDAWBgNVBAoTD1NlY3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2Vj dXJlV2FyZSBQQ0ExFzAVBgNVBAsTDkVuZ2luZWVyaW5nIENBMB4XDTk1MDUwODIw MjMzNVoXDTk3MDUwNzIwMjMzNVowcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1Nl Y3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2VjdXJlV2FyZSBQQ0ExFzAVBgNVBAsT DkVuZ2luZWVyaW5nIENBMRUwEwYDVQQDEwxDaGFybGVzIFdhdHQwWTAKBgRVCAEB AgICBANLADBIAkEM2ZSp7b6eqDqK5RbPFpd6DGSLjbpHOZU07pUcdgJXiduj9Ytf 1rsmf/adaplQr+X5FeoIdT/bVSv2MUi3gY0eFwIDAQABMA0GCSqGSIb3DQEBAgUA A0EApEjzeBjiSnGImJXgeY1K8HWSufpJ2DpLBF7DYqqIVAX9H7gmfOJhfeGEYVjK aTxjgASxqHhzkx7PkOnL4JrN+Q== MIC-Info: RSA-MD5,RSA, A6fe0hqFROJGqdI5VoNSKgJbwRyB8ZCyOOrweEc6tjWLnGlu4/7NGqUa+Kjtv7AI 2oZojCJHKRXTRfjOP1DmDOs= Paul Leach wrote: > Charles said: > ] True, but to the user neither: > ] > ] Charles.Watt@sware.com > ] sware.com > ] ga.gov > ] > ] nor > ] CN=Charles Watt, O=SecureWare, C=US > ] O=SecureWare, C=US > ] O=Georgia Certificate Authority, C=US > ] > ] are as effective as a more formatted display. If you need to reformat > ] anyway, what's the difference? > ] > > Reformatting for UI purposes is not the issue. If I make a connection to > www.sware.com > using (e.g.) SSL or PCT, and the certificate comes back and proves I've > just contacted "O=SecureWare, C=US", have I contacted the correct > server, or not? I can't determine this automatically in my browser (or > better yet, in the secure connection layer), and if the user is relied > upon to decide, then if I'm a spoofer, I'll for sure pick a name that > is as close as possible to the one I'm spoofing so as to fool users > into saying that it is the name to which they were trying to connect. > > My principle: if you're making a secure connection to a DNS-named > entity, then the certificate MUST bind its DNS name to its key. > (Something that can be trivially and algorithmically mapped to a DNS > name would be OK -- but I've never seen anyone present an X.509 > example, real or hypothetical, where that's true. One post to this > list (or pkix -- I forget) showed the DN in a Verisign certificate of a > real SSL-using web site, and the relation between its DN and it DNS > name was not even as close as Charles' example above. The DN named the > parent corporation of the entity that ran the web site...) You are quite correct that establishing trust is the single most important issue for any public key infrastructure. However, deriving trust from the name, whether using DNs or domain names is foolish at best. I can spoof DNS servers, can't you? At this time the only secure method (of which I am aware) that has been suggested for establishing trust for public key operations is to cryptographically link an unknown Name/Key binding to some established Name/Key binding that you implicitly trust. X.509 specified a very general approach to solving this problem, an approach that was too general to be of any use. Finding an approach that works well in various operational environments is difficult, and has been the subject of much debate. This is the most significant difference between PGP and PEM. It, not the horrid encoding format, is the fundamental problem slowing X.509 deployment. It is the problem that any replacement for X.509 would have to solve. And it is the problem that the pkix working group is wrestling with. Charles Watt SecureWare -----END PRIVACY-ENHANCED MESSAGE----- From ipsec-request@ans.net Wed Nov 15 09:10:50 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12755 (5.65c/IDA-1.4.4 for ); Wed, 15 Nov 1995 20:18:46 -0500 Received: by interlock.ans.net id AA10987 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Nov 1995 20:08:38 -0500 Message-Id: <199511160108.AA10987@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 15 Nov 1995 20:08:38 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 15 Nov 1995 20:08:38 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Nov 1995 20:08:38 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Nov 1995 20:08:38 -0500 X-Received: from red-16-msg by xnet2 with receive; Wed, 15 Nov 1995 17:08:08 -0800 X-Msmail-Message-Id: F706B4BD X-Msmail-Conversation-Id: F706B4BD From: Paul Leach To: ipsec-request@ans.net, ipsec@ans.net Date: Wed, 15 Nov 95 17:10:50 PST Subject: Re: editorial on Photuris X-Msxmtid: red-16-msg951116010744MTP[01.51.01]000000a1-197954 ] > My principle: if you're making a secure connection to a DNS-named ] > entity, then the certificate MUST bind its DNS name to its key. ] > (Something that can be trivially and algorithmically mapped to a DNS ] > name would be OK -- but I've never seen anyone present an X.509 ] > example, real or hypothetical, where that's true. One post to this ] > list (or pkix -- I forget) showed the DN in a Verisign certificate of a ] > real SSL-using web site, and the relation between its DN and it DNS ] > name was not even as close as Charles' example above. The DN named the ] > parent corporation of the entity that ran the web site...) ] ] You are quite correct that establishing trust is the single most important ] issue for any public key infrastructure. However, deriving trust from the ] name, whether using DNs or domain names is foolish at best. I can spoof ] DNS servers, can't you? Spoofing the server buys you denial of service, no more. The server you are directed at either won't know the private key of the certificate for the real server, or won't have a certificate that links to someone you do trust. ] At this time the only secure method (of which I ] am aware) that has been suggested for establishing trust for public key ] operations is to cryptographically link an unknown Name/Key binding to some ] established Name/Key binding that you implicitly trust. 100% agree. Don't see why it contradicts my example, though. It does point out that I omitted a few details-- the process of checking the certificate of the server one is talking to does indeed have to include checking the signature on that certificate, which is done recursively until one gets to a signature that can be checked via an apriori known key of a trusted CA. But it also has to include checking that the name of the principal you think you are talking to is the same as the name in what you call "Name/Key binding" that is presented as proof of the principal's identity. ] ] X.509 specified a very general approach to solving this problem, an approach ] that was too general to be of any use. Finding an approach that works well ] in various operational environments is difficult, and has been the subject ] of much debate. This is the most significant difference between PGP and PEM. ] It, not the horrid encoding format, is the fundamental problem slowing ] X.509 deployment. It is the problem that any replacement for X.509 ] would have to solve. And it is the problem that the pkix working group ] is wrestling with. Maybe this is the long term problemt they're tackling, but right now they seem particularly to be arguing about how the wedge the internet identity and CA locating information into the "extensions" field of v3 X.509 certificates. X.509 certs work perfectly fine when your directory is X.500 and your mail is X.400, but (IMHO) leave around some pretty useless artifacts when your directory is DNS and your mail is SMTP. From ipsec-request@ans.net Thu Nov 16 05:58:28 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12108 (5.65c/IDA-1.4.4 for ); Thu, 16 Nov 1995 01:07:10 -0500 Received: by interlock.ans.net id AA15164 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 16 Nov 1995 00:58:34 -0500 Message-Id: <199511160558.AA15164@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 16 Nov 1995 00:58:34 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 16 Nov 1995 00:58:34 -0500 X-Sender: jis@e40-po.mit.edu (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 16 Nov 1995 00:58:28 -0500 To: Charles Watt From: jis@mit.edu (Jeffrey I. Schiller) Subject: Re: editorial on Photuris Cc: ipsec@ans.net -----BEGIN PGP SIGNED MESSAGE----- Indeed the issue is how trust is established. PGP has flourished because of several properties: o No infrastructure required. Two parties can obtain PGP and communicate as soon as they have it installed. o PGP has a built in direct trust verification system, namely a built-in command to generate the MD5 hash of a public key (for easy communication over a telephone or other "trusted" channel) as well as a manual that explains why you need to do this and how to do it. o PGP's Web of Trust in effect easily supports several, potentially mutually exclusive, hierarchies. A Name/Key binding can have multiple signatures associated with it. If commerce were to use PGP, then I could have Visa sign my key and Master Card sign my key. I would still be able to use my one key and it would be trusted by both Master Card and Visa without Master Card nor Visa having to trust each other (or trust some "higher" third party!). o More to the point, PGP easily facilitates the above. o PGP supports a mechanism for me to extract my key and send it to you. Similarly you can add your signature (after verifying authenticity off line) and send me back my key and I can easily incorporate my key (with your signature now attached) back into my keyring. o PGP does not preclude a more formal hierarchy, but it is not limited to one. In short PGP has been successful because as a program it is a complete system including not only confidentiality and authentication but the real tools you need to do key management as well. Its completeness has permitted people to implement the PGP keyservers for public key exchange. The primary complaint I have seen against PGP is that a naive user can be lulled into believing a message that she shouldn't (i.e., this message is PGP signed, but unless you *know* that you have my public PGP key, you really don't know if it is from me [P.S. the same is true of Charles Watt's PEM formatted messages]). However PGP does attempt to warn people when uncertified keys are being depended on. If people choose to ignore the warnings... Some have proposed that the only answer to this problem is to make it impossible to use the system (be it PEM/MOSS/SSL etc.) unless you have a legitimate certificate, removing any discretion from the end user. However such systems have tended to be constructed of nonobtainium. Legal agreements are required, many with onerous licensing terms. For example Apple's AOCE requires the certificate requester to agree in writing (in ink in front of a notary) to Apple's software license (which is otherwise a license of adhesion). The Netscape Commerce server requires a certificate issued from Version in order to communicate with people who use Netscape's web browser. However Verisign isn't under any obligation to give anyone a certificate. In fact the last time I checked, the Verisign certificate agreement [which may have changed] didn't guarantee renewal. In theory a company could setup a Netscape commerce server, get a certificate and then find themselves suddenly out of the secure web business (assuming that Netscape checks the certificate validity dates) if a disagreement with Verisign results in Verisign not signing a renewal certificate. Now it is also important to understand that none of the above precludes the use of X.509 or any other format. You can easily build a PGP like application using X.509 format certificates (they would be bigger and clunkier then the PGP format because each PGP signature would require its own certificate). Similarly you can use the PGP format in a product that requires a strict naming hierarchy. Its just that traditionally X.509 certificates have been associated with nonobtainium certificates and PGP has been associated with an easy to obtain (modulo export control and other nonsense) and use program. Sorry for the length... -Jeff -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMKrS28UtR20Nv5BtAQEhGAQAicdUy3j8dTW8DzFJATLfG4ZgygECOgHT wXO1vggDqaRTtsYxfvU9M8G0Fu14l6MM7qKeAWpMuPwuy3w01GyL2EU0V24I6EWe eXUYisI9GxS+A/kPbUqBcYsDLWId1YrpF+8VBMdHvMNmApfq0HvWrFkAPMhf2dGd jv830g6JDOw= =goOP -----END PGP SIGNATURE----- From ipsec-request@ans.net Thu Nov 16 14:08:51 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17982 (5.65c/IDA-1.4.4 for ); Thu, 16 Nov 1995 09:18:05 -0500 Received: by interlock.ans.net id AA20527 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 16 Nov 1995 09:06:37 -0500 Message-Id: <199511161406.AA20527@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 16 Nov 1995 09:06:37 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 16 Nov 1995 09:06:37 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 16 Nov 1995 09:06:37 -0500 To: Paul Leach Cc: ipsec-request@ans.net, perry@piermont.com, ipsec@ans.net, linn@cam.ov.com Subject: Re: editorial on Photuris In-Reply-To: Your message of "Wed, 15 Nov 1995 11:24:16 PST." <199511151922.AA02003@interlock.ans.net> Date: Thu, 16 Nov 1995 09:08:51 -0500 From: John Linn Re: >My principle: if you're making a secure connection to a DNS-named >entity, then the certificate MUST bind its DNS name to its key. >(Something that can be trivially and algorithmically mapped to a DNS >name would be OK -- but I've never seen anyone present an X.509 >example, real or hypothetical, where that's true. One post to this >list (or pkix -- I forget) showed the DN in a Verisign certificate of a >real SSL-using web site, and the relation between its DN and it DNS >name was not even as close as Charles' example above. The DN named the >parent corporation of the entity that ran the web site...) As a point of information, RFC-1279 ("X.500 and Domains", written by Steve Kille in November 1991) defined just such a mapping, based on DomainComponent attributes to be incorporated in X.500 DNs. The ability to map between the name requested/displayed and the name as certified is critical; the choice of whether the certificate encoding is or isn't X.509 isn't fundamental. --jl From ipsec-request@ans.net Thu Nov 16 14:08:51 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17231 (5.65c/IDA-1.4.4 for ); Thu, 16 Nov 1995 13:32:07 -0500 Message-Id: <199511161832.AA17231@ftp.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@ftp.ans.net); Thu, 16 Nov 1995 13:25:30 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 16 Nov 1995 13:25:30 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 16 Nov 1995 13:25:30 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 16 Nov 1995 13:25:30 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Thu, 16 Nov 1995 13:25:30 -0500 To: Paul Leach Cc: ipsec-request@ans.net, perry@piermont.com, ipsec@ans.net, linn@cam.ov.com Subject: Re: editorial on Photuris In-Reply-To: Your message of "Wed, 15 Nov 1995 11:24:16 PST." <199511151922.AA02003@interlock.ans.net> Date: Thu, 16 Nov 1995 09:08:51 -0500 From: John Linn Re: >My principle: if you're making a secure connection to a DNS-named >entity, then the certificate MUST bind its DNS name to its key. >(Something that can be trivially and algorithmically mapped to a DNS >name would be OK -- but I've never seen anyone present an X.509 >example, real or hypothetical, where that's true. One post to this >list (or pkix -- I forget) showed the DN in a Verisign certificate of a >real SSL-using web site, and the relation between its DN and it DNS >name was not even as close as Charles' example above. The DN named the >parent corporation of the entity that ran the web site...) As a point of information, RFC-1279 ("X.500 and Domains", written by Steve Kille in November 1991) defined just such a mapping, based on DomainComponent attributes to be incorporated in X.500 DNs. The ability to map between the name requested/displayed and the name as certified is critical; the choice of whether the certificate encoding is or isn't X.509 isn't fundamental. --jl From ipsec-request@ans.net Thu Nov 16 19:30:57 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17452 (5.65c/IDA-1.4.4 for ); Thu, 16 Nov 1995 15:13:33 -0500 Received: by interlock.ans.net id AA05339 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 16 Nov 1995 15:10:46 -0500 Message-Id: <199511162010.AA05339@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 16 Nov 1995 15:10:46 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 16 Nov 1995 15:10:46 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 16 Nov 1995 15:10:46 -0500 From: alten@novell.com (Alex Alten) Subject: Re: editorial on Photuris To: perry@piermont.com Date: Thu, 16 Nov 1995 11:30:57 -0800 (PST) Cc: rja@cs.nrl.navy.mil, kent@bbn.com, ipsec@ans.net In-Reply-To: <199511151428.AA21093@interlock.ans.net> from "Perry E. Metzger" at Nov 15, 95 09:28:22 am X-Mailer: ELM [version 2.4 PL22] Original-Content-Type: text Content-Type: text/plain Content-Length: 2397 > > > Ran Atkinson writes: > > Regardless of whether some folks have strong objections to X.509, > > there DOES exist a community of interest that wants to use it. There > > are known technical problems with putting X.509 into the DNS, hence > > DNS certificates are not X.509 format (neither are they PGP). > > > > It is legitimate for folks in the IPsec WG to work on adding X.509 > > support as extensions to the various key mgmt proposals. > > I'm not arguing against that at all. I'm arguing something entirely > different -- that it is time for us to work on a simplified > certificate format. This is something that needs doing quite apart > from the specific considerations of Photuris, MOSS, or whatever else > might want to use such certificates. I realize that such a format > isn't going to be ready soon and that work can't be delayed to work > on it, and that people will want to use other formats as well. > > Perry > I brought up a very similar issue earlier with this list. We really need to standardize the formats of all sorts of things; certificates, signatures, multiprecision integers, etc. We probably have to do it for at least three encoding standards; Internet byte order, MIME, and ASN.1. This is beyond the scope of this list but it is crucial to the interoperability of secure IP, secure DNS, secure SNMP, secure Mail, secure HTTP, etc. These things are like nuts and bolts. If every bridge being built (read secure protocol) uses it's own custom nuts and bolts (read signatures, etc.) then the parts cannot be interchangeable. This drives up the cost of maintenance, administration, development, and use. An example might be that I receive a certified signature via SNMP which I then use to verify a signed record I receive from DNS. I firmly believe that these must be standardized before we can allow any of the secure protocol drafts to move further down the protocols track. We will probably have to compromise and allow a few variations to coexist because of existing implementations but I sincerely hope we can reduce these to a minimum. We should make the formats flexible enough to accomodate new public key and signature (mathematical) algorithms, etc. - Alex -- Alexander I. Alten Alten@Na.Sjf.Novell.Com (408) 577-8224 Novell, Inc. Member of Technical Staff Mail Stop F1-42-D2 2180 Fortune Drive San Jose, CA 95131 USA From ipsec-request@ans.net Sun Nov 19 19:46:15 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17407 (5.65c/IDA-1.4.4 for ); Sun, 19 Nov 1995 16:18:37 -0500 Received: by interlock.ans.net id AA03685 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 19 Nov 1995 16:13:26 -0500 Message-Id: <199511192113.AA03685@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 19 Nov 1995 16:13:26 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 19 Nov 1995 16:13:26 -0500 Date: Sun, 19 Nov 95 19:46:15 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Photuris Long-Term Session-Keys In the past week, there was considerable private debate about combining certain features of SKIP and Photuris. In particular, SKIP long term state for saving "master" keys, when perfect forward secrecy is not needed -- as in authentication-only applications, or "rapid fail-over" [sic] surviving crashes of critical firewalls. The current size of the Photuris SPI LifeTime is sufficient for weeks or months of long-term storage (2**24-1 seconds is about half a year). The SPI LifeTime is not related to the Photuris Exchange LifeTime. That is, the SPI session-key can be stored for long periods of time without compromising other privacy uses of the same shared-secret. Therefore, I will add a 5th "scenario", describing the possible storage of Long LifeTime SPIs. This should obviate the only "advantage" of SKIP. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Sun Nov 19 20:10:11 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17920 (5.65c/IDA-1.4.4 for ); Sun, 19 Nov 1995 16:18:37 -0500 Received: by interlock.ans.net id AA03691 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 19 Nov 1995 16:13:30 -0500 Message-Id: <199511192113.AA03691@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 19 Nov 1995 16:13:30 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 19 Nov 1995 16:13:30 -0500 Date: Sun, 19 Nov 95 20:10:11 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Photuris changes Over the past week, the authors have spent considerable time reviewing the state of the current draft and the recent discussions. We have concluded that certain "flexibility" features overly complicate the implementation and have made cryptological verification difficult. Therefore, the following changes will be made in the next draft: 1) The TLV definition of Attributes will be moved from the Appendix to the Protocol Details "Attributes" section. This is hoped to make it easier to scan for implementors (less page flipping). The three required Attributes descriptions will remain in the Appendix. All other non-required Attributes have already been moved to a separate "Extensions" document. 2) The optional moduli will be moved to the "Extensions" document. However, the example elliptic curve will remain, as it may encourage folks to experiment during the expected interminable "Extensions" document discussion. 3) The "Privacy-Choice" is being removed. Instead, each "Scheme-Choice" will specify exactly one privacy method. All Identification_Messages will be protected. The required 1024-bit modulus and optional 155-bit elliptic curve will both use DES. The optional 2048-bit and 4096-bit moduli will use Triple DES. 4) The "Key-Generator-Choice" is being removed. Instead, each authentication or encryption method will specify exactly one key generator hashing function. The required MD5 will always use MD5 (big surprise). The required DES with 32 or 64 bit IVs will always use MD5. 5) The "Validity-Choice" is being removed. Instead, each "Scheme-Choice" will specify exactly one integrity method. All Change_Messages will be protected. The required 1024-bit modulus and optional 155-bit elliptic curve will both use MD5. Another suggestion was that a formal pair of FSAs be described for the Initiator and Responder. This has been determined to add many pages to the draft. Perhaps if it is still felt that it is needed at the Draft Standard stage, we will undertake the effort at that time. I expect to have a new draft ready by Tuesday. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Mon Nov 20 04:30:39 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA16969 (5.65c/IDA-1.4.4 for ); Sun, 19 Nov 1995 23:34:33 -0500 Received: by interlock.ans.net id AA08436 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 19 Nov 1995 23:30:45 -0500 Message-Id: <199511200430.AA08436@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Sun, 19 Nov 1995 23:30:45 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 19 Nov 1995 23:30:45 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 19 Nov 1995 23:30:45 -0500 Date: Sun, 19 Nov 1995 21:30:39 -0700 From: Hilarie Orman To: bsimpson@morningstar.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <199511192113.AA03685@interlock.ans.net> Subject: Re: Photuris Long-Term Session-Keys > This should obviate the only "advantage" of SKIP. What about the ability to communicate over a unidirectional link? From ipsec-request@ans.net Mon Nov 20 12:01:48 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18722 (5.65c/IDA-1.4.4 for ); Mon, 20 Nov 1995 07:08:39 -0500 Received: by interlock.ans.net id AA12795 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 20 Nov 1995 07:01:59 -0500 Message-Id: <199511201201.AA12795@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 20 Nov 1995 07:01:59 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 20 Nov 1995 07:01:59 -0500 Date: Mon, 20 Nov 1995 04:01:48 -0800 (PST) From: Phil Karn To: ho@cs.arizona.edu Cc: bsimpson@morningstar.com, ipsec@ans.net In-Reply-To: <199511200430.AA08436@interlock.ans.net> (message from Hilarie Orman on Sun, 19 Nov 1995 21:30:39 -0700) Subject: Re: Photuris Long-Term Session-Keys >What about the ability to communicate over a unidirectional link? How many of these do we have in the Internet? I suppose multicasting could be thought of as a set of unidirectional links, but we've always known it would be a special case. TCP doesn't work too well unidirectionally either. The most important set of true unidirectional links we have is email, and for that we already have PGP. Phil From ipsec-request@ans.net Mon Nov 20 20:16:21 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18708 (5.65c/IDA-1.4.4 for ); Mon, 20 Nov 1995 15:15:04 -0500 Received: by interlock.ans.net id AA00726 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 20 Nov 1995 15:09:34 -0500 Message-Id: <199511202009.AA00726@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 20 Nov 1995 15:09:34 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 20 Nov 1995 15:09:34 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 20 Nov 1995 15:09:34 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 20 Nov 1995 15:09:34 -0500 Date: Mon, 20 Nov 1995 12:16:21 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) To: ipsec@ans.net Subject: Re: Reporter claiming SKIP... X-Sun-Charset: US-ASCII >From: "William Allen Simpson" > > > My original comments came because I was informed by a reporter that > > > there were people from Sun going around claiming that SKIP was > > > destined to be *the* standard for IP security and trying to bludgeon > > [...] > > > > > I can see where the reporter might have gotten the idea. Aziz's slides > (in today's presentation) states: > > "There was overwhelming consensus for SKIP to become an IETF > standards track RFC at the July '95 IETF meeting in Stockholm." > > No mention that it was a BOF. No mention that it wasn't the working > group, or more importantly a steering group final decision. > > Bill.Simpson@um.cc.umich.edu Bill, Here are a few things you neglected to mention. - This was not a press briefing. It was a private presentation to a group of vendors, most (or probably all) of whom are IETF participants, and had been to the meeting in question and knew exactly what was being discussed. The press was not invited to this presentation. Your implication that reporters might have been present is misleading at best. - Taking text from a presentation slide's bullet item, and then blasting it for completeness is not appropriate. As anyone who has given a presentation knows, a presentation bullet item is more of a visual cue for the speaker, and not a legally complete piece of text. The fact that this was a BOF came up in the verbal discussion when this slide was up, and no attempt was made to misrepresent any information, as you are suggesting. - The quoted text does *not* in any way imply that SKIP would become *the* standard for IP security. As it stands, the text is completely accurate. - In this vein, you could take the text from the bullet item of my last slide where it states: "SKIP reference sw will soon be placed in the public domain" and blast it for not mentioning that there will be 2 restrictions, i) a liability disclaimer and ii) observance of US export control laws. Gosh, a bullet item was not legally precise, by failing to mention these two restrictions. Stricly speaking, the software would not be public domain. Of course, these 2 restrictions were mentioned verbally, when this slide was up, and presentation bullet items rarely contain complete text on the points they are intended to highlight. Regards, Ashar. From ipsec-request@ans.net Mon Nov 20 23:21:42 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17598 (5.65c/IDA-1.4.4 for ); Mon, 20 Nov 1995 18:20:34 -0500 Received: by interlock.ans.net id AA06732 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 20 Nov 1995 18:14:52 -0500 Message-Id: <199511202314.AA06732@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 20 Nov 1995 18:14:52 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 20 Nov 1995 18:14:52 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 20 Nov 1995 18:14:52 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 20 Nov 1995 18:14:52 -0500 Date: Mon, 20 Nov 1995 15:21:42 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) To: ipsec@ans.net Subject: Re: WG Last Call for SKIP I-D X-Sun-Charset: US-ASCII > From bsimpson@morningstar.com Tue Nov 14 23:22 PST 1995 > > Here is a digest of my last call responses: > Bill, Thanks for your comments. Here are my reponses to the issues that you raise. > SKIP fails to provide adequate anti-clogging, at the protocol, > computational and resource levels. I don't agree with any of these assertions. > SKIP also lacks graceful recovery mechanisms. > > For example, a WWW server which accepts traffic from arbitrary clients > is easily clogged. As this is a principle application, such a failing > is unacceptable. > > Whenever a packet arrives with a master-key for which it does not have > the certificate precalculated, SKIP locates a certificate (requiring a > certificate protocol exchange) and calculates a Modular Exponentiation. > > When SKIP scales to hundreds (or millions) of nodes, it will be a simple > matter to completely swamp the target by sending a perfectly valid > SKIP header with each of the world-wide master identifying numbers, > triggering a search for the certificate, validation of the certificate > signature, and calculation of the shared-secret. This is not true. The clogging defense in SKIP, described in section 1.8.3 of the 04 draft, adequately protects against this. The SKIP defense to clogging is to have a pre-compute cache of master keys. In general when a SKIP node is targeted for clogging, it stops computing new master keys. This does NOT result in a denial-of-service, since the pre-compute cache can provide communications with nodes with which it has pre-computed master keys (including brand new network connections). Millions of nodes simply means a million or so master keys. If we assume 16 bytes per key, this comes to 16 Mbytes of storage. Even on very low end machines, 16M is a small amount of storage, since 0.5G to 1 G disk is pretty normal storage amounts these days. Assuming 16 MB spare on a disk on a node capable of handling a million nodes is not excessive. The master keys can live encrypted on disk under another key, either located on a smart card, or encrypted in a user password. Note that this does NOT represent a greater security threat than storing the long-term DH secret on stable storage, since the master keys are all computable from knowledge of the long-term DH secret. All this will result is in denying *unusual* access patterns service. A million or so usual patterns can still get service. > This is unacceptably protocol inefficient, as it generates a large > number of extraneous certificate query exchanges. When a node is being clogged, no new certificate requests need to be generated. The certificate requests are only needed if the node actually plans to exponentiate, which in this case it wouldn't. No extraneous certificate queries would be generated during a clogging attack. > This is unacceptably computationally expensive, as the signature and > shared-secret (Kijn) are calculated. > > The storage cache can easily be overflowed, likely causing loss of > storage for other applications. In the even of loss of cache, this > requires recalculation of other valid traffic master-keys -- yet another > additional computational expense -- possibly resulting in lost traffic. This is purely an implementation issue. The cache can easily be bounded to, say, a million entries. A cache is not necessarily ephemeral state, it can be permanent state. This is NO different from a security perspective than stating that the long-term DH private keys are permanent state (which they are) since (as noted above) the master keys are computable from the long-term DH secret. > This problem is due to the tremendous amount of long-term stored state > required by SKIP, and the lack of LifeTime. > > Recovery (as stated in the draft) requires manual intervention by the > system administrator to add each valid user to a "pre-compute cache". > This is unacceptable. You have misunderstood the intent of the draft. The manual intervention is there to allow *unusual* access patterns *during* a clogging attack. Unusual access patterns are the only class that may be denied service. If one is willing to disallow unusual access patterns service (i.e. not one that cannot be fit into a cache of a million or so entries) then NO manual intervention is required. I suspect that most people would be perfectly happy if a million or so nodes could get service during a clogging attack (including make brand new network connections). All of this was discussed in great depth almost a year ago, on the ipsec mailing list. > SKIP fails to provide adequate anonymity. > > In order to scale, SKIP certificates will need to be widely available, > making it easy to compile a world-wide database. The name space must be > searchable for deployment to scale. > > Use of a hash, public-value, or other index to identify the master key > is easily searched among all known master certificates. The type of > certificate used is transparently identified in the SKIP header. > > Protection of anonymity by private manual configuration and/or assuming > very large and unsearchable name spaces (page 15) is unacceptable. One solution for anonymity for mobile users is to have anonymous principal ids (either per host or per user) (represented by private keys in smart cards or encrypted in some user password) that can be handed out to mobile users. These anonymous smart cards can be rotated among users, so that it isn't possible to know who is using a particular anonymous principal ID at any point in time. This can be implemented with SKIP, without requiring any change to the protocol. > SKIP admittedly does not provide "perfect forward secrecy" (back traffic > protection). > > While it may be that authenticated traffic does not require this > protection in certain instances (which are debatable), it is "a > desirable and appealing goal" for privacy. SKIP lack of this protection > for encryption is unacceptable. Lack of "desirable and appealing" is not the same as "unacceptable". Secure e-mail protocols, such as PGP, PEM, MOSS, etc. are widely used in the Internet community for encryption purposes, and these provide no perfect forward secrecy. If we accept lack of pfs for e-mail, why is it unacceptable for IP? Is encrypted IP data inherently more valuable than encrypted e-mail data? > SKIP headers range from 28 to 60 bytes, not including the IP Security > headers (only 4 to 8 bytes). You are comparing apples and oranges. For SKIP, you are counting algorithm specific information (the encrypted key is algorithm specific) but for ESP/AH you are only counting algorithm independent information. If you count algorithm specific information, the overheads are quite comparable. For example, for AH with keyed MD5, the per packet overhead due to AH is 24 bytes. The SKIP header can be as small as 20-28 bytes, (which BTW is probably going to be the common case in initial SKIP deployment). This is either slightly *less* or slightly more header overhead as compared to AH with Keyed MD5 (24 bytes). Not counting algorithm specific information for one case, but counting it for the other case is misleading. > SKIP trades "zero-message" initialization with manual configuration -- > or a few "optional" certificate discovery messages otherwise -- for > continuous bandwidth degradation on every datagram. > > The Internet Protocol Security Working Group spent considerable time in > designing the ESP and AH headers to be as small as possible. > > Considering that the average TCP payload is 13 bytes, and the average IP > datagram is 124 or so bytes, bloating every datagram by an extra 50% to > 200% is unacceptable First of all, if you assume avg SKIP header as 20-30 bytes, this comes to 16-24% of a 124 byte packet (and not 50-200%). Of course, 124 bytes is a small sized packet, and throughput critical applications (ftp etc.) will use larger packet sizes, like 512 to 1024 bytes. This brings the header overhead down to 4-6% for 512 bytes and 2-3% for 1k bytes. Assuming worst case SKIP header overheads with small sized IP packets is quite misleading. Second, why don't we leave this to the community to try and decide if this is acceptable or unacceptable. We are making our source software freely available so that people can try this in the environments that matter to them. If people don't like any part of it, nobody is forcing them to use SKIP or anything else for that matter. [I have been privately informed that the April '95 Merit/NFSNET backbone statistics shown an average IP datagram size of 266 bytes for TCP services. The current boom in WWW traffic is pushing IP packet sizes up, not down.] > SKIP exhibits several serious insecurities. > > The SKIP master keys are extremely long term. No matter how many > "reasonable safeguards", long term storage of keys carries a significant > security risk. This problem has long been recognized for KDCs. There is a BIG distinction between central storage of long-term keys (the KDC represents a single "fat target") and decentralized storage of long term keys. There is no central storage of long-term keys in SKIP. Only decentralized storage of long-term keys. This avoids the biggest problem with KDCs. Decentralized storage of long-term keys is a fact of life for any cryptographic protocol that provides authentication, since one needs to securely store each principal's authentication keys. The distinction here is the amount of decentralized long-lived information. However, any technique that can protect a small amount of decentralized secret information can be used to protect a large amount of decentralized secrets, since cryptography is an amplification technique (a small amount of information, i.e, a key can protect a large amount of information, usually data but in this case other keys). > The SKIP master keys are maintained on multiple systems. Although this > may be appealing for rapid "fail-over and load-balancing", and > "intermediate authentication", there is no IP Security requirement for > these features. First of all, your statement is misleading. It is incorrect to state that "SKIP master keys are maintained on multiple systems". Rather, they CAN be maintained on multiple systems, providing failure recovery properties you simply can't get with conventional session key-management protocols. Second, please don't tell me what is and what isn't a requirement. The firewall customers that I talk to (virtually every large telco, bank, large enterprise) ask for features like high availability far more than they ask about things like perfect forward secrecy. If we are asking the user community to trade off perfect secrecy for availabilty, then let's let the user community decide this. > Every node that has the duplicate master keys is > another potential security risk. This makes the security risk even > worse than KDCs. Like I said, SKIP doesn't REQUIRE the master keys to be duplicated on multiple nodes, it PERMITS you to do so, providing highly desirable features that you simply can't get with other approaches. > The SKIP public-values are signed, but the generated session-keys are > not signed. Current literature suggests that _both_ the public values > and resulting session-keys be signed to prevent attacks. The signature > operation is not known to be associative or commutative. I am not aware of any requirement that traffic keys MUST be signed, since there are so many key-distribution protocols that involve NO signature operation. As one example, look at ANSI X9.42, which uses certified DH keys to come up with per session keys which are not signed. There is also a protocol due to El Gamal, which is some kind of ISO draft standard, that generates session keys using certified DH keys, which are not signed. I am not aware of attacks or vulnerabilities in either one of these schemes. If you really believe that this is a significant security risk, then please describe an attack on the protocol, or even the beginnings of such an attack. I will consider your objection more seriously then. To summarize, I don't believe that you have raised any new issues in your comments. Only issues that have been discussed many times over in the last year and a half on this mailing list. Nor have you described any serious shortcomings or defects. Also, you have requested no specific changes to the document. Therefore, at this point in time, I don't have any editorial action to take, based on your comments. Of course, if there is clarifying text that you would like to suggest that may help remove some of the misunderstandings that prompted your messages, I will gladly add such text, provided you supply me this text. Kind regards, Ashar. From ipsec-request@ans.net Tue Nov 21 00:15:23 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA16943 (5.65c/IDA-1.4.4 for ); Mon, 20 Nov 1995 19:11:01 -0500 Received: by interlock.ans.net id AA08181 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 20 Nov 1995 19:08:34 -0500 Message-Id: <199511210008.AA08181@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 20 Nov 1995 19:08:34 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 20 Nov 1995 19:08:34 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 20 Nov 1995 19:08:34 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 20 Nov 1995 19:08:34 -0500 Date: Mon, 20 Nov 1995 16:15:23 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) To: ipsec@ans.net Subject: Re: comments on draft 03 of SKIP X-Sun-Charset: US-ASCII > From housley@spyrus.com Tue Nov 14 08:02 PST 1995 > Date: Tue, 14 Nov 95 07:25:58 > From: "Housley, Russ" > Ashar: > > At SPYRUS, we have always included MD5 within our commercial PCMCIA crypto > token, the LYNKS Privacy Card. We originally put the MD5 hash into the > card to support digital signature applications, and it would be a trivial > modification to use it for key update in the manner that I suggested in my > original note. In fact, we already have plans to add the X9.42 scheme once > the ANSI X9.F.1 committee comes to consensus on the remaining open > details. > > I think the SKIP users and developers will be better served by the hash > approach. Russ, I tend to agree with you. The next draft of SKIP will contain the hash based approach. (For the independent implementors of SKIP, this is the same as the hash based scheme described for manual master key setup). I will put out a new draft soon. Thanks, Ashar. From ipsec-request@ans.net Mon Nov 20 22:35:29 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17942 (5.65c/IDA-1.4.4 for ); Tue, 21 Nov 1995 01:13:28 -0500 Received: by interlock.ans.net id AA13872 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 21 Nov 1995 01:09:29 -0500 Message-Id: <199511210609.AA13872@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 21 Nov 1995 01:09:29 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 21 Nov 1995 01:09:29 -0500 Date: Mon, 20 Nov 95 22:35:29 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: Photuris Long-Term Session-Keys > Date: Sun, 19 Nov 1995 21:30:39 -0700 > From: Hilarie Orman > > This should obviate the only "advantage" of SKIP. > > What about the ability to communicate over a unidirectional link? > This was mentioned in jest? The SKIP "certificate discovery protocol" [page 42] sends requests to the node from which it received the SKIP datagram. That requires two-way communication. To quote: An optional protocol is described to enable communicating IP-nodes to discover each other's certificate(s). This obviates the need for an on- line certificate directory server. Of course, once the certificate is obtained and the shared-secret is calculated, then one-way is possible. But that is true of normal IP Security as well, using Photuris. Photuris is an automated key management protocol. Please compare the key management functions themselves. Note that certificate management in SKIP is _optional_. I guess that's what makes it "simple". ---- While I'm thinking about it, SKIP also allows "intermediate authentication" at routers. This, of course, requires manual key setup. Again, not an automated key management function. It also requires the sharing of both parties secret keys with all the routers en route. Pretty bad security. I have a tendency to ignore so-called "security features" which reduce security. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Tue Nov 21 06:37:48 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17983 (5.65c/IDA-1.4.4 for ); Tue, 21 Nov 1995 01:39:07 -0500 Received: by interlock.ans.net id AA14206 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 21 Nov 1995 01:36:33 -0500 Message-Id: <199511210636.AA14206@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 21 Nov 1995 01:36:33 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 21 Nov 1995 01:36:33 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 21 Nov 1995 01:36:33 -0500 Date: Mon, 20 Nov 1995 23:37:48 -0700 From: Oliver Spatscheck To: ipsec@ans.net Subject: Photuris in Dallas. Content-Length: 410 I will have a Photuris prototype ready for interoperability testing in Dallas and was wondering if somebody else will have a protoype ready to test ineroperability. My current version complies to draft 7.c. Oliver Spatscheck ----- PhD student and research assistant in computer science at the University of Arizona, Tucson, USA Please check also my homepage URL: http://www.cs.arizona.edu/people/spatsch From ipsec-request@ans.net Tue Nov 21 07:55:07 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA04299 (5.65c/IDA-1.4.4 for ); Tue, 21 Nov 1995 02:59:31 -0500 Received: by interlock.ans.net id AA14824 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 21 Nov 1995 02:54:52 -0500 Message-Id: <199511210754.AA14824@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 21 Nov 1995 02:54:52 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 21 Nov 1995 02:54:52 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 21 Nov 1995 02:54:52 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 21 Nov 1995 02:54:52 -0500 From: markson@osmosys.incog.com (Tom Markson) Subject: Re: Photuris Long-Term Session-Keys To: bsimpson@morningstar.com (William Allen Simpson) Date: Mon, 20 Nov 1995 23:55:07 -0800 (PST) Cc: ipsec@ans.net In-Reply-To: <199511210609.AA13872@interlock.ans.net> from "William Allen Simpson" at Nov 20, 95 10:35:29 pm X-Mailer: ELM [version 2.4 PL24 PGP5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > The SKIP "certificate discovery protocol" [page 42] sends requests to > the node from which it received the SKIP datagram. That requires > two-way communication. To quote: > > An optional protocol is described to enable communicating > IP-nodes to discover each other's certificate(s). This obviates > the need for an on- line certificate directory server. > > Of course, once the certificate is obtained and the shared-secret is > calculated, then one-way is possible. But that is true of normal IP > Security as well, using Photuris. Not exactly. SKIP public values can be distributed in ways other than the Discovery protocol. One could use floppies, directory services, etc. Then, the two way isn't needed at all. It is more analgous to this: I need to find your IP address to talk to you. I can query a name service, call you on the phone or whatever. Once I have your ip address, I don't need anything else to start sending you IP packets. Think of the Public value like an IP address. Once I have it, I don't need any exchanges with you to begin sending encrypted/authenticated data. I believe SKIP is the only key management protocol which displays this property. > Note that certificate management in SKIP is _optional_. I guess that's > what makes it "simple". It's optional because it is a convenient, limited solution to a much larger problem of key distribution. Regards, --tom From ipsec-request@ans.net Tue Nov 21 21:48:25 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12170 (5.65c/IDA-1.4.4 for ); Tue, 21 Nov 1995 16:55:49 -0500 Received: by interlock.ans.net id AA01437 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 21 Nov 1995 16:51:25 -0500 Message-Id: <199511212151.AA01437@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 21 Nov 1995 16:51:25 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 21 Nov 1995 16:51:25 -0500 Organization: To: Oliver Spatscheck Cc: ipsec@ans.net Subject: Re: Photuris in Dallas. In-Reply-To: Your message of "Mon, 20 Nov 1995 23:37:48 MST." <199511210636.AA14206@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <15849.816990503.1@forthnet.gr> Date: Tue, 21 Nov 1995 23:48:25 +0200 From: "Angelos D. Keromytis" In message <199511210636.AA14206@interlock.ans.net>, Oliver Spatsche ck writes: > >I will have a Photuris prototype ready for interoperability testing >in Dallas and was wondering if somebody else will have a protoype r >eady >to test ineroperability. > I will. -Angelos From ipsec-request@ans.net Tue Nov 21 22:21:07 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13027 (5.65c/IDA-1.4.4 for ); Tue, 21 Nov 1995 17:24:46 -0500 Received: by interlock.ans.net id AA02266 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 21 Nov 1995 17:21:12 -0500 Message-Id: <199511212221.AA02266@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 21 Nov 1995 17:21:12 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 21 Nov 1995 17:21:12 -0500 Date: Tue, 21 Nov 1995 17:21:07 -0500 From: Byleu@aol.com To: atkinson@itd.nrl.navy.mil, ipsec@ans.net Subject: IPSEC fragmentation scheme Hi, I have a question regarding the AH & ESP RFCs. We are designing our next product according to the IPSEC RFCs(1825-1829) sepc. These RFCs do not mention what to do if a packet needs to be fragmented because of the AH & ESP security overhead. I am assuming that IP layer fragmentation scheme (using Identification, Flag & Fragment Offset fields) is the default scheme to use. Am I right ? If not, is there an IPSEC defined or recommended fragmentation scheme to use with AH & ESP ? I know we can define our own and include it as part of the payload data in AH/ESP. Best Regards, Brian Leu From ipsec-request@ans.net Wed Nov 22 01:21:22 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12602 (5.65c/IDA-1.4.4 for ); Tue, 21 Nov 1995 20:27:47 -0500 Received: by interlock.ans.net id AA05108 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 21 Nov 1995 20:21:33 -0500 Message-Id: <199511220121.AA05108@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 21 Nov 1995 20:21:33 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 21 Nov 1995 20:21:33 -0500 Date: Tue, 21 Nov 1995 17:21:22 -0800 (PST) From: Phil Karn To: Byleu@aol.com Cc: atkinson@itd.nrl.navy.mil, ipsec@ans.net In-Reply-To: <199511212221.AA02266@interlock.ans.net> (Byleu@aol.com) Subject: Re: IPSEC fragmentation scheme >These RFCs do not mention what to do if a packet needs >to be fragmented because of the AH & ESP security overhead. Well, if the packet has to be fragmented because of the added AH/ESP overhead, then you simply fragment it using the normal IP fragmentation scheme. However, if the packet being protected in "tunnel mode" has the DF (don't fragment) bit set, you bounce it back to the sender in an ICMP message along with an estimate of how large a packet could be acommodated without the AH/ESP overhead causing fragmentation. In this way a sender that implements MTU Discovery can reduce its packet size to avoid fragmentation in the first place. A host that implements AH/ESP directly ("transport mode") can somewhat more easily avoid local fragmentation due to the AH/ESP header. For example, many TCP implementations already ask the IP layer at connection setup time for the MTU of the interface that will be used to reach the specified destination. By subtracting the IP and TCP header sizes they arrive at the maximum segment size that can be sent without local fragmentation. When you implement AH/ESP on such a host, it's a simple matter to add code that further reduces the MTU reported from the IP layer by the worst-case AH/ESP header overhead. I've already done this in my KA9Q code and it works well. Phil From ipsec-request@ans.net Wed Nov 22 01:54:51 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17260 (5.65c/IDA-1.4.4 for ); Tue, 21 Nov 1995 21:01:54 -0500 Received: by interlock.ans.net id AA05475 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 21 Nov 1995 20:56:16 -0500 Message-Id: <199511220156.AA05475@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 21 Nov 1995 20:56:16 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 21 Nov 1995 20:56:16 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: markson@osmosys.incog.com (Tom Markson) Cc: bsimpson@morningstar.com (William Allen Simpson), ipsec@ans.net Subject: Re: Photuris Long-Term Session-Keys In-Reply-To: Your message of "Mon, 20 Nov 1995 23:55:07 PST." <199511210754.AA14824@interlock.ans.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 21 Nov 1995 20:54:51 -0500 From: "Perry E. Metzger" Tom Markson writes: > > The SKIP "certificate discovery protocol" [page 42] sends requests to > > the node from which it received the SKIP datagram. That requires > > two-way communication. > Not exactly. SKIP public values can be distributed in ways other than > the Discovery protocol. One could use floppies, An amazing speed advantage over Photuris, doubtless, > directory services, etc. Those can be conducted without two way communcication? I constantly hear from the SKIP people how SKIP requires no two way communication but I've yet to see any evidence that this is the case except in toy preconfigured situations in which IPSEC wouldn't require any two way communication if you manually keyed, either. Perry From ipsec-request@ans.net Wed Nov 22 08:10:36 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18855 (5.65c/IDA-1.4.4 for ); Wed, 22 Nov 1995 03:15:05 -0500 Received: by interlock.ans.net id AA09936 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 22 Nov 1995 03:11:10 -0500 Message-Id: <199511220811.AA09936@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 22 Nov 1995 03:11:10 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 22 Nov 1995 03:11:10 -0500 Date: Wed, 22 Nov 1995 00:10:36 -0800 (PST) From: Phil Karn To: bsimpson@morningstar.com Cc: ipsec@ans.net In-Reply-To: <199511192113.AA03685@interlock.ans.net> (bsimpson@morningstar.com) Subject: Re: Photuris Long-Term Session-Keys >The SPI LifeTime is not related to the Photuris Exchange LifeTime. That >is, the SPI session-key can be stored for long periods of time without >compromising other privacy uses of the same shared-secret. I think Bill's approach is a good one, and I agree that it should satisfy many of the needs of those who currently favor SKIP. I am interested in thoughts on the subject, though. Phil From ipsec-request@ans.net Wed Nov 22 10:59:09 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12833 (5.65c/IDA-1.4.4 for ); Wed, 22 Nov 1995 06:06:20 -0500 Received: by interlock.ans.net id AA11261 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 22 Nov 1995 06:00:49 -0500 Message-Id: <199511221100.AA11261@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 22 Nov 1995 06:00:49 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 22 Nov 1995 06:00:49 -0500 Date: Wed, 22 Nov 1995 02:59:09 -0800 (PST) From: Phil Karn To: ashar@osmosys.incog.com Cc: ipsec@ans.net In-Reply-To: <199511202314.AA06732@interlock.ans.net> (ashar@osmosys.incog.com) Subject: Re: WG Last Call for SKIP I-D >The SKIP defense to clogging is to have a pre-compute cache >of master keys. In general when a SKIP node is targeted for clogging, >it stops computing new master keys. This does NOT result in a >denial-of-service, since the pre-compute cache can provide >communications with nodes with which it has pre-computed >master keys (including brand new network connections). Ashar, You can deal with clogging in *any* key management protocol by simply disabling it as long as the attack is in progress, thus disabling the creation of new associations. Even if the system is not completely disabled (e.g., if prior associations continue to work) I see this as less desirable than a protocol that is designed to continue full functioning even when it is under attack. >The master keys can live encrypted on disk under another key, either >located on a smart card, or encrypted in a user password. Note >that this does NOT represent a greater security threat than storing >the long-term DH secret on stable storage, since the master keys are >all computable from knowledge of the long-term DH secret. This is a good point and illustrates an approach that all our schemes can use equally well to preserve state across reboots to save the resources necessary to recompute it. At the expense, of course, of diminished perfect forward secrecy if that is desired. Bill has proposed long-lived AH security associations (whose keys could be saved on disk across reboots) as one way that Photuris could satisfy some of the low-overhead authentication-only situations that SKIP has in the past handled better. Your comments? >When a node is being clogged, no new certificate requests need >to be generated. The certificate requests are only >needed if the node actually plans to exponentiate, which >in this case it wouldn't. No extraneous certificate queries >would be generated during a clogging attack. Again this is essentially a successful (partial) denial of service brought about by the attack. >> The storage cache can easily be overflowed, likely causing loss of >This is purely an implementation issue. The cache can easily >be bounded to, say, a million entries. A cache is not necessarily >ephemeral state, it can be permanent state. This is NO different >from a security perspective than stating that the long-term >DH private keys are permanent state (which they are) since >(as noted above) the master keys are computable from the >long-term DH secret. If the cache is not large enough to hold the entire database, then the attacker can purposely cause it to thrash (presuming he knows the replacement algorithm in use). Way back in my reckless undergraduate days we used to see how long we could keep the Cornell campus VM370 system page thrashing with the minimal amount of billed CPU time. It was amazingly easy when you put your mind to it... >One solution for anonymity for mobile users is to have anonymous >principal ids (either per host or per user) (represented by private keys >in smart cards or encrypted in some user password) that can be handed out >to mobile users. I've thought about your idea, and although it might work in theory (modulo various statistical attempts at traffic analysis) I think it is probably impractical in practice. Perhaps if the user and system used the SKIP encrypted channel to agree on a new randomly chosen ID for use in the next "conversation", it might work. But this of course adds state. >Secure e-mail protocols, such as PGP, PEM, MOSS, etc. are widely >used in the Internet community for encryption purposes, and these provide >no perfect forward secrecy. >If we accept lack of pfs for e-mail, why is it unacceptable for >IP? Is encrypted IP data inherently more valuable than encrypted >e-mail data? I "accept" no PFS for email right now only because I have no viable alternative. I am increasingly dissatisfied with the lack of PFS where it could easily be supported, i.e., in interactive communications. I generate a new PGP key pair every year or two at considerable inconvenience (look at my signature list!) just to put SOME limit on the damage that a compromise could cause. This is one reason I've made PFS such a priority in Photuris. Still, I'll have to accept no PFS when operating in unidirectional environments until somebody figures out how to do it. >There is a BIG distinction between central storage of long-term >keys (the KDC represents a single "fat target") and decentralized >storage of long term keys. Agree. Still, it's best to not do even this if you don't have to. >Decentralized storage of long-term keys is a fact of life >for any cryptographic protocol that provides authentication, >since one needs to securely store each principal's authentication >keys. Also true, but the consequences of a secret authentication key compromise in Photuris are FAR less severe than the compromise of a SKIP secret key. The effect of a compromise in Photuris would be limited to enabling active man-in-the-middle attacks which are inherently more difficult to mount and riskier (in terms of increased chances of detection) than passive monitoring attacks. If you can quickly detect the breach in Photuris you can essentially avoid damage entirely by immediately revoking the compromised key and generating a new one. In any event, thanks to PFS all prior session traffic is still protected. In SKIP all this traffic is forever compromised. >The distinction here is the amount of decentralized >long-lived information. However, any technique that can protect >a small amount of decentralized secret information can be used to >protect a large amount of decentralized secrets, since cryptography is >an amplification technique (a small amount of information, i.e, a key >can protect a large amount of information, usually data but in this >case other keys). True, but it cuts both ways -- a compromise can amplify your INsecurity in the exact opposite direction! In summary, I do agree with you when it comes to user requirements. Regardless of what we decide here, the market will ultimately decide based on what it considers most important, and it may very will choose a criterion we have hardly even considered. And then again there may turn out to be several well defined sets of needs for which one protocol or the other is best suited, meaning that they end up coexisting peacefully. Time will tell. Boy, I do seem to be mellowing in my old age. Or maybe I've just been redirecting my combative energies elsewhere where they might do some real good... :-) Phil From ipsec-request@ans.net Wed Nov 22 10:39:48 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12102 (5.65c/IDA-1.4.4 for ); Wed, 22 Nov 1995 16:43:19 -0500 Received: by interlock.ans.net id AA06047 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 22 Nov 1995 16:32:55 -0500 Message-Id: <199511222132.AA06047@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 22 Nov 1995 16:32:55 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 22 Nov 1995 16:32:55 -0500 Date: Wed, 22 Nov 95 15:39:48 EST From: hugo@watson.ibm.com To: IPSEC@ans.net Subject: Re: WG Last Call for SKIP I-D Received from Phil Karn (responding to Ashar): >>Secure e-mail protocols, such as PGP, PEM, MOSS, etc. are widely >>used in the Internet community for encryption purposes, and these provide >>no perfect forward secrecy. > >>If we accept lack of pfs for e-mail, why is it unacceptable for >>IP? Is encrypted IP data inherently more valuable than encrypted >>e-mail data? > >I "accept" no PFS for email right now only because I have no viable >alternative. I am increasingly dissatisfied with the lack of PFS >where it could easily be supported, i.e., in interactive >communications. I generate a new PGP key pair every year or two at >considerable inconvenience (look at my signature list!) just to put >SOME limit on the damage that a compromise could cause. > >This is one reason I've made PFS such a priority in Photuris. Still, >I'll have to accept no PFS when operating in unidirectional >environments until somebody figures out how to do it. Let me emphasize this. If I use SKIP in my firewall and its private key is compromised then *all* traffic in a *very long time* *from and to* the firewall is immediately exposed. That not only includes my incoming and outcoming mail, but also the telnet sessions, the ftp's, etc. etc. etc. I frankly wonder if Sun's headquaters would "defend" themselves with such a firewall. > >>There is a BIG distinction between central storage of long-term >>keys (the KDC represents a single "fat target") and decentralized >>storage of long term keys. > >Agree. Still, it's best to not do even this if you don't have to. > About the KDC example: even in that case PFS is a great solution. Even a breaking to the KDC will not compromise my session traffic if the KDC-provided key used *only* to authenticate a Diffie-Hellman exchange. Hugo From ipsec-request@ans.net Wed Nov 22 22:34:42 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA19179 (5.65c/IDA-1.4.4 for ); Wed, 22 Nov 1995 18:01:45 -0500 Received: by interlock.ans.net id AA07413 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 22 Nov 1995 17:34:45 -0500 Message-Id: <199511222234.AA07413@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 22 Nov 1995 17:34:45 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 22 Nov 1995 17:34:45 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: IPSEC@ans.net Subject: Re: WG Last Call for SKIP I-D In-Reply-To: Your message of "Wed, 22 Nov 1995 15:39:48 EST." <199511222132.AA06047@interlock.ans.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 22 Nov 1995 17:34:42 -0500 From: "Perry E. Metzger" > >>Secure e-mail protocols, such as PGP, PEM, MOSS, etc. are widely > >>used in the Internet community for encryption purposes, and these provide > >>no perfect forward secrecy. [...] > >I "accept" no PFS for email right now only because I have no viable > >alternative. I was under the impression that certain variations on El Gammal let you do perfect forward secrecy in non-interactive communications. am I hallucinating this, or is it correct? Perry From ipsec-request@ans.net Wed Nov 22 11:33:33 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12090 (5.65c/IDA-1.4.4 for ); Wed, 22 Nov 1995 18:21:40 -0500 Received: by interlock.ans.net id AA07849 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 22 Nov 1995 17:55:02 -0500 Message-Id: <199511222255.AA07849@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 22 Nov 1995 17:55:02 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 22 Nov 1995 17:55:02 -0500 Date: Wed, 22 Nov 95 16:33:33 EST From: hugo@watson.ibm.com To: karn@qualcomm.com Cc: ipsec@ans.net Subject: Photuris Long-Term Session-Keys Ref: Your note of Wed, 22 Nov 1995 00:10:36 -0800 (PST) (attached) > >>The SPI LifeTime is not related to the Photuris Exchange LifeTime. That >>is, the SPI session-key can be stored for long periods of time without >>compromising other privacy uses of the same shared-secret. > >I think Bill's approach is a good one, and I agree that it should satisfy >many of the needs of those who currently favor SKIP. I am interested in >thoughts on the subject, though. > >Phil Phil, Here are some thoughts. Indeed, as you say, Photuris can support long-lived pairwise master keys thus providing many of the advantages claimed by SKIP which are based on the existence of such (cached) long-term secrets. Actually, Photuris does better. It refreshes short-lived keys through the change-message and not by appending keys to the IP packet, thus avoiding SKIP header's overhead. However, both SKIP and the change-message way of refreshing keys are limited by the fact that these are uni-directional methods. Bi-directional (or interactive) refreshment of short-lived keys based on (authenticated) handshakes between the parties, provide for significant better security and synchronization. It provides the parties with assurance of a successful exchange (lost messges are detected), it provides with freshness of the keys and authentication in both directions, it lets both parties refresh their SPI's, both parties contribute to the randomness of the exchanged key, an eavesdropper is required to monitor both directions of the communications to try to learn anything, replay is easily handled (no need for timestamps, counters, or keeping very long lists of used SPIs), and so on. If all of this is done using cheap authentication techniques, like MD5, there is no reason (in the vast majority of cases) not to do it. Photuris hints to a way to do this but not in a satisfactory way. The implementation note in page 25 (Photuris.07) implies that an interactive key refreshment happens when the parties maintain their exchange-values unchanged. However, as far as I understand it, in this case only the initiator provides fresh information to the exchange via the SPI and Cookie (I believe that the intention of the text here is that the responder's cookie is unchanged in this case). Thus, suffering from many of the limitation of the "uni-directional" methods. I believe that this "implementation note" needs to be upgraded to support fully fresh bi-directional key refreshment. The way to do it is very simple (and I have already argued for it in the past). Instead of unnecessarily re-sending the unchanged exchanged-values just to discover that they did not change, allow the parties to send fresh nonces as the "exchange-values". In this case, all the advantages of interactive refreshment as pointed out above hold. (Of course, the authentication of the messages is done using the long-lived shared-secret via keyed-MD5 -- very cheap!). [OK. If you want to use fresh cookies instead of fresh nonces, I'll live with that...] Let's not miss this oportunity to take full advantage of Photuris being "bi-directional" by definition. Hugo From ipsec-request@ans.net Thu Nov 23 05:47:21 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA19109 (5.65c/IDA-1.4.4 for ); Thu, 23 Nov 1995 03:10:39 -0500 Received: by interlock.ans.net id AA14067 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 23 Nov 1995 03:01:25 -0500 Message-Id: <199511230801.AA14067@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 23 Nov 1995 03:01:25 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 23 Nov 1995 03:01:25 -0500 Date: Thu, 23 Nov 95 05:47:21 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: "interactive" freshness I hate to contradict Hugo when he is actually agreeing with me (what a rare circumstance), but he hasn't analysed the interaction correctly. > From: hugo@watson.ibm.com > Photuris hints to a way to do this but not in a satisfactory way. > The implementation note in page 25 (Photuris.07) implies that an > interactive key refreshment happens when the parties maintain their > exchange-values unchanged. However, as far as I understand it, > in this case only the initiator provides fresh information to the exchange > via the SPI and Cookie (I believe that the intention of the text here is > that the responder's cookie is unchanged in this case). > That is correct. As he has noticed, the Initiator changes the Cookie on each Exchange. This provides some very good "freshness". > allow the parties to send fresh nonces as the "exchange-values". > In this case, all the advantages of interactive refreshment as pointed out > above hold. > They do! Note that they also exchange a "fresh" SPI -- a nice random number that is _guaranteed_ not to be the same as a previous SPI (in that same direction) -- that also is included in the session-key. > Let's not miss this oportunity to take full advantage of Photuris being > "bi-directional" by definition. > We didn't.... But glad you agree! Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Thu Nov 23 06:57:59 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13732 (5.65c/IDA-1.4.4 for ); Thu, 23 Nov 1995 03:10:39 -0500 Received: by interlock.ans.net id AA14079 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 23 Nov 1995 03:01:33 -0500 Message-Id: <199511230801.AA14079@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 23 Nov 1995 03:01:33 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 23 Nov 1995 03:01:33 -0500 Date: Thu, 23 Nov 95 06:57:59 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: SKIP wastes bandwidth Because you seem incapable of addition, here is little more clear and direct comparison: > From: ashar@osmosys.incog.com (Ashar Aziz) > > SKIP headers range from 28 to 60 bytes, not including the IP Security > > headers (only 4 to 8 bytes). > > You are comparing apples and oranges. > > For SKIP, you are counting algorithm specific information (the encrypted > key is algorithm specific) but for ESP/AH you are only counting algorithm > independent information. If you count algorithm specific information, the > overheads are quite comparable. For example, for AH with keyed MD5, > the per packet overhead due to AH is 24 bytes. > Last I noticed, SKIP included AH headers! I was overly generous, and only calculated with SKIP plus ESP headers! > The SKIP header can be as small as 20-28 bytes, (which BTW is probably > going to be the common case in initial SKIP deployment). Your SKIP header diagrams indicate a minimum 28 bytes. I clearly stated a _range_ of SKIP headers, as presented in your proposal! Reading carefully, the short 20 byte variant is only possible if IP addressed are used instead of master IDs. But on the other hand, more than 8 byte keys are necessary when using AH instead of ESP. Full size SKIP with 16 byte keys is 68 bytes! OK, let's look at the "true" range of 20 to 68 bytes.... > This is either > slightly *less* or slightly more header overhead as compared to AH with > Keyed MD5 (24 bytes). > SKIP includes AH headers, so that overhead is in addition to AH, not in comparison to AH! That makes the SKIP plus AH headers 56 to 92 bytes! > > The Internet Protocol Security Working Group spent considerable time in > > designing the ESP and AH headers to be as small as possible. > > > > Considering that the average TCP payload is 13 bytes, and the average IP > > datagram is 124 or so bytes, bloating every datagram by an extra 50% to > > 200% is unacceptable > > First of all, if you assume avg SKIP header as 20-30 bytes, > this comes to 16-24% of a 124 byte packet (and not 50-200%). > SKIP (128-bit key) plus AH (MD5) is at least 92 bytes. A TCP/IP Ack is exactly 40 bytes. This almost 250% overhead. Worse than 200%. SKIP (64-bit key) plus ESP (DES) is at least 36 bytes. A TCP/IP with an average payload of 13 bytes is 53 bytes. This is 68% of the deliverable datagram. Again, I was being generous estimating only 50%. > Assuming worst case SKIP header overheads with small sized > IP packets is quite misleading. > I didn't. I was fair. I gave a range. I was generous. And don't give me crap about using an average. It does not matter that some packets can be bigger. Half will be smaller, and the bloated SKIP header has a _WORSE_ impact on smaller packets! The real impact will likely be dominated by the worse case estimate! Particularly as encryption makes VJ header compression impossible! Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Thu Nov 23 05:54:35 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18855 (5.65c/IDA-1.4.4 for ); Thu, 23 Nov 1995 03:10:39 -0500 Received: by interlock.ans.net id AA14073 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 23 Nov 1995 03:01:31 -0500 Message-Id: <199511230801.AA14073@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 23 Nov 1995 03:01:31 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 23 Nov 1995 03:01:31 -0500 Date: Thu, 23 Nov 95 05:54:35 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: SKIP insecure I do wish that you hadn't combined all your replies into a single message. It wasn't helpful for reading the thread. Of course, you probably didn't like the subject headings.... The first time around, I tried to be neutral, and state succinctly and impersonally the bare facts about the most important problems with the proposal, leaving out the 20 or so more minor failings. This time, you have decided to become personal, and I shall be personal in return! Phil, Perry, and Hugo have addressed many of your comments already. But here's my take on this particular concern: > From: ashar@osmosys.incog.com (Ashar Aziz) > > While it may be that authenticated traffic does not require this > > protection in certain instances (which are debatable), it is "a > > desirable and appealing goal" for privacy. SKIP lack of this protection > > for encryption is unacceptable. > > Lack of "desirable and appealing" is not the same as "unacceptable". > Please do not put words in my mouth. This was a "last call". It is time to evaluate whether the proposal covers the desired functionality. The quote "desirable and appealing goal" was from your own draft! This was _my_ analysis, with _my_ name on it -- the lack makes the proposal unacceptable to me! > > SKIP exhibits several serious insecurities. > > > > The SKIP master keys are extremely long term. No matter how many > > "reasonable safeguards", long term storage of keys carries a significant > > security risk. This problem has long been recognized for KDCs. > > There is a BIG distinction between central storage of long-term > keys (the KDC represents a single "fat target") and decentralized > storage of long term keys. > > There is no central storage of long-term keys in SKIP. Only decentralized > storage of long-term keys. This avoids the biggest problem with > KDCs. > This is WORSE than a KDC! Because a KDC is "central" in a single place, it can be hardened. Attacks can be managed, quantified and qualified, and made difficult. Since the SKIP keys are all over the place, it is much harder to quantify and qualify the attacks. Very simply, widely distributing the secrets makes it much more likely to be breached. Humans are fallable! > > The SKIP master keys are maintained on multiple systems. Although this > > may be appealing for rapid "fail-over and load-balancing", and > > "intermediate authentication", there is no IP Security requirement for > > these features. > > First of all, your statement is misleading. It is incorrect to > state that "SKIP master keys are maintained on multiple systems". > > Rather, they CAN be maintained on multiple systems, providing failure > recovery properties you simply can't get with conventional session > key-management protocols. > That they can is a _serious_ failing of the proposal. > Second, please don't tell me what is and what isn't a requirement. > I can damn well state what is a requirement! If you wish to contradict me, please refer to the paragraph in RFC-1825 where your requirement is derived! > The firewall customers that I talk to (virtually every large telco, > bank, large enterprise) ask for features like high availability far more > than they ask about things like perfect forward secrecy. > I am truly amazed that you talk to "virtually every" such customer. What an important person you are! However, I have a certain amount of experience in the field myself, and I dispute your findings. Oh, and I've worked on about 10 router vendor's products, too.... > > The SKIP public-values are signed, but the generated session-keys are > > not signed. Current literature suggests that _both_ the public values > > and resulting session-keys be signed to prevent attacks. The signature > > operation is not known to be associative or commutative. > > I am not aware of any requirement that traffic keys MUST be > signed, since there are so many key-distribution protocols > that involve NO signature operation. > Ye Gods Above and Below! You are correct. There are a lot of provably insecure protocols! What do I care? I can find literature references to identification and signatures going back to Crypto '84 (over 10 years in a field barely that old) without leaving my chair. And I don't even have much of a library here at home.... > If you really believe that this is a significant security risk, then > please describe an attack on the protocol, or even the beginnings > of such an attack. I will consider your objection more > seriously then. > It is not my job to prove the protocol insecure. It is your job to prove the protocol secure! My field of expertise is protocols, not cryptology (where I merely am "interested"). I have analysed your protocol in respect to the current cryptological literature available to me. In this particular case, the literature speaks of "direct proof" of knowledge of the shared-secret key. SKIP does not have this "direct proof". When it does, I will consider your protocol more seriously.... > To summarize, I don't believe that you have raised any new > issues in your comments. Only issues that have been discussed > many times over in the last year and a half on this mailing > list. Nor have you described any serious shortcomings or > defects. > I reviewed my comments, and found the word "unacceptable" at least eight (8) times. If the protocol being unacceptable is somehow not a serious shortcoming, why then by all means find somewhere to publish. Just don't bother me anymore! > Also, you have requested no specific changes to the document. > I can do that easily. Start at the first paragraph. Delete the inaccurate overview, which tells nothing about the protocol (instead attacking other session-oriented protocols). Delete all references to "stateless", "messageless" (or "zero-message"), "manual distribution", "storage", "intermediate authentication", and the bloated SKIP header. Beginning with Chapter 3 "Algorithm Discovery", design a key management protocol. Come back again when you are done. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Fri Nov 24 14:06:22 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA19031 (5.65c/IDA-1.4.4 for ); Fri, 24 Nov 1995 11:15:24 -0500 Received: by interlock.ans.net id AA29297 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 24 Nov 1995 11:06:59 -0500 Message-Id: <199511241606.AA29297@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 24 Nov 1995 11:06:59 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 24 Nov 1995 11:06:59 -0500 Date: Fri, 24 Nov 95 14:06:22 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: WG Last Call for SKIP I-D > From: ashar@osmosys.incog.com (Ashar Aziz) > Therefore, at this point in time, I don't have any editorial > action to take, based on your comments. Of course, if there > is clarifying text that you would like to suggest that may > help remove some of the misunderstandings that prompted your > messages, I will gladly add such text, provided you supply > me this text. > For some odd reason, I awoke this morning with the following text in mind. Perhaps it was because I spent the holiday with my family, which enjoys ironic humor. Perhaps it was the private email which thanked me for providing comic relief in regard to my previous SKIP postings. Anyway, I am sure that you will "gladly" add the following to SKIP. Note that I even quoted a portion of your email message: 4.x Master Key Distribution One of the significant features that keeps SKIP "simple" is the required use of SneakerNet to distribute master keys, rather than wastefully passing messages over the InterNet. For each participating node, and each possible future communicating party, the operator is required to hand-configure 1024-bit or 2048-bit D-H public-values. At least one additional party -- the administrator -- is also required to be hand-configured (see section 1.8.3). In addition, a separate signature is hand-configured for each D-H public-value. As noted earlier in section 1.1, the format of the signature is unconstrained. Howver, X.509 certificates MUST be supported (see section 4.2). These may be considerably larger than the D-H public-value itself. An alternate signature mechanism, described in section 4.1, employs smaller MD5 128-bit hash signatures. Support for this shortened form is merely optional, when using the optional certificate discovery protocol described in section 4.3, and beyond the scope of this section. Nota Bene: Experience shows that hand-configuration of long strings of random digits is often frought with difficulty, and the operators cannot dependably verify their own work. The authenticated signatures will help find these problems. For those circumstances where a large number of parties might communicate (such as between clients and servers, or among hosts and routers), the implementation MUST support very large configuration files. Millions of nodes simply means a million or so master keys. If we assume 16 bytes per pre-computed master key, this comes to 16 MegaBytes of storage. Even on very low-end machines, 16MB is a small amount of storage, since 0.5 to 1 GigaByte disks are pretty normal storage amounts these days. Assuming 1024-bit master keys with 2048-bit X.509 certificates are hand-configured in ASCII hex notation, this comes to only 3 GB for the configuration files. Assuming 16 MB spare on a 3 GB disk on a node capable of communicating with a million other nodes in its lifetime is not excessive. The only change is that routers and other terminals will now be required to have hard disks. Also, the master key public-values and signatures may change from time to time. The hand-configured public-values and Certificate Revocation Lists SHOULD NOT change more than once per 6 months. Based on current InterNet growth rates, estimated maintainance staffing should be no more than 4,096 clerks and operators (and 1,024 administrators and management) for each server or router. Think of it as "full employment". 4.3 Certificate Discovery Protocol An optional protocol is described to enable communicating IP-nodes to discover each other's certificate(s). This obviates the need for an on-line certificate directory server. Nota Bene: Since this feature is optional, it cannot be depended upon for master key exchange between parties. However, in order to provide "zero-message" operation and support unidirectional links, there is no error message defined when this feature is not present. The message merely disappears into a black-hole. Therefore, whenever communication unexplicably stops, the operator is recommended to use alternate means (such as the telephone) to communicate with the peer operator for exchange of the public-value and signature. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Sat Nov 25 20:45:14 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13703 (5.65c/IDA-1.4.4 for ); Sat, 25 Nov 1995 20:45:14 -0500 Received: by interlock.ans.net id AA13917 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 25 Nov 1995 20:38:40 -0500 Message-Id: <199511260138.AA13917@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 25 Nov 1995 20:38:40 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 25 Nov 1995 20:38:40 -0500 X-Sender: karn@servo.qualcomm.com (Unverified) X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 25 Nov 1995 21:22:31 -0800 To: "William Allen Simpson" , ipsec@ans.net From: Phil Karn Subject: Re: SKIP wastes bandwidth At 06:57 AM 11/23/95 GMT, William Allen Simpson flamed Ashar Aziz about header overhead: >Because you seem incapable of addition, here is little more clear and >direct comparison: Bill (and the group), I don't like header overhead either, especially when it can be avoided, but there's usually a reason for adding it and I don't see any particular number of bytes that is automatically, under all circumstances "unacceptable". Remember that VJ first did his header compression scheme back in the days of 2400bps modems. The time it took to send 40 bytes at 2400bps was a significant fraction of the total round trip time. Today, with 14.4 and 28.8 modems the store-and-forward delay for such a header is much less, especially in comparison with the fixed and fairly substantial delays in the modem equalizers. As you are undoubtedly familiar, round trip times over a PPP link to even the node on the other side are seldom if ever less than 100ms, and that's a lot of bits when you do the math. Again, if I have two protocols that do the job and one has more header overhead than the other, I'm more likely to pick the one with less overhead. But I can't give you a size above which a protocol becomes automatically "unacceptable". Phil From ipsec-request@ans.net Mon Nov 27 23:54:59 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17183 (5.65c/IDA-1.4.4 for ); Mon, 27 Nov 1995 18:56:55 -0500 Received: by interlock.ans.net id AA04316 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 27 Nov 1995 18:48:19 -0500 Message-Id: <199511272348.AA04316@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 27 Nov 1995 18:48:19 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 27 Nov 1995 18:48:19 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 27 Nov 1995 18:48:19 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 27 Nov 1995 18:48:19 -0500 Date: Mon, 27 Nov 1995 15:54:59 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) To: ipsec@ans.net Subject: Re: WG Last Call for SKIP I-D X-Sun-Charset: US-ASCII >From: Phil Karn > >The SKIP defense to clogging is to have a pre-compute cache > >of master keys. In general when a SKIP node is targeted for clogging, > >it stops computing new master keys. This does NOT result in a > >denial-of-service, since the pre-compute cache can provide > >communications with nodes with which it has pre-computed > >master keys (including brand new network connections). > > Ashar, > > You can deal with clogging in *any* key management protocol by simply > disabling it as long as the attack is in progress, thus disabling the > creation of new associations. Even if the system is not completely > disabled (e.g., if prior associations continue to work) I see this as > less desirable than a protocol that is designed to continue full > functioning even when it is under attack. .. > Again this is essentially a successful (partial) denial of service > brought about by the attack. Phil, This point is worth clarifying. *New* associations can still come in and work during a clogging attack, using the SKIP anti-clogging scheme, even from nodes that have never communicated before with the node under attack, since the cache is a *pre*-compute cache. It isn't necessary to have made a prior association in order for new communications to occur during a clogging attack. Since this pre-compute cache can, with relative ease, accommodate thousands or even millions of nodes, I am not sure I see this as a major drawback. However, it would be trivial to add cookie style anti-clogging to the existing SKIP ICMP message. This can be used in instances when a node is feeling clogged (and not as the default case). This could allow the flexibilility of zero message overhead communications under normal circumstances, and cookie style anti-clogging during a clogging attack. Your comments? >If the cache is not large enough to hold the entire database, then the >attacker can purposely cause it to thrash (presuming he knows the >replacement algorithm in use). Way back in my reckless undergraduate >days we used to see how long we could keep the Cornell campus VM370 >system page thrashing with the minimal amount of billed CPU time. It >was amazingly easy when you put your mind to it... The caching algorithm does not have to be in any way similar to an OS page replacement algorithm. One could always let the cache be a set of nodes that must get through (so they are permanently in the cache, and this could easily number in the tens of thousands) and then let the other parts of the cache be more replaceable. It is worth mentioning that the cookie solution is also a partial solution, since the cookie approach relies on an attacker's inability to observe reverse traffic. Any attacker that can passively monitor, say, a major Internet backbone can come up with enough spoofed IP addresses for which reverse traffic will be visible. Passive monitoring of such a backbone would permit an attacker to conjure enough spoofed IP addresses to swamp a node that relies only on a cookie approach. The existing SKIP anti-clogging mechanism does not rely on an attacker's inability to see reverse traffic. Regards, Ashar. From ipsec-request@ans.net Tue Nov 28 01:06:57 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13789 (5.65c/IDA-1.4.4 for ); Mon, 27 Nov 1995 20:14:12 -0500 Received: by interlock.ans.net id AA05802 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 27 Nov 1995 20:08:20 -0500 Message-Id: <199511280108.AA05802@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 27 Nov 1995 20:08:20 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 27 Nov 1995 20:08:20 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: ashar@osmosys.incog.com (Ashar Aziz) Cc: ipsec@ans.net Subject: Re: WG Last Call for SKIP I-D In-Reply-To: Your message of "Mon, 27 Nov 1995 15:54:59 PST." <199511272348.AA04316@interlock.ans.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 27 Nov 1995 20:06:57 -0500 From: "Perry E. Metzger" Ashar Aziz writes: > it would be trivial to add cookie style anti-clogging > to the existing SKIP ICMP message. In that case, why not use Photuris? > This can be used in instances when a node is feeling clogged (and > not as the default case). That would add a second round trip to the overhead, would it not? Personally, I want to see anti-clogging tokens added to more technology as the default case, not to less. For example, I'd like to see a next generation TCP operate with Photuris style anti-clogging cookies. > It is worth mentioning that the cookie solution > is also a partial solution, since the cookie approach > relies on an attacker's inability to observe reverse > traffic. True enough. It isn't perfect by any means. It would, however, stop the vast majority of such attacks. As it stands now, there are some enormously dangerous clogging attacks that could be performed which threaten the integrity of the internet. You view this as an unimportant situation, but it really is not. Perry From ipsec-request@ans.net Tue Nov 28 01:41:50 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12807 (5.65c/IDA-1.4.4 for ); Mon, 27 Nov 1995 20:44:24 -0500 Received: by interlock.ans.net id AA06279 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 27 Nov 1995 20:35:06 -0500 Message-Id: <199511280135.AA06279@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 27 Nov 1995 20:35:06 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 27 Nov 1995 20:35:06 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 27 Nov 1995 20:35:06 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 27 Nov 1995 20:35:06 -0500 Date: Mon, 27 Nov 1995 17:41:50 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) To: ipsec@ans.net Subject: Re: WG Last Call for SKIP I-D X-Sun-Charset: US-ASCII >From: Phil Karn > > I "accept" no PFS for email right now only because I have no viable > alternative. I am increasingly dissatisfied with the lack of PFS > where it could easily be supported, i.e., in interactive > communications. I generate a new PGP key pair every year or two at > considerable inconvenience (look at my signature list!) just to put > SOME limit on the damage that a compromise could cause. > > This is one reason I've made PFS such a priority in Photuris. Still, > I'll have to accept no PFS when operating in unidirectional > environments until somebody figures out how to do it. > .. > .. > Also true, but the consequences of a secret authentication key > compromise in Photuris are FAR less severe than the compromise of a > SKIP secret key. The effect of a compromise in Photuris would be > limited to enabling active man-in-the-middle attacks which are > inherently more difficult to mount and riskier (in terms of increased > chances of detection) than passive monitoring attacks. If you can > quickly detect the breach in Photuris you can essentially avoid damage > entirely by immediately revoking the compromised key and generating a > new one. In any event, thanks to PFS all prior session traffic is > still protected. In SKIP all this traffic is forever compromised. Phil, We have been discussing this, and there is a PFS solution possible for SKIP, that I believe will satisfy a large percentage of users. The solution is to let the certified DH public key be instead a set of certified DH public keys, each of which have shorter validity than a typical certificate, say one or two weeks. The set of intervals over which each public key is valid would be contiguous and non-overlapping, and the sum of these intervals would equal the validity period of a typical certificate, say six months or a year. Corresponding to each short validity public key in the certificate would be a short validity private key. A short while after each public key expires, the corresponding private key is deleted. This limits the effect of a node compromise to the validity period of a single public key, (e.g. 1 or 2 weeks) thereby providing PFS/back traffic protection for encrypted traffic sent earlier than a single public key validity period. This leaves the issue of making sure that communications can switch over from one certified public key to another without manual intervention (since 1 or 2 weeks is too frequent to expect manual intervention for a large number of nodes). Fortunately, this is easily solved by limiting the switch from one public key to another to occur on an "n" counter update boundary. Since, this contains the sender's notion of time, this allows a receiver to unambigously know which master key to use in order to decrypt/authenticate IP traffic. And all of this can be done without really modifying SKIP, other than to say that certificate management of this type is possible. The advantage of this approach is that it still allows pre-computation of all master keys, (no real-time exponentiations required even for encrypted traffic with PFS) and still permit the redundant high availability configurations (for failover purposes) possible using SKIP. > In summary, I do agree with you when it comes to user requirements. > Regardless of what we decide here, the market will ultimately decide > based on what it considers most important, and it may very will choose > a criterion we have hardly even considered. And then again there may > turn out to be several well defined sets of needs for which one > protocol or the other is best suited, meaning that they end up > coexisting peacefully. Time will tell. Yes, perhaps in time the protocols will end up coexisting peacefully after all. I agree with you that we should let the market decide which one suits their purposes better. Regards, Ashar. From ipsec-request@ans.net Tue Nov 28 04:59:26 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12246 (5.65c/IDA-1.4.4 for ); Tue, 28 Nov 1995 00:06:57 -0500 Received: by interlock.ans.net id AA09412 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 28 Nov 1995 00:00:47 -0500 Message-Id: <199511280500.AA09412@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Nov 1995 00:00:47 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Nov 1995 00:00:47 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: ashar@osmosys.incog.com (Ashar Aziz) Cc: ipsec@ans.net Subject: Re: WG Last Call for SKIP I-D In-Reply-To: Your message of "Mon, 27 Nov 1995 17:41:50 PST." <199511280135.AA06279@interlock.ans.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 27 Nov 1995 23:59:26 -0500 From: "Perry E. Metzger" Ashar Aziz writes: > We have been discussing this, and there is a PFS solution > possible for SKIP, that I believe will satisfy a large percentage > of users. > > The solution is to let the certified DH public key be instead > a set of certified DH public keys, each of which have shorter > validity than a typical certificate, say one or two weeks. Yuck. What a kludge! Whats the point, anyway? I mean, yes, it does improve things a little bit, but its not like people don't still then get months and months and months to try to snatch the keys, and besides, there still aren't any demonstrable good parts to SKIP that make it important enough to hang this sort of bag on it in order to very marginally improve the secrecy. I mean, really, what does SKIP give you? At best, it lets you substitute a lookup in a key database with your initial Photuris exchange, and at the cost of losing Perfect Forward Secrecy (what you are proposing isn't Perfect Forward Secrecy, its just Slightly Improved Forward Secrecy). > A short while after each public key expires, the corresponding > private key is deleted. So what? How do you know no copies exist? And, if someone breaks the key, you lose not just one conversation but many. In any case, as I've said, after all this time, I still don't see what SKIP buys me. Perry From ipsec-request@ans.net Mon Nov 27 15:01:26 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13633 (5.65c/IDA-1.4.4 for ); Tue, 28 Nov 1995 09:14:18 -0500 Received: by interlock.ans.net id AA15569 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 28 Nov 1995 09:03:46 -0500 Message-Id: <199511281403.AA15569@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Nov 1995 09:03:46 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Nov 1995 09:03:46 -0500 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ipsec-icmp-fail-00.txt Date: Mon, 27 Nov 95 10:01:26 -0500 Sender: cclark@CNRI.Reston.VA.US --NextPart A New 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 : ICMP Security Failures Messages Author(s) : P. Karn, W. Simpson Filename : draft-ietf-ipsec-icmp-fail-00.txt Pages : 3 Date : 11/22/1995 This document specifies ICMP messages for indicating failures when using IP Security Protocols (AH, ESP, and Photuris). 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-icmp-fail-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-icmp-fail-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-icmp-fail-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951122163145.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-icmp-fail-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-icmp-fail-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951122163145.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Mon Nov 27 15:01:43 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12870 (5.65c/IDA-1.4.4 for ); Tue, 28 Nov 1995 09:14:19 -0500 Received: by interlock.ans.net id AA15579 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 28 Nov 1995 09:03:50 -0500 Message-Id: <199511281403.AA15579@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Nov 1995 09:03:50 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Nov 1995 09:03:50 -0500 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ipsec-photuris-ext-01.txt Date: Mon, 27 Nov 95 10:01:43 -0500 Sender: cclark@CNRI.Reston.VA.US --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 : Photuris Extensions Author(s) : W. Simpson Filename : draft-ietf-ipsec-photuris-ext-01.txt Pages : 12 Date : 11/22/1995 Photuris is an experimental session-key management protocol intended for use with the IP Security Protocols (AH and ESP). Extensible Exchange Schemes and Attributes are provided to enable future implementation changes without affecting the basic protocol. 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-photuris-ext-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-photuris-ext-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 (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-photuris-ext-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@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951122162347.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-photuris-ext-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-photuris-ext-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951122162347.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Mon Nov 27 15:01:38 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13640 (5.65c/IDA-1.4.4 for ); Tue, 28 Nov 1995 09:14:20 -0500 Received: by interlock.ans.net id AA15574 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 28 Nov 1995 09:03:48 -0500 Message-Id: <199511281403.AA15574@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Nov 1995 09:03:48 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Nov 1995 09:03:48 -0500 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ipsec-photuris-08.txt Date: Mon, 27 Nov 95 10:01:38 -0500 Sender: cclark@CNRI.Reston.VA.US --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 : The Photuris Session Key Management Protocol Author(s) : P. Karn, W. Simpson Filename : draft-ietf-ipsec-photuris-08.txt Pages : 66 Date : 11/22/1995 Photuris is an experimental session-key management protocol intended for use with the IP Security Protocols (AH and ESP). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-photuris-08.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-photuris-08.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-photuris-08.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951122162855.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-photuris-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-photuris-08.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951122162855.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Mon Nov 27 15:02:30 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA19284 (5.65c/IDA-1.4.4 for ); Tue, 28 Nov 1995 09:16:08 -0500 Received: by interlock.ans.net id AA15702 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 28 Nov 1995 09:07:55 -0500 Message-Id: <199511281407.AA15702@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Nov 1995 09:07:55 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Nov 1995 09:07:55 -0500 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ipsec-isakmp-03.txt, .ps Date: Mon, 27 Nov 95 10:02:30 -0500 Sender: cclark@CNRI.Reston.VA.US --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 : Internet Security Association and Key Management Protocol (ISAKMP) Author(s) : D. Maughan, M. Schertler Filename : draft-ietf-ipsec-isakmp-03.txt, .ps Pages : 59 Date : 11/22/1995 This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and cryptographic keys in an Internet environment. A Security Association protocol that negotiates, establishes, modifies and deletes Security Associations and their attributes is required for an evolving Internet, where there will be numerous security mechanisms and several options for each security mechanism. The key management protocol must be robust in order to handle public key generation for the Internet community at large and private key requirements for those private networks with that requirement. The Internet Security Association and Key Management Protocol (ISAKMP) defines the procedures for authenticating a communicating peer, creation and management of Security Associations, key generation techniques, and threat mitigation (e.g. denial of service and replay attacks). All of these are necessary to establish and maintain secure communications (via IP Security Service or any other security protocol) in an Internet environment. 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-isakmp-03.txt". Or "get draft-ietf-ipsec-isakmp-03.ps". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-03.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-03.txt". Or "FILE /internet-drafts/draft-ietf-ipsec-isakmp-03.ps". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951122151208.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951122151208.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Mon Nov 27 15:01:38 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA19332 (5.65c/IDA-1.4.4 for ); Tue, 28 Nov 1995 11:19:44 -0500 Message-Id: <199511281619.AA19332@ftp.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@ftp.ans.net); Tue, 28 Nov 1995 11:12:55 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Nov 1995 11:12:55 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Nov 1995 11:12:55 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Tue, 28 Nov 1995 11:12:55 -0500 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ipsec-photuris-08.txt Date: Mon, 27 Nov 95 10:01:38 -0500 Sender: cclark@CNRI.Reston.VA.US --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 : The Photuris Session Key Management Protocol Author(s) : P. Karn, W. Simpson Filename : draft-ietf-ipsec-photuris-08.txt Pages : 66 Date : 11/22/1995 Photuris is an experimental session-key management protocol intended for use with the IP Security Protocols (AH and ESP). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-photuris-08.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-photuris-08.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-photuris-08.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951122162855.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-photuris-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-photuris-08.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951122162855.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Mon Nov 27 15:01:26 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17341 (5.65c/IDA-1.4.4 for ); Tue, 28 Nov 1995 11:51:41 -0500 Message-Id: <199511281651.AA17341@ftp.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@ftp.ans.net); Tue, 28 Nov 1995 11:46:43 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Nov 1995 11:46:43 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Nov 1995 11:46:43 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Tue, 28 Nov 1995 11:46:43 -0500 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ipsec-icmp-fail-00.txt Date: Mon, 27 Nov 95 10:01:26 -0500 Sender: cclark@CNRI.Reston.VA.US --NextPart A New 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 : ICMP Security Failures Messages Author(s) : P. Karn, W. Simpson Filename : draft-ietf-ipsec-icmp-fail-00.txt Pages : 3 Date : 11/22/1995 This document specifies ICMP messages for indicating failures when using IP Security Protocols (AH, ESP, and Photuris). 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-icmp-fail-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-icmp-fail-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-icmp-fail-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951122163145.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-icmp-fail-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-icmp-fail-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951122163145.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Mon Nov 27 15:01:43 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12052 (5.65c/IDA-1.4.4 for ); Tue, 28 Nov 1995 12:19:53 -0500 Message-Id: <199511281719.AA12052@ftp.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@ftp.ans.net); Tue, 28 Nov 1995 12:13:53 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Nov 1995 12:13:53 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Nov 1995 12:13:53 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Tue, 28 Nov 1995 12:13:53 -0500 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ipsec-photuris-ext-01.txt Date: Mon, 27 Nov 95 10:01:43 -0500 Sender: cclark@CNRI.Reston.VA.US --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 : Photuris Extensions Author(s) : W. Simpson Filename : draft-ietf-ipsec-photuris-ext-01.txt Pages : 12 Date : 11/22/1995 Photuris is an experimental session-key management protocol intended for use with the IP Security Protocols (AH and ESP). Extensible Exchange Schemes and Attributes are provided to enable future implementation changes without affecting the basic protocol. 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-photuris-ext-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-photuris-ext-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 (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-photuris-ext-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@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951122162347.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-photuris-ext-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-photuris-ext-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951122162347.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Mon Nov 27 15:02:30 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA19263 (5.65c/IDA-1.4.4 for ); Tue, 28 Nov 1995 12:49:11 -0500 Message-Id: <199511281749.AA19263@ftp.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@ftp.ans.net); Tue, 28 Nov 1995 12:43:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Nov 1995 12:43:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Nov 1995 12:43:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Tue, 28 Nov 1995 12:43:23 -0500 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ipsec-isakmp-03.txt, .ps Date: Mon, 27 Nov 95 10:02:30 -0500 Sender: cclark@CNRI.Reston.VA.US --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 : Internet Security Association and Key Management Protocol (ISAKMP) Author(s) : D. Maughan, M. Schertler Filename : draft-ietf-ipsec-isakmp-03.txt, .ps Pages : 59 Date : 11/22/1995 This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and cryptographic keys in an Internet environment. A Security Association protocol that negotiates, establishes, modifies and deletes Security Associations and their attributes is required for an evolving Internet, where there will be numerous security mechanisms and several options for each security mechanism. The key management protocol must be robust in order to handle public key generation for the Internet community at large and private key requirements for those private networks with that requirement. The Internet Security Association and Key Management Protocol (ISAKMP) defines the procedures for authenticating a communicating peer, creation and management of Security Associations, key generation techniques, and threat mitigation (e.g. denial of service and replay attacks). All of these are necessary to establish and maintain secure communications (via IP Security Service or any other security protocol) in an Internet environment. 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-isakmp-03.txt". Or "get draft-ietf-ipsec-isakmp-03.ps". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-03.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-03.txt". Or "FILE /internet-drafts/draft-ietf-ipsec-isakmp-03.ps". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951122151208.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951122151208.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Mon Nov 27 15:01:38 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13624 (5.65c/IDA-1.4.4 for ); Tue, 28 Nov 1995 14:51:35 -0500 Message-Id: <199511281951.AA13624@ftp.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@ftp.ans.net); Tue, 28 Nov 1995 14:46:40 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Nov 1995 14:46:40 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Nov 1995 14:46:40 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Tue, 28 Nov 1995 14:46:40 -0500 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ipsec-photuris-08.txt Date: Mon, 27 Nov 95 10:01:38 -0500 Sender: cclark@CNRI.Reston.VA.US --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 : The Photuris Session Key Management Protocol Author(s) : P. Karn, W. Simpson Filename : draft-ietf-ipsec-photuris-08.txt Pages : 66 Date : 11/22/1995 Photuris is an experimental session-key management protocol intended for use with the IP Security Protocols (AH and ESP). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-photuris-08.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-photuris-08.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-photuris-08.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951122162855.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-photuris-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-photuris-08.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951122162855.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Mon Nov 27 15:01:26 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17289 (5.65c/IDA-1.4.4 for ); Tue, 28 Nov 1995 15:20:20 -0500 Message-Id: <199511282020.AA17289@ftp.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@ftp.ans.net); Tue, 28 Nov 1995 15:15:47 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Nov 1995 15:15:47 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Nov 1995 15:15:47 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Tue, 28 Nov 1995 15:15:47 -0500 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ipsec-icmp-fail-00.txt Date: Mon, 27 Nov 95 10:01:26 -0500 Sender: cclark@CNRI.Reston.VA.US --NextPart A New 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 : ICMP Security Failures Messages Author(s) : P. Karn, W. Simpson Filename : draft-ietf-ipsec-icmp-fail-00.txt Pages : 3 Date : 11/22/1995 This document specifies ICMP messages for indicating failures when using IP Security Protocols (AH, ESP, and Photuris). 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-icmp-fail-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-icmp-fail-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-icmp-fail-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951122163145.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-icmp-fail-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-icmp-fail-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951122163145.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Tue Nov 28 10:07:33 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA19346 (5.65c/IDA-1.4.4 for ); Tue, 28 Nov 1995 15:26:51 -0500 Received: by interlock.ans.net id AA01903 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 28 Nov 1995 15:24:56 -0500 Message-Id: <199511282024.AA01903@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Nov 1995 15:24:56 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Nov 1995 15:24:56 -0500 Date: Tue, 28 Nov 95 15:07:33 EST From: hugo@watson.ibm.com To: ipsec@ans.net Subject: "interactive" freshness Ref: Your note of Thu, 23 Nov 95 05:47:21 GMT (attached) Bill, > > > Let's not miss this oportunity to take full advantage of Photuris being > > "bi-directional" by definition. > > > We didn't.... But glad you agree! > > Bill.Simpson@um.cc.umich.edu If you believe that Photuris (through the implementation note of page 26 - ver 08) is really taking advantage of the interaction to generate a fresh, synchronized and authenticated key, then I recommend that you highlight the description of this "mode", e.g., through a special subsection rather than an "implementation note". It should be presented as a feature of Photuris and even encourage people to use it (in many cases it is much better than the change-message). In my opinion this also requires more clarification. For example, let's say that the parties find that the exchange values are unchanged from the previous exchange. What do they send as the Identification_Message? WHat key do they use to authenticate that message (i.e., how do they compute the verification field)? Do they use the previously shared-secret for that? If they use digital signatures, do you want them to freshly sign that message (I guess not)? I'll be glad if you can clarify this over this list and in the draft's text. Hugo From ipsec-request@ans.net Tue Nov 28 10:25:36 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13779 (5.65c/IDA-1.4.4 for ); Tue, 28 Nov 1995 15:44:39 -0500 Received: by interlock.ans.net id AA02406 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 28 Nov 1995 15:35:54 -0500 Message-Id: <199511282035.AA02406@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Nov 1995 15:35:54 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Nov 1995 15:35:54 -0500 Date: Tue, 28 Nov 95 15:25:36 EST From: hugo@watson.ibm.com To: IPSEC@ans.net Subject: length of exponents I gladly noticed that a recommendation was added to the exchange scheme #2 (Phil's 1024 bit prime) stating that exponents between 196 to 256 bits are recommended. I have always insisted that 128 bits as exemplified in section 7.2 is unacceptable low. The next step is to remove the number 128 from the implementation note in section 7.2.2 (page 45), and *moreover* to recommend explicit values in that section. (The implementation note is not recommending the use of 128 but makes it sound as a reasonable choice). I would go one step further and say that "implementations MUST use at least 160 bits for exponents and SHOULD use 256 bits or more". Implementation will be easily tempted to use much shorter exponents; a mandatory minimum, although hard to check, may deter implementations (especially products) from going too short with these exponent. Hugo From ipsec-request@ans.net Mon Nov 27 15:01:43 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18908 (5.65c/IDA-1.4.4 for ); Tue, 28 Nov 1995 15:49:57 -0500 Message-Id: <199511282049.AA18908@ftp.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@ftp.ans.net); Tue, 28 Nov 1995 15:46:16 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Nov 1995 15:46:16 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Nov 1995 15:46:16 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Tue, 28 Nov 1995 15:46:16 -0500 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ipsec-photuris-ext-01.txt Date: Mon, 27 Nov 95 10:01:43 -0500 Sender: cclark@CNRI.Reston.VA.US --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 : Photuris Extensions Author(s) : W. Simpson Filename : draft-ietf-ipsec-photuris-ext-01.txt Pages : 12 Date : 11/22/1995 Photuris is an experimental session-key management protocol intended for use with the IP Security Protocols (AH and ESP). Extensible Exchange Schemes and Attributes are provided to enable future implementation changes without affecting the basic protocol. 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-photuris-ext-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-photuris-ext-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 (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-photuris-ext-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@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951122162347.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-photuris-ext-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-photuris-ext-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951122162347.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Tue Nov 28 10:35:49 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12773 (5.65c/IDA-1.4.4 for ); Tue, 28 Nov 1995 15:52:13 -0500 Received: by interlock.ans.net id AA02737 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 28 Nov 1995 15:46:00 -0500 Message-Id: <199511282046.AA02737@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Nov 1995 15:46:00 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Nov 1995 15:46:00 -0500 Date: Tue, 28 Nov 95 15:35:49 EST From: hugo@watson.ibm.com To: IPSEC@ans.net Subject: anonymity against active attackers Draft 08 (pg 8) still keeps an "old" remark on the mechanism provided by Photuris to keep anonymity. It should be erased. The remark says: The scheme is not foolproof. By posing as the Responder, an active attacker could trick the Initiator into revealing its identity. However, this active attack is considerably more difficult than passive vacuum-cleaner monitoring. Unless the attacker can steal the private/secret key belonging to the Responder, the Initiator will discover the deception when verifying the Identification Exchange. This does not hold anymore. Since the Identification-Messages are now ordered and the Responder sends its Identification_Message only after it received the one from the Inititiator (and after it verified validity), then the Responder will not reveal its identity to a fake/unknown/unauthorized, etc initiator. Definitely a good change! Hugo From ipsec-request@ans.net Mon Nov 27 15:02:30 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12111 (5.65c/IDA-1.4.4 for ); Tue, 28 Nov 1995 16:24:10 -0500 Message-Id: <199511282124.AA12111@ftp.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@ftp.ans.net); Tue, 28 Nov 1995 16:15:45 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Nov 1995 16:15:45 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Nov 1995 16:15:45 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Tue, 28 Nov 1995 16:15:45 -0500 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ipsec-isakmp-03.txt, .ps Date: Mon, 27 Nov 95 10:02:30 -0500 Sender: cclark@CNRI.Reston.VA.US --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 : Internet Security Association and Key Management Protocol (ISAKMP) Author(s) : D. Maughan, M. Schertler Filename : draft-ietf-ipsec-isakmp-03.txt, .ps Pages : 59 Date : 11/22/1995 This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and cryptographic keys in an Internet environment. A Security Association protocol that negotiates, establishes, modifies and deletes Security Associations and their attributes is required for an evolving Internet, where there will be numerous security mechanisms and several options for each security mechanism. The key management protocol must be robust in order to handle public key generation for the Internet community at large and private key requirements for those private networks with that requirement. The Internet Security Association and Key Management Protocol (ISAKMP) defines the procedures for authenticating a communicating peer, creation and management of Security Associations, key generation techniques, and threat mitigation (e.g. denial of service and replay attacks). All of these are necessary to establish and maintain secure communications (via IP Security Service or any other security protocol) in an Internet environment. 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-isakmp-03.txt". Or "get draft-ietf-ipsec-isakmp-03.ps". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-03.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-03.txt". Or "FILE /internet-drafts/draft-ietf-ipsec-isakmp-03.ps". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951122151208.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951122151208.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Tue Nov 28 10:46:39 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12224 (5.65c/IDA-1.4.4 for ); Tue, 28 Nov 1995 17:11:16 -0500 Received: by interlock.ans.net id AA04951 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 28 Nov 1995 17:04:05 -0500 Message-Id: <199511282204.AA04951@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Nov 1995 17:04:05 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Nov 1995 17:04:05 -0500 Date: Tue, 28 Nov 95 15:46:39 EST From: hugo@watson.ibm.com To: IPSEC@ans.net Subject: mandatory encryption for anonymity After having praised Photuris for the good protection of privacy/anonymity, let me disagree with the change in draft 08 that makes encryption of Identification_Message (and Change_Message) mandatory. Mandating symetric encryption (in particular, DES) where not strictly necessary is not advisable. Having this as an option as before was the right thing. The complexity of having this particular option (in addition or together to the existing scheme option) is not worth the effects of mandating encryption. The latter is just an unnecessary obstacle for the fast deployment of Photuris for (at least) many American vendors. Hugo From ipsec-request@ans.net Mon Nov 27 15:31:47 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13611 (5.65c/IDA-1.4.4 for ); Tue, 28 Nov 1995 20:04:34 -0500 Received: by interlock.ans.net id AA08596 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 28 Nov 1995 19:56:57 -0500 Message-Id: <199511290056.AA08596@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Nov 1995 19:56:57 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Nov 1995 19:56:57 -0500 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@CNRI.Reston.VA.US Cc: iesg@CNRI.Reston.VA.US, ipsec@ans.net Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-krawczyk-keyed-md5-01.txt Date: Mon, 27 Nov 95 10:31:47 -0500 Sender: cclark@CNRI.Reston.VA.US --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Keyed-MD5 for Message Authentication Author(s) : H. Krawczyk Filename : draft-krawczyk-keyed-md5-01.txt Pages : 5 Date : 11/22/1995 This document describes a keyed-MD5 mechanism for use as a message authentication code (MAC) (or, integrity check value -- ICV). It is mainly intended for integrity verification of information transmitted over open networks (e.g., Internet) between parties that share a common secret key. The proposed mechanism combines the (key-less) MD5 hash function [RFC-1321] with a shared secret key. The description of keyed-MD5 in this document is independent of its use in any particular protocol. An analogous mechanism can be used in combination with other iterative hash functions, e.g., SHA. 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-krawczyk-keyed-md5-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-krawczyk-keyed-md5-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 (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-krawczyk-keyed-md5-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@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951122172952.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-krawczyk-keyed-md5-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-krawczyk-keyed-md5-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951122172952.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Wed Nov 29 01:14:52 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA19300 (5.65c/IDA-1.4.4 for ); Tue, 28 Nov 1995 20:13:59 -0500 Received: by interlock.ans.net id AA08798 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 28 Nov 1995 20:08:08 -0500 Message-Id: <199511290108.AA08798@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 28 Nov 1995 20:08:08 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 28 Nov 1995 20:08:08 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Nov 1995 20:08:08 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Nov 1995 20:08:08 -0500 Date: Tue, 28 Nov 1995 17:14:52 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) To: ipsec@ans.net Subject: SKIP source release now available Cc: firewall-interest@rsa.com X-Sun-Charset: US-ASCII Folks, We are pleased to announce the free public availability of Sun's implementation of SKIP in source form. Important points about this release that should be highlighted are: - This implementation can be used in commercial products, free of charge, subject to the restrictions described in the software and patent license statements. - Since this is the season of giving, we are also pleased to announce free commercial use of the Stanford public key patents (which cover Diffie-Hellman, DSA and public key in general) to users/OEMs of this package. Sun Microsystems and Cylink have negotiated an agreement by means of which Sun can sublicense commercial use of the Stanford public key patents to the SKIP user and developer community free of charge. For precise details of this license, please consult the README.PATENT file in the SKIP source directory. - In addition to the free use of Stanford patents, there is also a free for commercial use implementation of a high speed bignum package, used for Diffie-Hellman, etc. (Check the file BN_SOFTWARE_LICENSE for precise details on the terms of this license.) Thanks are due to Colin Plumb and Phillip Zimmerman for this software. This means that the community can acquire the source code, port it for use on their platform or inside commercial products without paying any royalties to either Sun or Cylink, subject to the terms of the software and patent licenses. Other details: - For details on downloading the software, point your browser to: http://skip.incog.com - It includes ASN.1 software for encoding/decoding X.509 certificates. An implementation of X.509 certs for SKIP is included. Future releases will support other certificate types popular in the Internet community. - It includes support for ESP with DES and triple DES. AH will be supported in future releases. - GUI tools to administer and control the software. - For more information on release details, consult the README file in the source package. For questions, bug reports or request for help, send mail to freeskip@incog.com Enjoy, Ashar, Tom, Hemma, Martin, Joseph. From ipsec-request@ans.net Wed Nov 29 04:31:51 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12120 (5.65c/IDA-1.4.4 for ); Wed, 29 Nov 1995 10:14:11 -0500 Received: by interlock.ans.net id AA19927 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Nov 1995 10:08:32 -0500 Message-Id: <199511291508.AA19927@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Nov 1995 10:08:32 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Nov 1995 10:08:32 -0500 Date: Wed, 29 Nov 95 09:31:51 EST From: hugo@watson.ibm.com To: IPSEC@ans.net Subject: length of exponents I was asked in a private mail to be more explicit about my recommendation on mandating 160 bit minimal exponent lengths and recommending 256 (and, in any case, to discourage 128 bits). As Photuris08 already explains 1024 bit DH has a current security of about 2^n where n ranges between 86 and 98 (this depepends on the way you extrapolate the already implemented attacks on shorter moduli). If one uses 160 long exponents the security becomes at most 2^80 because of Shanks/Pollard attacks that require roughly 2^{t/2} operations to find an exponent whose length is t (this number is independent of the modulus length). In general, one should consider 2^80 as hard enough. So, as far as the best one can do for 160 bit exponents is to break them in the above complexity we are fine. Less than that becomes the weakest link in the security of the system and thus should be avoided. Let's remember that all the point of going through a Diffie-Hellman computation is to achieve PERFECT FORWARD SECRECY. That is to provide strong and *long-term* security. The point that can be more controversial is that I recommend using even longer than 160 bit exponents. The only reason I do that is to take some "safety margin". Any improvement on the above 2^{t/2} attacks would put at risk the security of using 160 bits. (BTW, these 2^{t/2} attacks are off-line attacks, no need to interact with the "victims"). We have seen in the past results that showed that short RSA exponents are weaker than one can expect (M. Wiener, IEEE Trans IT Vol 36 No 3). [These results do not apply to DH exponents, I am citing it as an example of possibly unexpected weaknesses.] More relevant, P. van Oorschot and M. Wiener have very recent results on attacking short DH exponents. These attacks do not directly apply to safe primes, as recommended by Photuris; they do apply to other classes of primes (e.g., random primes). Mostly importantly, these results are a timely reminder of the caution with which one needs to design protocols that are intended to keep secret information for long time (which, as said, is the whole idea of providing perfect forward secrecy). Another point that was raised in this private mail is why not going beyond 1024. Of course, that is possible, but the computation penalty is bigger. Just notice that a linear increase in exponent length translates into a linear increase in DH computation. On the other hand, the effect of an increase in modulus length is between quadratic to cubic (depeneding on implementation). (And, in any case, if one goes to longer moduli then using too short exponents becomes an even weaker link for the security). Bottom line: I recommend to mandate minimum 160 bit exponents so I get (some) assurance that the product I buy gives me good security, and even more importantly, the implementation that my partner to communication is using gives *me* good security. A recommendation about taking a safety margin and going beyong the 160 bits, will also be, in my opinion, a good thing to do. Hugo From ipsec-request@ans.net Wed Nov 29 15:36:29 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA19844 (5.65c/IDA-1.4.4 for ); Wed, 29 Nov 1995 10:41:39 -0500 Received: by interlock.ans.net id AA20631 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Nov 1995 10:37:51 -0500 Message-Id: <199511291537.AA20631@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Nov 1995 10:37:51 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Nov 1995 10:37:51 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: ashar@osmosys.incog.com (Ashar Aziz) Cc: ipsec@ans.net, firewall-interest@rsa.com Subject: Re: SKIP source release now available In-Reply-To: Your message of "Tue, 28 Nov 1995 17:14:52 PST." <199511290108.AA08798@interlock.ans.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 29 Nov 1995 10:36:29 -0500 From: "Perry E. Metzger" Ashar Aziz writes: > We are pleased to announce the free public availability of Sun's > implementation of SKIP in source form. I'll point out, by the way, that you can get your hands on NRL's IPsec implementation, too, these days. .pm From ipsec-request@ans.net Wed Nov 29 05:11:00 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA20053 (5.65c/IDA-1.4.4 for ); Wed, 29 Nov 1995 12:26:05 -0500 Received: by interlock.ans.net id AA00132 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Nov 1995 12:24:15 -0500 Message-Id: <199511291724.AA00132@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Nov 1995 12:24:15 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Nov 1995 12:24:15 -0500 Date: Wed, 29 Nov 95 10:11:00 EST From: hugo@watson.ibm.com To: IPSEC@ans.net Subject: anonymity against active attackers Correction to a previous message of mine follows (sorry for the confusion). I said that the paragraph in Photuris (bottom of page 8): > > The scheme is not foolproof. By posing as the Responder, an active > > attacker could trick the Initiator into revealing its identity. > > However, this active attack is considerably more difficult than > > passive vacuum-cleaner monitoring. Unless the attacker can steal the > > private/secret key belonging to the Responder, the Initiator will > > discover the deception when verifying the Identification Exchange. is no longer necessary. Actually, it is. I didn't read correctly the participants here. Indeed, a responder acting as a man-in-the-middle *can* trick the initiator to disclose its identity. The actual feature of Photuris (that didn't exist in early versions of the protocol), and which I consider very important, is that an Initiator *cannot* trick the Responder to disclose its identity. This is very important. Otherwise, any Initiator could discover the identity of a user (say a mobile one) by just initiating a Photuris exchange. That's far easier than intercepting communication as a man-in-the-middle. Anyway, pardon my confusion. (It may still be valuable to add to that paragraph in page 8 a remark that the attack does not work on the other direction, namely, an Initiator tricking the Responder to disclose its identity. The text in the draft that ensures that property is at the beginning of section 5 in page 25). Hugo PS: thanks to the person that pointed out to my confusion in a private mail. From ipsec-request@ans.net Wed Nov 29 15:36:29 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17499 (5.65c/IDA-1.4.4 for ); Wed, 29 Nov 1995 12:27:41 -0500 Message-Id: <199511291727.AA17499@ftp.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@ftp.ans.net); Wed, 29 Nov 1995 12:26:09 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Nov 1995 12:26:09 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Nov 1995 12:26:09 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Wed, 29 Nov 1995 12:26:09 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: ashar@osmosys.incog.com (Ashar Aziz) Cc: ipsec@ans.net, firewall-interest@rsa.com Subject: Re: SKIP source release now available In-Reply-To: Your message of "Tue, 28 Nov 1995 17:14:52 PST." <199511290108.AA08798@interlock.ans.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 29 Nov 1995 10:36:29 -0500 From: "Perry E. Metzger" Ashar Aziz writes: > We are pleased to announce the free public availability of Sun's > implementation of SKIP in source form. I'll point out, by the way, that you can get your hands on NRL's IPsec implementation, too, these days. .pm From ipsec-request@ans.net Wed Nov 29 17:42:28 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13691 (5.65c/IDA-1.4.4 for ); Wed, 29 Nov 1995 12:46:39 -0500 Received: by interlock.ans.net id AA00932 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Nov 1995 12:42:33 -0500 Message-Id: <199511291742.AA00932@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Nov 1995 12:42:33 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Nov 1995 12:42:33 -0500 Date: Wed, 29 Nov 1995 12:42:28 -0500 From: "Perry E. Metzger" To: cypherpunks@toad.com, ipsec@ans.net Subject: NRL IPsec/IPv6 code Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission An early version of NRL's 4.4BSDlite based IPsec/IPv6 implementation is up on ftp.c2.org in an appropriately export controlled directory. This isn't an official distribution -- I'm just putting up the code I got because there has been some interest in it. I've been hacking it in to NetBSD of late. Perry From ipsec-request@ans.net Wed Nov 29 07:18:10 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA20096 (5.65c/IDA-1.4.4 for ); Wed, 29 Nov 1995 12:49:09 -0500 Received: by interlock.ans.net id AA01084 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Nov 1995 12:48:00 -0500 Message-Id: <199511291748.AA01084@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Nov 1995 12:48:00 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Nov 1995 12:48:00 -0500 Date: Wed, 29 Nov 95 12:18:10 EST From: hugo@watson.ibm.com To: IPSEC@ans.net Subject: keyed-MD5 I have sumbitted a new version of my internet-draft on keyed MD5 (draft-krawczyk-keyed-md5-01.txt). You may recall that the previous version of this draft (00) presented the construction that was adopted into RFC-1828 (keyed MD5 for IP AH). The reason for the new updated draft is that I am proposing a different construction which keeps all the advantages of the previous one (simplicity, efficiency, short key, no change to MD5 code, etc), but in addition has a significantly better security analysis behind it. To the best of my knowledge, it is the best mode of keyed-MD5 proposed so far among those that enjoy the above properties and have a well understood security analysis behind it. (I personally believe it will make it until the basic MD5 function will be dropped by cryptanalysis or performance, since a practical breaking of this message authentication algorithm would imply severe weaknesses of the underlying hash function.) My previous draft was a compromise between improving on the by-then WG official keyed-MD5 proposal and what seemed to be acceptable to the RFC editors. It was not, in particular, the best solution available at the time. In the meantime, we have even further improved in some aspects of this construction. In particular, it enjoys now very clear analysis advantages relative to other proposals (including my previous one). I hope that you agree with me that it is not too late to move to this new proposal. It involves no difficulty for existing implementations to change the function, and it offers a significantly better understood security. On the other hand, it is better to do it now before these standards are widely deployed in products. As an "appendix" to this note I am attaching some more information about this construction that does not appear in the draft. People interested to better understand the issues involved here are encouraged to read it. Hugo ************************************************************************* The following is intended to complement the information provided in the draft (draft-krawczyk-keyed-md5-01.txt) itself about the considerations and rationale behind the proposed function. I recommend you first read the draft. Background references: the reference [BCK1] in the paper has not yet been published, but I will make it available on a web site this week (I will send a message about that). That paper deals with the general theory of building pseudorandom functions (from which MACs are a particular case) out of iterated hash functions a la MD5. It does not present the specific construction I described in the draft; it develops the mathematical tools to analyze these constructions and presents some (other) examples. It is not easy to read (unfortunately, the analysis there is quite involved and directed more for the "math types"). The "nested" construction (as I call the function that I am proposing in the new internet draft) is tailored in particular to message authentication, and as such has a simpler and tighter security analysis. Its detailed analysis will be presented in a paper [BCK2] that I plan to complete before the RSA conference in January, where I will present it. Here I present some more details than those appearing in the internet-draft as for the rationale behind this construction. Except for the actual mathematical details and formalism of the analysis the information given in the draft and here is quite complete. In what follows you will need some "patience" before I get to the actual construction as proposed in the draft. The basis of the methodology introduced in [BCK1] is to consider hash functions that are keyed through their "initial variable" (IV) (sometimes called 'chaining variable'), that is, the usually fixed IV is replaced by a value K which serves as the (secret) key to the function. Let's denote by MD5_K(x) the result of applying MD5 to a string x, when the IV of MD5 is initialized to K (here K is a random string of length 128). The basic nested construction for keyed-MD5 would be MAC(K1,K2,x) = MD5_K2(MD5_K1(x)) where K1 and K2 are two *different* keys each of length 128 bits, and x is the information being authenticated. (The secret keys K1 and K2 are shared by the communicating parties). We can prove (using much simpler tools than [BCK1]) that for this construction to be secure it is enough that 1) an adversary that *does not know* K1 cannot find x and x' such that MD5_K1(x)=MD5_K1(x'); and 2) an adversary that *does not know* K2 and sees the values of MD5_K2 on a sequence of 512-bits strings y1,y2,... cannot compute by itself the full result of MD5_K2 on any other string y. Both conditions can be further weakened but to present that we need more definitions and notation. But even the conditions as stated above are already weaker than other assumptions on MD5 used for this kind of analysis (including those needed to analyze the construction in RFC1828). The regular (and basic) assumption on MD5 is that collisions cannot be found even when the IV is fixed and known. Here (condition (1)) we are requiring a much weaker assumption, namely, collision resistance (of MD5_K1) when the IV is random and *secret*. Indeed, a far much harder task for the attacker. (This assumption can be further weakened if you notice that the adversary never gets the value of MD5_K1 on any string, but just the result after the additional MD5_K2 is applied). Another approach commonly used in the analysis of MD5-like functions is to consider these functions (ot their compression function) as "random functions". In such cases, one is assuming that the result of this (compression) function cannot be predicted even on a single-bit basis (i.e., if I ask you what will be the value of the 15th bit of the result of the function on a given input, your ability to predict it would be no better than 1/2; if I ask you to predict a whole byte your expected success probability is only 1/256, and so on). Instead (condition (2)), we are only asking that predicting the *whole* 128 bit output (of MD5_K2) is hard, e.g. can succeed with probability at most 2^{-64}. This is a very significant difference. For example, while the discovery of any statistical bias in the output of MD5 could rend the function useless (or very weak) for uses where full randomness is required, it could still make a very good MAC under the above construction. (Again, our actual requirement is weaker; just notice that although the adversary sees the function MD5_K2 computed on some strings, it never gets to entirely see these strings since they contain the unknown substring MD5_K1(x)). Now, back to the proposed MAC(K,x)= MD5(K,pad2,MD5(K,pad1,x)). This may seem quite different than the function described above. Especially that it uses only one 128 bit key K. However, if you know how MD5 works you will notice that this is *exactly*: MD5_K2(MD5_K1(x)) where K1=MD5'(K,pad1) K2=MD5'(K,pad2) (MD5' stands for a single iteration of MD5 applied to one 512 bit block without length padding). The idea is that K1 and K2 in the original construction are derived from one 128-bit key using the compression function of MD5 and with *different* pads pad1 and pad2. We do this to avoid defining a 256 bit key, and to avoid mandating the keying of MD5 IVs. The latter would prevent the use of MD5 as a "pure" black-box (althought the implementation of a keyed IV is quite trivial and explained in the draft for the sake of increased efficiency). The additional assumption we need for this derivation of K1 and K2 from a single K is that these two keys are "computationally independent", i.e. that one cannot infer on the value of K1 from knowing K2, and viceversa. This requires a relatively weak pseudorandomness assumption on the compression function of MD5, e.g., reasonable mixing properties (which is related to the basic design of the compression function of MD5 as a block cipher). As for the choice of values for pad1 and pad2, I chose them arbitrarily to have a very simple and "portable" description. The only "structure" behind these particular values is that the two bytes x'36' and x'5C' have half of the bits in common and half of them different making the Hamming distance between the pads a big one; this is intended to exploit as much as possible the mixing properties of MD5. As for the best attack known on this proposal it requires knowing the result of keyed-MD5 on about 2^64 known (but of the same length) messages, and all of which use the *same* key. As explained in the draft, this is totally impractical. From ipsec-request@ans.net Wed Nov 29 04:31:51 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA20115 (5.65c/IDA-1.4.4 for ); Wed, 29 Nov 1995 12:59:31 -0500 Message-Id: <199511291759.AA20115@ftp.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@ftp.ans.net); Wed, 29 Nov 1995 12:54:10 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Nov 1995 12:54:10 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Nov 1995 12:54:10 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Wed, 29 Nov 1995 12:54:10 -0500 Date: Wed, 29 Nov 95 09:31:51 EST From: hugo@watson.ibm.com To: IPSEC@ans.net Subject: length of exponents I was asked in a private mail to be more explicit about my recommendation on mandating 160 bit minimal exponent lengths and recommending 256 (and, in any case, to discourage 128 bits). As Photuris08 already explains 1024 bit DH has a current security of about 2^n where n ranges between 86 and 98 (this depepends on the way you extrapolate the already implemented attacks on shorter moduli). If one uses 160 long exponents the security becomes at most 2^80 because of Shanks/Pollard attacks that require roughly 2^{t/2} operations to find an exponent whose length is t (this number is independent of the modulus length). In general, one should consider 2^80 as hard enough. So, as far as the best one can do for 160 bit exponents is to break them in the above complexity we are fine. Less than that becomes the weakest link in the security of the system and thus should be avoided. Let's remember that all the point of going through a Diffie-Hellman computation is to achieve PERFECT FORWARD SECRECY. That is to provide strong and *long-term* security. The point that can be more controversial is that I recommend using even longer than 160 bit exponents. The only reason I do that is to take some "safety margin". Any improvement on the above 2^{t/2} attacks would put at risk the security of using 160 bits. (BTW, these 2^{t/2} attacks are off-line attacks, no need to interact with the "victims"). We have seen in the past results that showed that short RSA exponents are weaker than one can expect (M. Wiener, IEEE Trans IT Vol 36 No 3). [These results do not apply to DH exponents, I am citing it as an example of possibly unexpected weaknesses.] More relevant, P. van Oorschot and M. Wiener have very recent results on attacking short DH exponents. These attacks do not directly apply to safe primes, as recommended by Photuris; they do apply to other classes of primes (e.g., random primes). Mostly importantly, these results are a timely reminder of the caution with which one needs to design protocols that are intended to keep secret information for long time (which, as said, is the whole idea of providing perfect forward secrecy). Another point that was raised in this private mail is why not going beyond 1024. Of course, that is possible, but the computation penalty is bigger. Just notice that a linear increase in exponent length translates into a linear increase in DH computation. On the other hand, the effect of an increase in modulus length is between quadratic to cubic (depeneding on implementation). (And, in any case, if one goes to longer moduli then using too short exponents becomes an even weaker link for the security). Bottom line: I recommend to mandate minimum 160 bit exponents so I get (some) assurance that the product I buy gives me good security, and even more importantly, the implementation that my partner to communication is using gives *me* good security. A recommendation about taking a safety margin and going beyong the 160 bits, will also be, in my opinion, a good thing to do. Hugo From ipsec-request@ans.net Wed Nov 29 18:44:48 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA19719 (5.65c/IDA-1.4.4 for ); Wed, 29 Nov 1995 13:53:21 -0500 Received: by interlock.ans.net id AA02722 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Nov 1995 13:44:53 -0500 Message-Id: <199511291844.AA02722@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Nov 1995 13:44:53 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Nov 1995 13:44:53 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: hugo@watson.ibm.com Cc: IPSEC@ans.net Subject: Re: keyed-MD5 In-Reply-To: Your message of "Wed, 29 Nov 1995 12:18:10 EST." <199511291748.AA01084@interlock.ans.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 29 Nov 1995 13:44:48 -0500 From: "Perry E. Metzger" hugo@watson.ibm.com writes: > I have sumbitted a new version > of my internet-draft on keyed MD5 (draft-krawczyk-keyed-md5-01.txt). [...] > I hope that you agree with me that it is not too late to move to > this new proposal. It involves no difficulty for existing implementations > to change the function, and it offers a significantly better understood > security. On the other hand, it is better to do it now before these > standards are widely deployed in products. I think it might be a good idea to adopt it, and even to make it mandatory, but the existing RFC is out. If the consensus is to adopt it, we'll have to make this a new transform in addition to the old rather than a replacement for the old -- too many people have already coded to the old spec. Were we to adopt the idea, it would probably also be best to simply put this in a new and separate RFC until the entire protocol is advanced in the standardization process, and mandate it at that point. In any case, your proposal requires some study... Perry