From owner-ipsec@portal.ex.tis.com Mon Jan 4 11:30:47 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA16325 for ; Mon, 4 Jan 1999 11:30:46 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA20257 for ipsec-outgoing; Mon, 4 Jan 1999 09:51:48 -0500 (EST) Message-Id: X-Sender: balenson@pop.hq.tis.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 04 Jan 1999 10:09:46 -0500 To: ipsec@tis.com From: "David M. Balenson" Subject: REMINDER: Jan 6th Early Bird Deadline for NDSS '99 Cc: balenson@tis.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_915480586==_" Sender: owner-ipsec@ex.tis.com Precedence: bulk --=====================_915480586==_ Content-Type: text/plain; charset="us-ascii" --=====================_915480586==_ Content-Type: text/plain; charset="us-ascii" S A V E $ 7 0 O F F R E G I S T R A T I O N F E E ! ! R E G I S T E R B Y J A N U A R Y 6 , 1 9 9 9 THE INTERNET SOCIETY'S 1999 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM February 3-5, 1999 Catamaran Resort Hotel San Diego, California Program Chairs: Steve Kent, BBN Technologies Gene Tsudik, USC/Information Sciences Institute ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss99 KEYNOTE SPEAKER: Whitfield Diffie, Sun Microsystems. Co-author of "Privacy on the Line: The Politics of Wiretapping and Encryption." THIS YEAR'S TOPICS INCLUDE: - Secure Password-Based Protocol for Downloading a Private Key - A Real-World Analysis of Kerberos Password Security - Secure Remote Access to an Internal Web Server - Security and the User - Experimenting with Shared Generation of RSA Keys - Addressing the Problem of Undetected Signature Key Compromise - Practical Approach to Anonymity in Large Scale Electronic Voting Schemes - Securing the Internet's Exterior Routing Infrastructure - Distributed Policy Management for Java 1.2 - Distributed Execution with Remote Audit - An Algebra for Assessing Trust in Certification Chains - A Network Security Research Agenda - PGRIP: PNNI Global Routing Infrastructure Protection - A Cryptographic Countermeasure Against Connection Depletion Attacks - IPSec: Friend or Foe? EXPANDED PRE-CONFERENCE TECHNICAL TUTORIALS: - Principles of Network Security (Dr. Stephen T. Kent, BBN Technologies) - Optical Network Security (Jeff Ingle and Dr. Eric Harder, NSA) - Electronic Payment Systems (Dr. B. Clifford Neuman, USC/ISI) - Windows NT Security (Dominique Brezinski, Secure Computing Corp.) - Web Security and Beyond (Dr. B. Clifford Neuman, USC/ISI) - JAVA Security (Dr. Gary McGraw, Reliable Software Technologies) Full details and biographies at http://www.isoc.org/ndss99/technical.shtml --=====================_915480586==_ Content-Type: text/plain; charset="us-ascii" ---------------------------------------------------------------------- David M. Balenson, Publicity Chair, NDSS '99 TIS Labs at Network Associates, Inc. 3060 Washington Road, Suite 100, Glenwood, MD 21738 USA balenson@tis.com; 443-259-2358; fax 301-854-4731 --=====================_915480586==_-- From owner-ipsec@portal.ex.tis.com Mon Jan 4 11:44:33 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA16457 for ; Mon, 4 Jan 1999 11:44:30 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA21143 for ipsec-outgoing; Mon, 4 Jan 1999 11:51:47 -0500 (EST) Message-Id: <199901041710.JAA17521@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: dharkins owned process doing -bs X-Authentication-Warning: dharkins-ss20.cisco.com: dharkins@localhost didn't use HELO protocol To: ipsec@tis.com Subject: draft-ietf-ipsec-isakmp-mode-cfg-04.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17519.915469858.1@cisco.com> Date: Mon, 04 Jan 1999 09:10:58 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk I just noticed that draft-ietf-ipsec-isakmp-mode-cfg-04.txt (which has expired by the way) uses the value 6 for the exchange. This value is from a pool, 6-31, reserved for future ISAKMP use. Exchanges which use ISAKMP are supposed to use exchanges from either the DOI Specific pool (which is why IKE exchanges start at 32) or from the Private Use Range. Which brings up another point. There is no "reserved to IANA" pool for new exchanges. Is that an oversight? How does the WG envision advancing drafts which define new exchanges to standards track? The IANA Considerations section of RFC2408 mentions that "Security Protocols" have to have a standards-track RFC to have a magic number assigned but there's no pool to assign it from. And what should draft-ietf-ipsec-isakmp-mode-cfg-04.txt do? Use a Private Use number until (if?) it's advanced to standards track when it can get an IANA-assigned number? Various people have more exchanges in the works. The procedure should be defined before draft writers start assigning numbers themselves and conflicts arise. Dan. From owner-ipsec@portal.ex.tis.com Mon Jan 4 14:01:58 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA17446 for ; Mon, 4 Jan 1999 14:01:58 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA21835 for ipsec-outgoing; Mon, 4 Jan 1999 14:18:55 -0500 (EST) Message-ID: <31946FC09021D211BE9B00104BD1DEEE064479@dukat.psti.com> From: Jerome Etienne To: "'ipsec@tis.com'" Subject: explicite or implicit IV for ike encryption Date: Mon, 4 Jan 1999 14:51:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk in the rfc, there are a lot of text in the appendix (rfc2409) to explain how to choose the Initial value for the encryption of the ike packet and the way to avoid to be out of sync. so i doubt... the encryption use a explicit IV (as in rfc2405 in case of DES ) or an implicit one (as imply the text about the "out of sync") ? i have assumed a explicit one, because an implicit one is difficult (impossible ?) to handle in case of a network congestion. From owner-ipsec@portal.ex.tis.com Wed Jan 6 09:20:19 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA22044 for ; Wed, 6 Jan 1999 09:20:19 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA29817 for ipsec-outgoing; Wed, 6 Jan 1999 08:39:54 -0500 (EST) Message-ID: <3692AAC0.4876E55B@lucent.com> Date: Tue, 05 Jan 1999 19:13:52 -0500 From: Sashidhar Annaluru Organization: Lucent Technologies X-Mailer: Mozilla 4.05 [en]C-EMS-1.4 (WinNT; U) MIME-Version: 1.0 To: ipsec Subject: Can ID be different than SubjectAltName field of the Certificate Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi All, When we use Certificates for authentication, can the ID payload be IP address and the subjectAltName field in the certificate be rfc822name? Thanks in advance Sashidhar Annaluru avs@lucent.com From owner-ipsec@portal.ex.tis.com Wed Jan 6 09:20:47 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA22054 for ; Wed, 6 Jan 1999 09:20:47 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA00039 for ipsec-outgoing; Wed, 6 Jan 1999 09:06:59 -0500 (EST) Message-Id: <199901061426.JAA25923@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;;@tis.com@tis.com;;;;;;;; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-sps-00.txt Date: Wed, 06 Jan 1999 09:26:58 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --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 : Security Policy System Author(s) : L. Sanchez, M. Condell Filename : draft-ietf-ipsec-sps-00.txt Pages : 69 Date : 05-Jan-99 This document describes a distributed system that provides the mechanisms needed for discovering, accessing and processing security policy information of hosts, subnets or networks of a security domain. In this system policy clients and servers exchange information using the Security Policy Protocol. The protocol defines how the policy information is exchanged, processed, and protected by clients and servers. The system accommodates topology changes, hence policy changes, rather easily without the scalability constraints imposed by static reconfiguration of each client. The protocol is extensible and flexible. It allows the exchange of complex policy objects between clients and servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-sps-00.txt Internet-Drafts are also 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-sps-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-sps-00.txt". NOTE: The mail server at ietf.org 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. 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@ietf.org" Content-Type: text/plain Content-ID: <19990105170405.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-sps-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-sps-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990105170405.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@portal.ex.tis.com Wed Jan 6 23:57:47 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA19935 for ; Wed, 6 Jan 1999 23:57:46 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id XAA02550 for ipsec-outgoing; Wed, 6 Jan 1999 23:58:06 -0500 (EST) Message-Id: <3.0.5.32.19990107001411.007c0460@world.std.com> X-Sender: dpj@world.std.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 07 Jan 1999 00:14:11 -0500 To: Ramon Hontanon From: David Jablon Subject: Re: Basic IKE authentication question Cc: ipsec@tis.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 03:08 PM 12/30/98 -0500, Ramon Hontanon wrote: >What are the available options for peer authentication before an IPsec >tunnel can be established? I suspect that they are: > >- Pre-shared keys (i.e. some string that both peers agree upon in advance) >- X.509 certs from a Certificate Authority > >But how about: > >- Unverified public key exchange (like ssh) >- Manual distribution of public keys (Cisco's IKE implementation) ... and don't forget: - password-authenticated key exchange (like EKE, SPEKE, SRP) This is like "pre-shared keys", but stronger in case the key is small or brute-forcable. -- dpj ------------------------- David P. Jablon Integrity Sciences, Inc. dpj@world.std.com +1 508 898 9024 From owner-ipsec@portal.ex.tis.com Thu Jan 7 10:40:25 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA26342 for ; Thu, 7 Jan 1999 10:40:25 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA04119 for ipsec-outgoing; Thu, 7 Jan 1999 09:57:08 -0500 (EST) Message-Id: <199901071516.KAA28054@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;;@tis.com@tis.com;;;;;;;; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-dhcp-01.txt Date: Thu, 07 Jan 1999 10:16:38 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --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 : Dynamic configuration of IPSEC VPN host using DHCP Author(s) : B. Patel Filename : draft-ietf-ipsec-dhcp-01.txt Pages : 5 Date : 06-Jan-99 IPSEC [2] is a protocol suite defined by IETF working group on IP security to secure communication at the network layer between communicating peers. Among many applications enabled by IPSEC, an interesting and useful application is connect a remote host (e.g., roaming user) to the intranet through SNG (or secure network gateway) using IPSEC tunnels. A remote host on the public internet would connect to a secure network gateway and then establish an IPSEC tunnel between itself and SNG. All the traffic between the remote host and the intranet will be carried over the IPSEC tunnel via SNG as shown in the figure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-dhcp-01.txt Internet-Drafts are also 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-dhcp-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-dhcp-01.txt". NOTE: The mail server at ietf.org 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. 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@ietf.org" Content-Type: text/plain Content-ID: <19990106115215.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-dhcp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-dhcp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990106115215.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@portal.ex.tis.com Thu Jan 7 11:39:58 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA26793 for ; Thu, 7 Jan 1999 11:39:58 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA04530 for ipsec-outgoing; Thu, 7 Jan 1999 11:31:09 -0500 (EST) Message-Id: <199901071650.LAA20019@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: Anycast In-Reply-To: Your message of "Wed, 16 Dec 1998 14:33:53 PST." <199812162233.OAA27474@kebe.eng.sun.com> Date: Thu, 07 Jan 1999 11:50:43 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>>> "Dan" == Dan McDonald writes: Dan> Assuming my understanding of anycast is still up to snuff (it may Dan> not be), and that you've solve multicast key distribution, what you Dan> can have happen is this: Dan> 0.) Anycast keys are distributed, a node sends to the anycast Dan> address using that IPsec SA. Dan> 1.) The node that handles the anycast traffic accepts the packet, Dan> and turns around a response. This response is to a unicast address, Dan> and if you use source address as a selector, it comes from a Dan> "different" source address. This should kick off an IKE Dan> negotiation. I think that we can avoid introducing the multicast problem if one assumes that static keys are not possible. Instead, one initiates to an anycast address. An IKE responder, seeing that it was initiated to an anycast address either: 1. initiates with its real address and provides some kind of proof that it is in fact the anycast address. This is a weird kind of variarion on the initial-contact since the anycast service provider's response must cause the original initiator to drop it's ISAKMP SA, and use this new ISAKMP SA. 2. replies, but from its real address. This requires special handling on the initiator's side to recognize that the anycast ISAKMP has been replied to by a different IP address. In both cases, some kind of proof is required, probably in the form of a certificate binding the anycast address and the physical address. (SPKI/SDSI groups would be nice here) Dan> 2.) The remaining traffic is protected with a pair of unicast SAs Dan> that were negotiatied by the anycast handler and the original node. My personal opinion is that anycast seems neat, but that protecting connections to such addresses is dubious at best. :!mcr!: | Network and security consulting/contract programming Michael Richardson | Firewalls, TCP/IP and Unix administration Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine. From owner-ipsec@portal.ex.tis.com Thu Jan 7 13:26:54 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA27468 for ; Thu, 7 Jan 1999 13:26:54 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA05108 for ipsec-outgoing; Thu, 7 Jan 1999 13:27:10 -0500 (EST) Message-ID: <3695017F.CAEAE05@redcreek.com> Date: Thu, 07 Jan 1999 10:48:31 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Patel, Baiju V" CC: ipsec@tis.com Subject: comments on draft-ietf-ipsec-dhcp-01.txt References: <199901071516.KAA28054@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Following is a (probably not comprehensive) list of initial comments: - the current draft only deals with configuring the internal sgw interface; however, this mechanism could be extended in a straightforward manner to include one or more hosts behind the sgw, especially if the sgw is a bump-in-the-wire encryptor protecting one host, but also in other cases. - item 2 in section section 2.2 says the dhcp sa should be deleted after the internal interface is configured since later dhcp traffic will be carried over the vpn tunnel. This presumes that a tunnel will be established which will permit (perhaps other things) dhcp traffic. Since protocol is a valid filtering criteria, this presumption may be incorrect. Perhaps this text should be somehow qualified (or removed). - section 2.3, item 1 suggests that some client ID (besides the MAC) be placed in the chaddr field of the dhcp message. The text goes on to say that this field is not interpreted by gateway or dhcp server. However, existing dhcp implementations may use the MAC from this field to select the appropriate config parameters from the dhcp database. The suggested mechanism would require that the client ID be used by the dhcp server for this purpose, rather than the MAC. Perhaps some additional language noting this would be in order, or perhaps this requirement should be dropped, and the client hardware address (MAC) should remain untouched. - section 2.3, item 2 designates a short lifetime for the dhcp sa, and says that all future dhcp communication should use the vpn sa. For the reasons noted earlier, this language should be modified. I do agree that the initial SA should be dhcp-only, but not that it needs to be immediately dropped. I think some sort of wildcard needs to be used in the client ID for IKE so that subsequent DHCP operations for either the internal interface or another internal host will succeed. I will concede that this may not be in keeping with a given installation's security policy, and hence, should be configurable. I would also point out that there are other DHCP config operations which may occur using this (or another dhcp) SA, including all of those suggested in isakmp-mode-cfg. Scott From owner-ipsec@portal.ex.tis.com Mon Jan 11 08:57:02 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA08000 for ; Mon, 11 Jan 1999 08:57:02 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA16660 for ipsec-outgoing; Mon, 11 Jan 1999 08:10:25 -0500 (EST) From: "Kalyan Chakravarthy Bade" To: Subject: Management of Ceritificates in IKE Date: Mon, 11 Jan 1999 16:12:36 +0530 Message-ID: <01be3d4f$1a6b4160$320110ac@garfield.roc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi In IKE, how do we manage the certificates in digital signature authentication? Is it ok if we get the certificates of peers out of band, say by e-mail from the peer itself and use them ? or do we need to get the certificate chain from the CA ? And is there any protocol to manage the certificate repository ? Thanks in advance, Kalyan. From owner-ipsec@portal.ex.tis.com Mon Jan 11 09:09:26 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA08172 for ; Mon, 11 Jan 1999 09:09:25 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA17008 for ipsec-outgoing; Mon, 11 Jan 1999 09:23:23 -0500 (EST) Message-ID: <91AE69321799D211AEC500105A9C469605D7B2@SOTHMXS05> From: Greg Carter To: ipsec@tis.com, "'Kalyan Chakravarthy Bade'" Subject: RE: Management of Ceritificates in IKE Date: Mon, 11 Jan 1999 09:39:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk > ---------- > From: Kalyan Chakravarthy Bade[SMTP:kalyan@trinc.com] > Sent: Monday, January 11, 1999 5:42 AM > To: ipsec@tis.com > Subject: Management of Ceritificates in IKE > > Hi > > In IKE, how do we manage the certificates in digital signature > authentication? > Is it ok if we get the certificates of peers out of band, say by e-mail > from > the peer itself and use them ? or do we need to get the certificate chain > from the CA > ? > Yes you can get the end entity certificate out of band, it does not need to come in the IKE exchange, however this is usually the most convenient. As for the CA certificate, before beginning an IKE exchange you will always trust at least one CA. When validating the peers certificate you must be able to build a chain of trust from the CA that signed the peers certificate to the CA you trust. This "chain" can be delivered to you in IKE, or you can build it yourself (look it up using LDAP). The important point being that you must be able to establish a link between the CA you trust and the CA that the peers certificate was signed by. > And is there any protocol to manage the certificate repository ? > LDAP (X.500) are the most common, assuming X.509 certificates. Bye. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com From owner-ipsec@portal.ex.tis.com Mon Jan 11 11:32:30 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA09610 for ; Mon, 11 Jan 1999 11:32:30 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA17501 for ipsec-outgoing; Mon, 11 Jan 1999 11:41:34 -0500 (EST) Message-Id: <4.1.19990111085800.03cb0040@idi-fk-gw.abhiweb.com> X-Sender: rodney@idi-fk-gw.abhiweb.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 11 Jan 1999 08:58:38 -0800 To: Sashidhar Annaluru From: Rodney Thayer Subject: Re: Can ID be different than SubjectAltName field of the Certificate Cc: ipsec@tis.com In-Reply-To: <3692AAC0.4876E55B@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Not if you want to use the ID payload to decide what certificate to use, so no. At 07:13 PM 1/5/99 -0500, you wrote: >Hi All, > >When we use Certificates for authentication, can the ID payload be IP address >and the >subjectAltName field in the certificate be rfc822name? > >Thanks in advance >Sashidhar Annaluru >avs@lucent.com > > > From owner-ipsec@portal.ex.tis.com Mon Jan 11 16:10:06 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA12203 for ; Mon, 11 Jan 1999 16:10:06 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA18316 for ipsec-outgoing; Mon, 11 Jan 1999 16:25:31 -0500 (EST) From: dletendr@galea.com X-Lotus-FromDomain: GALEA To: ipsec@tis.com Message-ID: <852566F6.00770AB9.00@gotlib.galea.com> Date: Mon, 11 Jan 1999 16:45:24 -0500 Subject: Test Vectors Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@ex.tis.com Precedence: bulk I am looking for test cases for DES-CBC. I tried some compatibility testing with other products. I want to check if either I am doing something wrong or is the other product doing something wrong. Does anyone have valid test cases for DES-CBC? From owner-ipsec@portal.ex.tis.com Mon Jan 11 16:57:55 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA13309 for ; Mon, 11 Jan 1999 16:57:55 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA18425 for ipsec-outgoing; Mon, 11 Jan 1999 16:52:30 -0500 (EST) Date: Mon, 11 Jan 1999 14:04:42 -0800 From: jimg@mentat.com (Jim Gillogly) Message-Id: <199901112204.OAA19582@zendia.mentat.com> To: dletendr@galea.com Subject: Re: Test Vectors Cc: ipsec@tis.com X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk dltendr writes: > I am looking for test cases for DES-CBC. I tried some compatibility > testing with other products. I want to check if either I am doing > something wrong or is the other product doing something wrong. Does anyone > have valid test cases for DES-CBC? Try NIST Special Publication 800-17 from http://csrc.nist.gov/cryptval/#46-2 . Requires Acrobat reader. Jim Gillogly From owner-ipsec@portal.ex.tis.com Tue Jan 12 03:48:09 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA01341 for ; Tue, 12 Jan 1999 03:48:08 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id DAA20024 for ipsec-outgoing; Tue, 12 Jan 1999 03:17:31 -0500 (EST) Message-ID: <369B09B9.C74DF97F@checkpoint.com> Date: Tue, 12 Jan 1999 10:37:13 +0200 From: Tamir Zegman Organization: Check Point X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Rodney Thayer , ipsec@tis.com Subject: Re: Can ID be different than SubjectAltName field of theCertificate References: <4.1.19990111085800.03cb0040@idi-fk-gw.abhiweb.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk In aggressive mode, the initiator ID is sent before the responder has a chance to send his certificate request. Therefore, if we adhere to this restriction, an aggressive mode initiator will have to choose the certificate before receiving the certificate request from the responder. This restricts aggressive mode with certificates to scenarios in which the responder know in advance the CA the responder trusts. While aggressive mode has other restrictions, do want want to impose more? What do we have to gain from having the same content in both ID payload and subjectAltName? Tamir and Moshe. Rodney Thayer wrote: > Not if you want to use the ID payload to decide what certificate to use, > so no. > > At 07:13 PM 1/5/99 -0500, you wrote: > >Hi All, > > > >When we use Certificates for authentication, can the ID payload be IP address > >and the > >subjectAltName field in the certificate be rfc822name? > > > >Thanks in advance > >Sashidhar Annaluru > >avs@lucent.com > > > > > > From owner-ipsec@portal.ex.tis.com Tue Jan 12 09:37:36 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA18191 for ; Tue, 12 Jan 1999 09:37:36 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA21083 for ipsec-outgoing; Tue, 12 Jan 1999 09:00:35 -0500 (EST) Message-ID: <369B5604.95B3812C@ire-ma.com> Date: Tue, 12 Jan 1999 09:02:45 -0500 From: Bronislav Kavsan X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: Tamir Zegman CC: Rodney Thayer , ipsec@tis.com Subject: Re: Can ID be different than SubjectAltName field of theCertificate References: <4.1.19990111085800.03cb0040@idi-fk-gw.abhiweb.com> <369B09B9.C74DF97F@checkpoint.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Tamir Zegman wrote: > What do we have to gain from having the same content in both ID payload and > subjectAltName? Tamir, If the Policy on my server my server (responder in this case) is key-ed by the other party ID and I allow ID payload and cert mismatch as you suggested - than person A could impersonate his boss by sending boss's ID and person's A valid cert. In this case my policy will select wrong entry in SPD. > Rodney Thayer wrote: > > > Not if you want to use the ID payload to decide what certificate to use, > > so no. > > > > At 07:13 PM 1/5/99 -0500, you wrote: > > >Hi All, > > > > > >When we use Certificates for authentication, can the ID payload be IP address > > >and the > > >subjectAltName field in the certificate be rfc822name? > > > > > >Thanks in advance > > >Sashidhar Annaluru > > >avs@lucent.com > > > > > > > > > From owner-ipsec@portal.ex.tis.com Tue Jan 12 09:48:27 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA18328 for ; Tue, 12 Jan 1999 09:48:27 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA21319 for ipsec-outgoing; Tue, 12 Jan 1999 09:47:30 -0500 (EST) Message-ID: <369B612F.3167EF45@ire-ma.com> Date: Tue, 12 Jan 1999 09:50:23 -0500 From: Bronislav Kavsan X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: "Mason, David" CC: "'ipsec@tis.com'" Subject: Re: Can ID be different than SubjectAltName field of theCertifica te References: <447A3F40A07FD211BA2700A0C99D759B05CEA2@md-exchange1.nai.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk > I would suggest extracting the SubjectAltName from the certificate > and using that to key into your Policy database. Which one? Certificate may have multiple SubjectAltNames (IP Address, FQDN, USER_FQDN). ID payload is useful at least in this case by specifying ID Type to help extracting corresponding SubjectAltName from the certificate. Otherwise - I agree - the rest of the ID payload is useless in the presence of the certificate payload. Slava From owner-ipsec@portal.ex.tis.com Tue Jan 12 09:48:39 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA18336 for ; Tue, 12 Jan 1999 09:48:38 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA21273 for ipsec-outgoing; Tue, 12 Jan 1999 09:39:31 -0500 (EST) Message-ID: <447A3F40A07FD211BA2700A0C99D759B05CEA2@md-exchange1.nai.com> From: "Mason, David" To: "'Bronislav Kavsan'" Cc: "'ipsec@tis.com'" Subject: RE: Can ID be different than SubjectAltName field of theCertifica te Date: Tue, 12 Jan 1999 06:59:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk >If the Policy on my server my server (responder in this case) is key-ed by the >other party ID and I allow ID payload and cert mismatch as you suggested - than >person A could impersonate his boss by sending boss's ID and person's A valid cert. >In this case my policy will select wrong entry in SPD. I would suggest extracting the SubjectAltName from the certificate and using that to key into your Policy database. If certs are being exchanged there's not much need for the ID payload since the cert provides an unforgable identity by definition. Of course if certs aren't being exchanged via IKE then one way to identify which cert to retrieve via alternate means would be by the contents of the ID payload. -dave From owner-ipsec@portal.ex.tis.com Tue Jan 12 11:24:00 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA18882 for ; Tue, 12 Jan 1999 11:23:59 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA21799 for ipsec-outgoing; Tue, 12 Jan 1999 11:24:30 -0500 (EST) Message-ID: <369B77B1.D56ED014@ire-ma.com> Date: Tue, 12 Jan 1999 11:26:26 -0500 From: Bronislav Kavsan X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: Tamir Zegman CC: ipsec@tis.com Subject: Re: Can ID be different than SubjectAltName field of theCertificate References: <4.1.19990111085800.03cb0040@idi-fk-gw.abhiweb.com> <369B09B9.C74DF97F@checkpoint.com> <369B5604.95B3812C@ire-ma.com> <369B79FC.DABA6FBA@checkpoint.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Tamir, I guess it is possible, as long you have appropriate Policy rules for matching information in the Certificate, ID Payload and the SPD, whcich could be quite complex if all of them musmatch. BTW - my name is Slava (not Slave) Tamir Zegman wrote: > Slave, > > We agree that there should be strong bond between the information on the certificate > and the > ID payload, even so, this does not mandate that they be identical. The way in which you > bind the ID payload to the appropriate > SPD entry should be a local policy matter. For example, your local policy could bind > foo.bar.com to a certain ip address or > you could use Secure DNS to do the binding. > > Regards, > Tamir & Moshe. > > Bronislav Kavsan wrote: > > > Tamir Zegman wrote: > > > > > What do we have to gain from having the same content in both ID payload and > > > subjectAltName? > > > > Tamir, > > > > If the Policy on my server my server (responder in this case) is key-ed by the > > other party ID and I allow ID payload and cert mismatch as you suggested - than > > person A could impersonate his boss by sending boss's ID and person's A valid cert. > > In this case my policy will select wrong entry in SPD. > > From owner-ipsec@portal.ex.tis.com Tue Jan 12 11:45:56 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA19088 for ; Tue, 12 Jan 1999 11:45:55 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA21742 for ipsec-outgoing; Tue, 12 Jan 1999 11:16:30 -0500 (EST) Message-ID: <369B79FC.DABA6FBA@checkpoint.com> Date: Tue, 12 Jan 1999 18:36:12 +0200 From: Tamir Zegman Organization: Check Point X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Bronislav Kavsan , ipsec@tis.com Subject: Re: Can ID be different than SubjectAltName field of theCertificate References: <4.1.19990111085800.03cb0040@idi-fk-gw.abhiweb.com> <369B09B9.C74DF97F@checkpoint.com> <369B5604.95B3812C@ire-ma.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Slave, We agree that there should be strong bond between the information on the certificate and the ID payload, even so, this does not mandate that they be identical. The way in which you bind the ID payload to the appropriate SPD entry should be a local policy matter. For example, your local policy could bind foo.bar.com to a certain ip address or you could use Secure DNS to do the binding. Regards, Tamir & Moshe. Bronislav Kavsan wrote: > Tamir Zegman wrote: > > > What do we have to gain from having the same content in both ID payload and > > subjectAltName? > > Tamir, > > If the Policy on my server my server (responder in this case) is key-ed by the > other party ID and I allow ID payload and cert mismatch as you suggested - than > person A could impersonate his boss by sending boss's ID and person's A valid cert. > In this case my policy will select wrong entry in SPD. > From owner-ipsec@portal.ex.tis.com Wed Jan 13 10:36:07 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA22195 for ; Wed, 13 Jan 1999 10:36:03 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA25560 for ipsec-outgoing; Wed, 13 Jan 1999 09:07:36 -0500 (EST) Message-ID: <9DBF3C44F94BD2119C4400105A16BC7F021DBE@MAILMAN> From: "Brothers, John" To: "'ipsec@tis.com'" Subject: Passing IPSec VPN traffic through a Port-masquerading firewall Date: Wed, 13 Jan 1999 09:25:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Howdy, I need to support IPSec VPN users through Linux masquerading firewall. The linux masquerade code converts the "client-side" IP addresses into its address, and manipulates the source port in order to keep track of who is doing what so it can demasquerade on the way back. Now, I understand that there are two parts to the VPN protocol - the initial key exchange at port 500, and then the ESP packets. I know that there are multiple-IP-address NAT devices that work with this method, so I assume that I can change the IP address of the packets without getting into too much trouble. But I have been told that there is no session number that I can draw off of to distinguish two clients creating VPN tunnels to the same destination server. I have looked at the RFC for ESP, and it seems to support this claim. I was wondering if I could potentially use the sequence number as a reasonably unique identifier - Not perfect, but perhaps ok. Does anyone on this list have any other suggestions? Thanks John ------- johnbr@elastic.com - John Brothers - (678) 297 3084 From owner-ipsec@portal.ex.tis.com Wed Jan 13 10:47:32 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA22295 for ; Wed, 13 Jan 1999 10:47:29 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA25909 for ipsec-outgoing; Wed, 13 Jan 1999 10:10:39 -0500 (EST) X-Mailer: exmh version 2.0.2 To: ipsec@tis.com Subject: help Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Jan 1999 15:22:08 +0100 Message-ID: <963.916240928@cs.ucl.ac.uk> From: Theo PAGTZIS Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi All, I am new in the area of IPsec. I am trying to find some starting points for background reading on related activities of IPsec. I have downloaded some rfc 2401-X. However, I am not sure if I am starting from the right place. Could anybody already familar with the realms of IPsec give me some hints? Any help or even bother to read this email is highly appreciated. Many thanks Theo From owner-ipsec@portal.ex.tis.com Wed Jan 13 15:43:31 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA01958 for ; Wed, 13 Jan 1999 15:43:29 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA27100 for ipsec-outgoing; Wed, 13 Jan 1999 15:10:48 -0500 (EST) Message-ID: <9DBF3C44F94BD2119C4400105A16BC7F021DC3@MAILMAN> From: "Brothers, John" To: "'ipsec@tis.com'" Subject: RE: Passing IPSec VPN traffic through a Port-masquerading firewal l Date: Wed, 13 Jan 1999 15:29:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk I've had a couple of good responses, but I think I failed to explain the problem fully. We're operating a 'guest' server - anyone can connect, and access the outside world with their own laptop through the linux masquerade box. We aren't providing the VPN capability, we just want to carry VPN traffic across. In addition, we don't know who these people are, or where they are going. So we can't, unfortunately, create special rules for certain destinations ahead of time - we have to do everything on demand as people attempt to use the system. and in the worst case, it is possible that there could be dozens, if not a hundred people all attempting to connect to the same IPSec VPN server, all essentially using the same source IP address and the same destination IP address. The application for this is Ethernet-speed Internet access in a hotel room - and some hotels have as many as 4000 rooms... > -----Original Message----- > From: Brothers, John [SMTP:johnbr@elastic.com] > Sent: Wednesday, January 13, 1999 9:26 AM > To: 'ipsec@tis.com' > Subject: Passing IPSec VPN traffic through a Port-masquerading > firewall > > Howdy, > > I need to support IPSec VPN users through Linux masquerading firewall. > The linux masquerade code converts the "client-side" IP addresses into its > address, and manipulates the source port in order to > keep track of who is doing what so it can demasquerade on the way back. > > Now, I understand that there are two parts to the VPN protocol - the > initial key exchange at port 500, > and then the ESP packets. I know that there are multiple-IP-address NAT > devices that work with this > method, so I assume that I can change the IP address of the packets > without > getting into too much > trouble. But I have been told that there is no session number that I can > draw off of to distinguish two clients creating VPN tunnels to the same > destination server. > > I have looked at the RFC for ESP, and it seems to support this claim. I > was wondering if I could > potentially use the sequence number as a reasonably unique identifier - > Not > perfect, but perhaps > ok. Does anyone on this list have any other suggestions? > > Thanks > John > > > ------- > johnbr@elastic.com - John Brothers - (678) 297 3084 From owner-ipsec@portal.ex.tis.com Thu Jan 14 02:18:38 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA14211 for ; Thu, 14 Jan 1999 02:18:37 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id BAA28631 for ipsec-outgoing; Thu, 14 Jan 1999 01:55:49 -0500 (EST) Message-ID: From: "Eren, Evren" To: ipsec@tis.com Subject: esp and ah introduction material Date: Thu, 14 Jan 1999 08:16:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, I very recently started to get into IPsec and look for an easy introduction to AH and ESP on the web. Could anybody out there recommend some links ? Thanks in advance Evren From owner-ipsec@portal.ex.tis.com Thu Jan 14 06:42:53 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA20475 for ; Thu, 14 Jan 1999 06:42:53 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id GAA29552 for ipsec-outgoing; Thu, 14 Jan 1999 06:13:49 -0500 (EST) Date: Thu, 14 Jan 1999 13:33:25 +0200 (EET) From: Markku Savela Message-Id: <199901141133.NAA04476@anise.tte.vtt.fi> To: ipsec@tis.com Subject: Getting ISPs to pass IPSEC protocols 51, 50 and 4 Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@ex.tis.com Precedence: bulk This is not really technical IPSEC posting, but I just wish unburden my mind about difficulties in testing IPSEC when ISPs and providers have overjealous filtering on by default. I wanted to test IPSEC connection between two points where the other would be on a dial-up PPP, and observed - our own (VTT.FI) dialup lines didn't pass IPSEC (for a company firewall, probably a good thing by default), Then tried two internet providers in Helsinki area that allow anonymous dialup PPP, such that the phone line is billed by minute for the use. I assumed that this type of connection is ideal for random traveller and IPSEC use. But I found that one of them didn't pass any of the IPSEC protocols ("surf" kolumbus.fi), the "Inet open" dialup lines passed the IPSEC packets and I could complete the tests. A small sample, but I wonder if similar problem is common globally and whether something should be done about it, by increasing the IPSEC awarenes and getting the blocks removed. -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@portal.ex.tis.com Thu Jan 14 13:10:56 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA24127 for ; Thu, 14 Jan 1999 13:10:55 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA01077 for ipsec-outgoing; Thu, 14 Jan 1999 12:08:50 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: In-Reply-To: <369B79FC.DABA6FBA@checkpoint.com> References: <4.1.19990111085800.03cb0040@idi-fk-gw.abhiweb.com> <369B09B9.C74DF97F@checkpoint.com> <369B5604.95B3812C@ire-ma.com> Date: Thu, 14 Jan 1999 10:40:20 -0500 To: Tamir Zegman From: Stephen Kent Subject: Re: Can ID be different than SubjectAltName field of theCertificate Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Tamir, >We agree that there should be strong bond between the information on the >certificate >and the >ID payload, even so, this does not mandate that they be identical. The way >in which you >bind the ID payload to the appropriate >SPD entry should be a local policy matter. For example, your local policy >could bind >foo.bar.com to a certain ip address or >you could use Secure DNS to do the binding. I agree with your observations, but I think it fair to say that the best case arises when the ID in the cert matches the SPD entry. Any other situation creates dependencies on other databases, which creates more opportunities for management-induced vulerabilities, etc. Steve From owner-ipsec@portal.ex.tis.com Thu Jan 14 16:18:55 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA25858 for ; Thu, 14 Jan 1999 16:18:55 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA02094 for ipsec-outgoing; Thu, 14 Jan 1999 16:39:50 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: In-Reply-To: <9DBF3C44F94BD2119C4400105A16BC7F021DBE@MAILMAN> Date: Thu, 14 Jan 1999 14:25:39 -0500 To: "Brothers, John" From: Stephen Kent Subject: Re: Passing IPSec VPN traffic through a Port-masquerading firewall Cc: "'ipsec@tis.com'" Sender: owner-ipsec@ex.tis.com Precedence: bulk John, First, port 500 is associated with IKE, but not AH or ESP. These protocols, used for transit traffic security, have their own protocol IDs (50 and 51), and have no port numbers per se, unlike TCP or UDP. Depending on the security service selected, you might be able to see real port numbers, but since you can't count on that in all cases, it probably is not a useful heuristic. I don't understand your reference to the sequence numbers in packets. Each packet protected with AH or ESP will have an increasing sequence number, but there is no guarantee that all packets will be delivered in order, so you may see gaps. Also, since everyone uses the same sequence number space, what approach do you envision for using these values to demux individual user SAs? Steve From owner-ipsec@portal.ex.tis.com Thu Jan 14 17:56:25 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA26638 for ; Thu, 14 Jan 1999 17:56:25 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA02378 for ipsec-outgoing; Thu, 14 Jan 1999 17:59:48 -0500 (EST) Message-ID: <9DBF3C44F94BD2119C4400105A16BC7F021DDC@MAILMAN> From: "Brothers, John" To: "'Stephen Kent'" , "Brothers, John" Cc: "'ipsec@tis.com'" Subject: RE: Passing IPSec VPN traffic through a Port-masquerading firewal l Date: Thu, 14 Jan 1999 18:18:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk > First, port 500 is associated with IKE, but not AH or ESP. These > protocols, used for transit traffic security, have their own protocol IDs > (50 and 51), and have no port numbers per se, unlike TCP or UDP. > Depending > on the security service selected, you might be able to see real port > numbers, but since you can't count on that in all cases, it probably is > not > a useful heuristic. > [Brothers, John] Right. I should be able to view the SPI, though, correct? > I don't understand your reference to the sequence numbers in packets. > Each > packet protected with AH or ESP will have an increasing sequence number, > but there is no guarantee that all packets will be delivered in order, so > you may see gaps. Also, since everyone uses the same sequence number > space, what approach do you envision for using these values to demux > individual user SAs? [Brothers, John] I was trying to provoke some discussion by throwing out a random idea. Basically, the gist of what I've found is that the sequence number is not a good idea, but the SPI may be. Thanks for your input, John > Steve From owner-ipsec@portal.ex.tis.com Thu Jan 14 21:06:48 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA10245 for ; Thu, 14 Jan 1999 21:06:48 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id VAA02997 for ipsec-outgoing; Thu, 14 Jan 1999 21:30:49 -0500 (EST) Date: Thu, 14 Jan 1999 18:48:48 -0800 (PST) From: Gabriel Montenegro Reply-To: Gabriel Montenegro Subject: RE: Passing IPSec VPN traffic through a Port-masquerading firewal l To: "Brothers, John" Cc: "'Stephen Kent'" , "'ipsec@tis.com'" In-Reply-To: "Your message with ID" <9DBF3C44F94BD2119C4400105A16BC7F021DDC@MAILMAN> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk enabling end-to-end ipsec traffic (among other things) across NAT boxes (also known as ip masquerading) is the subject of http://www.ietf.org/internet-drafts/draft-montenegro-aatn-nar-01.txt In particular, you might be interested in section 2.6.2 (IPSEC Handling and Demultiplexing). I also gave a presentation at the last ipsec meeting on precisely the issue that worries you, and hopefully it helps outlining what needs to be done. my presentation was couched in terms of a framework and does not talk about any specific negotiation or signalling mechanism between the client and the nar box. The presentation is available from: http://playground.sun.com/~gab/talks/ipsec-nat-issues.PDF Three different types of signalling schemes have been proposed so far for similar applications. one is proposed in my draft above, in which i extend socks for the negotiation phase *only*. the other two are UDP based and are proposed in these drafts: Host NAT: http://www.ietf.org/internet-drafts/draft-ietf-nat-hnat-00.txt Distributed NAT: http://search.ietf.org/internet-drafts/draft-borella-aatn-dnat-01.txt this type of end-to-end application across "nat" boxes is being discussed by the nat working group: http://www.ietf.org/html.charters/nat-charter.html hope this helps, -gabriel From owner-ipsec@portal.ex.tis.com Sat Jan 16 09:30:57 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA07170 for ; Sat, 16 Jan 1999 09:30:56 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA00596 for ipsec-outgoing; Sat, 16 Jan 1999 09:16:58 -0500 (EST) X-Lotus-FromDomain: SHIVA CORPORATION From: "Jesse Walker" To: ipsec@tis.com Message-ID: <852566FA.006E9435.00@zule.shiva.com> Date: Fri, 15 Jan 1999 15:50:41 -0500 Subject: ISAKMP Query Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@ex.tis.com Precedence: bulk We have a question regarding Section 3.10, p. 35 of RFC 2408. The text in question reads: o Certificate Authority (variable length) - Contains an encoding of an acceptable certificate authority for the type of certificate requested. As an example, for an X.509 certificate this field would contain the Distinguished Name encoding of the Issuer Name of an X.509 certificate authority acceptable to the sender of this payload. This would be included to assist the responder in determining how much of the certificate chain would need to be sent in response to this request. If there is no specific certificate authority requested, this field SHOULD not be included. What does "contain the Distinguished Name encoding of the Issue Name of an X.509 certificate authority" mean? There is no definition of what the "Distinguished Name encoding" might be in this or any of the other ISAKMP-related RFCs. RFC 2407 does give an encoding for distinguished names, but only in the context of the ID payload. Further, the cisco reference implementation seems to include the entire certificate of the CA, using the encodings defined for a Certificate Request. The discussion at PKI night at the Binghamton Bakeoff also pointed to encoding the entire CA certificate into the payload and not less. But the RFC does not say to use the CA's certificate. What is the correct interpretation of this text? Jesse Walker Consulting Engineer Shiva Corporation 28 Crosby Drive Bedford, AM 01730-1437 voice: 781-687-1719 fax: 781-687-1828 e-mail: jwalker@shiva.com From owner-ipsec@portal.ex.tis.com Mon Jan 18 08:44:42 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA27792 for ; Mon, 18 Jan 1999 08:44:42 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA06317 for ipsec-outgoing; Mon, 18 Jan 1999 08:17:10 -0500 (EST) Message-ID: <91AE69321799D211AEC500105A9C469605D7F1@sothmxs05.entrust.com> From: Greg Carter To: ipsec@tis.com, "'Jesse Walker'" Subject: RE: ISAKMP Query Date: Mon, 18 Jan 1999 08:33:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk It is the binary ASN.1 DER encoding of the DN of the CA. Not the entire certificate. Bye. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com > ---------- > From: Jesse Walker[SMTP:jwalker@shiva.com] > Sent: Friday, January 15, 1999 3:50 PM > To: ipsec@tis.com > Subject: ISAKMP Query > > > There is no definition of what the "Distinguished Name encoding" might be > in this or any of the other ISAKMP-related RFCs. RFC 2407 does give an > encoding for distinguished names, but only in the context of the ID > payload. Further, the cisco reference implementation seems to include the > entire certificate of the CA, using the encodings defined for a > Certificate > Request. The discussion at PKI night at the Binghamton Bakeoff also > pointed > to encoding the entire CA certificate into the payload and not less. But > the RFC does not say to use the CA's certificate. > > What is the correct interpretation of this text? > > From owner-ipsec@portal.ex.tis.com Mon Jan 18 13:13:55 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA00119 for ; Mon, 18 Jan 1999 13:13:55 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA07860 for ipsec-outgoing; Mon, 18 Jan 1999 13:10:01 -0500 (EST) Message-ID: From: Ricky Charlet To: "'ipsec@tis.com'" Subject: Q about SA bundles Date: Mon, 18 Jan 1999 10:27:11 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BE4310.2A317698" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BE4310.2A317698 Content-Type: text/plain; charset="iso-8859-1" Howdy () OK, so everyone knows from ARCH sec 4.1 that: "Security services are afforeded to an SA by the use of AH, or ESP, but not both. IF both AH and ESP prtection is applied to a traffic stream, then two (or more) SAs are created to afford protection to the traffic stream." Why is this? What was the original thinking that went into this "seperation of SAs" requirement. One could envision a standardized architecture which called for bundeling ordered security services under a single SA. Then the SA managemnet construct would have modled very closly the virtual link. That would have been an nice modle for VPN management. So, what were the cons to 'grand unifying' SAs? This is only a point of curiosity for me since the IPSec ARCH is obvoiusly well understood and widely implemented (including at my company). ################################### # Ricky Charlet # rcharlet@RedCreek.com # (510) 795-6903 ################################### end Howdy; ------_=_NextPart_000_01BE4310.2A317698 Content-Type: application/octet-stream; name="Ricky Charlet.vcf" Content-Disposition: attachment; filename="Ricky Charlet.vcf" Content-Location: ATT-0-65F17EDFF0AED211A44800805F650DF2-R ICKYC%7E1.VCF BEGIN:VCARD VERSION:2.1 N:Charlet;Ricky FN:Ricky Charlet ORG:RedCreek Communications Inc.;Engineering TITLE:Engineer ADR;WORK:;2nd Floor;3900 Newpark Mall Rd.;Newark;CA;94560;USA LABEL;WORK;ENCODING=QUOTED-PRINTABLE:2nd Floor=0D=0A3900 Newpark Mall Rd.=0D=0ANewark, CA 94560=0D=0AUSA EMAIL;PREF;INTERNET:rcharlet@redcreek.com REV:19981013T230517Z END:VCARD ------_=_NextPart_000_01BE4310.2A317698-- From owner-ipsec@portal.ex.tis.com Tue Jan 19 03:08:11 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA15537 for ; Tue, 19 Jan 1999 03:08:10 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id CAA00975 for ipsec-outgoing; Tue, 19 Jan 1999 02:49:39 -0500 (EST) Message-ID: <778DFE9B4E3BD111A74E08002BA3DC0D827DFF@TRAB-HERMES> From: =?ISO-8859-1?Q?Eskil_=C5hlin?= To: "'ipsec@tis.com'" Subject: IPsec vs L2TP Date: Tue, 19 Jan 1999 09:08:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk How do IPsec and L2TP relate? L2TP tunnels PPP frames and will use IPsec mechanisms for encryption and authentication, at least according to some internet draft. Why would you want to tunnel the entire PPP frame instead of terminating the PPP connection at the most convenient, closest, access point and only run IPsec packets over untrustworthy networks (i.e. the Internet)? Maybe there are some market driven reasons for not doing so, but I can't see any technical reasons for not replacing L2TP with IPsec. What have I missed? /Eskil From owner-ipsec@portal.ex.tis.com Tue Jan 19 14:11:44 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA21753 for ; Tue, 19 Jan 1999 14:11:43 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA04483 for ipsec-outgoing; Tue, 19 Jan 1999 14:22:43 -0500 (EST) Message-ID: <70C20C1647EBD11183F800805FA67B43011394@vpnet.com> From: Sankar Ramamoorthi To: "'ipsec@tis.com'" Date: Tue, 19 Jan 1999 11:43:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, I ran into an interoperability situation between 2 ipsec implementations when the customer tried to set up 2 networks behind a security gateway as part of the same vpn. network1 ----- | SG1----x x--SG2--- peer network | networks ----- In the first implementation (SG1) The security gateway uses the same ipsec SA to send traffic from both networks since data originating from both the networks are part of the same VPN and hence there is no point creating another SA with the same crypto parameters. The security gateway applies the same logic on inbound traffic also and accepts packets on an ipsec SA as long as the ip addresses match local policy. In the second implementation (SG2) The implemenation is more stringent and tries to constrict the packets accepted on an SA to exactly match the addresses negotiated for that SA. The drawback of this approach seems to that when one want to protect more than one network as part of the same VPN (policy) you have to create 1 SA per network. The same problem exists when you want hosts from more than one network to be part of the same VPN (policy). You incur the cost of creating multiple SAs. Both SG1 and SG2 agree on local policy. However SG1 creates only one SA where as SG2 expects multiple SAs to be created. SG2 requires ip addresses of decrypted packets on SA to match the negotiated addresses. This forces SG1 to create multiple SAs. SG1 also verifies the addresses of decrypted packets but they are accepted as long as the match the local policy. Should the address checking be local policy based or based on negotiated addresses? The additional SAs share the same crypto parameters and hence seem reduntant. I reviewed the archives. There were previous discussions on this topic but never any definite conclusion. The RFCs does not take a position one way or other. I am willing to go either way but would like to know the most interoperable approach. My preferance is to avoid creating multiple SAs in this scenario unless there is a defnite security advantage/reason for constricting ipsec SAs created for the same VPN (policy). Thanks for any comments. -- sankar (sankar@vpnet.com) -- From owner-ipsec@portal.ex.tis.com Tue Jan 19 14:11:46 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA21760 for ; Tue, 19 Jan 1999 14:11:45 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA04378 for ipsec-outgoing; Tue, 19 Jan 1999 13:58:45 -0500 (EST) Message-ID: <36A4DA70.4DF0F4BE@Certicom.com> Date: Tue, 19 Jan 1999 14:18:08 -0500 From: Yuri Poeluev Organization: Certicom Corp. X-Mailer: Mozilla 4.01 [en] (WinNT; U) MIME-Version: 1.0 To: ipsec@tis.com Subject: Elliptic curves in IPSec [revisited] X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, A few people have asked us to reiterate our concerns over the default elliptic curves defined in IPSec. Our concerns are basically about the security of the curves. So I asked Simon Blake-Wilson for technical comments from our researchers on the security aspect. Unfortunately not many of the references are available in soft copy but I did hand out hard copies to interested parties at the Chicago IETF meeting. We are also concerned that the default curves are not aligned with all the other standards efforts in elliptic curve cryptography. The point representation and point order used is not compliant with ANSI X9.62 and X9.63, IEEE P1363, ISO 15849, WAP and the like. It's a serious mistake to ignore the work of these other standards to align all elliptic curve implementations. Our primary fear is that the implementation of non-standard techniques like those in IPSec will hinder the deployment of elliptic curve cryptography - much as the variety of different techniques used in RSA standards like ISO 9796, PKCS 1, ANSI X9.31, etc seems to have caused RSA problems. The non-standard techniques used in IPSec also mean that the default curves cannot be used by ECDSA if it is later integrated into IPSec. We have an implementation of IPSec with some alternative curves and plan to propose them shortly. Best regards, Yuri Poeluev ------------------------------------------------------------------------------------------------------- Default IPSec elliptic curves IPSec defines two default elliptic curves. One over F2^155, and one over F2^185. We are worried because these curves are defined over F2^m with m composite. The security of curves over F2^m with m composite has been questioned by many leading researchers. Our concerns have recently been echoed by the US government: Miles Smid of NIST announced at the ANSI X9F1 meeting in Ottawa in October that these curves will not be supported in the upcoming FIPS elliptic curve standards because of security concerns. Concerns about the security of the curves stem from the same property which is exploited in implementations: the existence of non-trivial subfields of F2^m when m is composite. It is often claimed that these subfields do not endow elliptic curves with any additional structure that could be exploited, but this is untrue: for example the subfields endow the Weil descent of the curve with rich additional structure. In layman's terms the Weil descent looks at algebraic structures related to the elliptic curve by considering F2^m with m=nn' as a vector space of dimension n' over F2^n. From this angle the elliptic curve corresponds to an algebraic curve of dimension (at most) n' over F2^n. For example if the algebraic curve happens to be a hyperelliptic curve then the elliptic curve can now be broken using the Adleman-Huang algorithm. Leading experts who have expressed concern about these curves include Gerhard Frey [2], Alfred Menezes, and Scott Vanstone [6]. We take their fears particularly seriously since they have already broken other special cases of the elliptic curve logarithm problem...see [3] and [5]. Other experts who have publicly raised their concerns about these curves include Erik De Win, Serge Mister, Bart Preneel, and Mike Wiener [1], Volker Mueller and Sachar Paulus [7], and Claus Schnorr [8]. (The only concrete results on these curves so far are minor improvements due to Rob Gallant, Rob Lambert, and Scott Vanstone [4] and Mike Wiener and Robert Zuccherato [9]. These results apply to elliptic curves over F2^nn' which are defined over F2^n.) 1. E. De Win, S. Mister, B. Preneel, and M. Wiener. On the performance of signature schemes based on elliptic curves. Proceedings of ANTS '98. Springer-Verlag. 2. G. Frey. Invited presentation at Eurocrypt '97. (Copies of his slides were available at the conference.) 3. G. Frey and H.-G. Ruck. A remark concerning m-divisibility and the discrete logarithm problem in the divisor class group of curves. Mathematics of Computation, number 62, volume 206, pages 865-874. 1994. 4. R. Gallant, R. Lambert, and S. Vanstone. Improving the parallelized Pollard lambda search on binary anomalous curves. To appear in Mathematics of Computation. Earlier version available from: http://cacr.math.uwaterloo.ca/ 5. A. Menezes, T. Okamoto, and S. Vanstone. Reducing elliptic curve logarithms to logarithms in a finite field. IEEE Transactions on Information Theory, number 39, pages 1639-1646, 1993. 6. A. Menezes and S. Vanstone. Comments at the IEEE P1363 meeting after Crypto '98. 7. V. Mueller and S. Paulus. On the generation of cryptographically strong elliptic curves. Available from: http://www.informatik.th-darmstadt.de/TI/Mitarbeiter/vmueller.html 8. C. Schnorr. Rump session talk on breaking the Chor-Rivest knapsack system. Crypto '97. 9. M. Wiener and R. Zuccherato. Fast attacks on elliptic curve cryptosystems. Proceedings of SAC '98. Springer-Verlag. From owner-ipsec@portal.ex.tis.com Tue Jan 19 15:03:33 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA22177 for ; Tue, 19 Jan 1999 15:03:33 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA04736 for ipsec-outgoing; Tue, 19 Jan 1999 15:11:44 -0500 (EST) Message-Id: <3.0.5.32.19990119223234.009876c0@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 19 Jan 1999 22:32:34 +0200 To: ipsec@tis.com From: Joern Sierwald Subject: Re: No Subject In-Reply-To: <70C20C1647EBD11183F800805FA67B43011394@vpnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id PAA04733 Sender: owner-ipsec@ex.tis.com Precedence: bulk At 11:43 19/01/99 -0800, you wrote: > >Hi, > >I ran into an interoperability situation between 2 ipsec implementations >when the >customer tried to set up 2 networks behind a security gateway as part of the >same vpn. > >network1 ----- > | > SG1----x x--SG2--- peer network > | >networks ----- > In a QM negotiation, you use IDs to specify the networks that are supposed to talk to each other. That could be 192.168.1.0/24 (behind SG1) and 192.168.2.0/24 (behind SG2). I would be very surprised if the resulting SA was used for something else than traffic between these networks. If SG1 really sends data from 192.168.3.0/24 through that SA, I'd say that this implementation is faulty. You need several SAs here. And if each SG has 10 subnets, there will be 100 SAs. A possible workaround would be to do QM with 0.0.0.0/0 IDs and some policy-based filtering. If you want the most interoperable approach: When sending packets, mind the QM IDs used to create the SA. When receiving packets, you could invent a policy setting to allow traffic that does not match the IDs. You could. I don't say that you should. Jörn From owner-ipsec@portal.ex.tis.com Tue Jan 19 15:43:01 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA22529 for ; Tue, 19 Jan 1999 15:43:00 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA04941 for ipsec-outgoing; Tue, 19 Jan 1999 15:48:44 -0500 (EST) Message-ID: <010501be43ef$ecfde6e0$1eacddcf@osiris.tril-inc.com> From: "PJ Kirner" To: Subject: Where are IPSec Conformance Test Sites Date: Tue, 19 Jan 1999 16:08:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@ex.tis.com Precedence: bulk Can anyone help by pointing me to IPSec conformance test sites. I am looking for sites which can be manually keyed so I can Authentication and Encapsulation side of IPSec (non-IKE). I found : http://www.antd.nist.gov/antd/html/wit.html Are there any others out there? PJ Kirner Trilogy, Inc. From owner-ipsec@portal.ex.tis.com Tue Jan 19 16:27:17 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA22870 for ; Tue, 19 Jan 1999 16:27:16 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA05232 for ipsec-outgoing; Tue, 19 Jan 1999 16:42:42 -0500 (EST) Message-ID: <36A50142.62BC6FA3@internetdevices.com> Date: Tue, 19 Jan 1999 14:03:46 -0800 From: "Sumit A. Vakil" X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@tis.com Subject: Re: References: <70C20C1647EBD11183F800805FA67B43011394@vpnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Sankar, In your example, both sides have a common security policy, but when a SA is negotiated, it is done for a single pair of networks (say, network 1 and 'peer network'). So, the IPSec SA is infact, enforcing a restrictive policy than what you have configured. Going by the 'be conservative in what you accept' approach, you would want to verify that the packets received over a SA are infact packets from the networks for which the SA was negotiated. As far as the Security Arch. RFC goes, an implementation is supposed to verify that a packet received over a SA is actually allowed to use that SA. Considering all of the above, I'd say that SG2's behavior is correct. Short of using vendor payloads, I can't think of a way to negotiate multiple, disjoint networks using IKE. You'd probably be safe negotiating one SA per network pair that you want to protect. Yes, it creates an explosion of SAs should your VPN consist of many networks at the two ends. However, if you are using manual SAs, I don't see why you couldn't have one SA for your entire VPN. If I remember right, the last time this discussion came up, it was decided that this was an IPSecond issue. Sumit A. Vakil Internet Devices, Inc. Sankar Ramamoorthi wrote: > > Hi, > > I ran into an interoperability situation between 2 ipsec implementations > when the > customer tried to set up 2 networks behind a security gateway as part of the > same vpn. > > network1 ----- > | > SG1----x x--SG2--- peer network > | > networks ----- > > In the first implementation (SG1) > The security gateway uses the same ipsec SA to send traffic from both > networks > since data originating from both the networks are part of the same VPN > and hence > there is no point creating another SA with the same crypto parameters. > The security > gateway applies the same logic on inbound traffic also and accepts > packets on an > ipsec SA as long as the ip addresses match local policy. > > In the second implementation (SG2) > The implemenation is more stringent and tries to constrict the packets > accepted on an SA to exactly match the addresses negotiated for that SA. > The drawback of this > approach seems to that when one want to protect more than one network as > part of the > same VPN (policy) you have to create 1 SA per network. The same problem > exists > when you want hosts from more than one network to be part of the same > VPN (policy). > You incur the cost of creating multiple SAs. > > Both SG1 and SG2 agree on local policy. However SG1 creates only one SA > where as > SG2 expects multiple SAs to be created. SG2 requires ip addresses of > decrypted packets > on SA to match the negotiated addresses. This forces SG1 to create > multiple SAs. SG1 also > verifies the addresses of decrypted packets but they are accepted as > long as the match > the local policy. > > Should the address checking be local policy based or based on negotiated > addresses? > The additional SAs share the same crypto parameters and hence seem > reduntant. > > I reviewed the archives. There were previous discussions on this topic > but never any > definite conclusion. The RFCs does not take a position one way or other. > > I am willing to go either way but would like to know the most > interoperable approach. > My preferance is to avoid creating multiple SAs in this scenario unless > there is a defnite > security advantage/reason for constricting ipsec SAs created for the > same VPN (policy). > > Thanks for any comments. > > -- sankar (sankar@vpnet.com) -- From owner-ipsec@portal.ex.tis.com Tue Jan 19 17:34:21 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA23894 for ; Tue, 19 Jan 1999 17:34:20 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA05216 for ipsec-outgoing; Tue, 19 Jan 1999 16:39:43 -0500 (EST) Message-ID: <36A50073.9BBD96D1@sympatico.ca> Date: Tue, 19 Jan 1999 17:00:19 -0500 From: Sandy Harris Organization: Crash Test Dummies on the Information Highway X-Mailer: Mozilla 4.5 [en]C-SYMPA (Win95; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: ipsec@tis.com Subject: Re: Where are IPSec Conformance Test Sites References: <010501be43ef$ecfde6e0$1eacddcf@osiris.tril-inc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk PJ Kirner wrote: > > Can anyone help by pointing me to IPSec conformance > test sites. . . . > > I found : http://www.antd.nist.gov/antd/html/wit.html > > Are there any others out there? I'm not sure either tests what you need but try: http://www.rsa.com/rsa/SWAN/swan_test.htm http://freecerts.entrust.com/vpncerts/index.htm -- "The real aim of current [cryptography] policy is to ensure the continued effectiveness of US information warfare assets against individuals, businesses and governments in Europe and elsewhere" Ross Anderson, Cambridge University From owner-ipsec@portal.ex.tis.com Tue Jan 19 17:35:38 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA23910 for ; Tue, 19 Jan 1999 17:35:38 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA05248 for ipsec-outgoing; Tue, 19 Jan 1999 16:50:43 -0500 (EST) Message-ID: <91AE69321799D211AEC500105A9C469605D803@sothmxs05.entrust.com> From: Greg Carter To: ipsec@tis.com Subject: Developer PKI Available for Testing Date: Tue, 19 Jan 1999 17:08:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Gabba Gabba Hey! http://developer.entrust.com You can get a developer addition of our PKI at the above url, including LDAP server so you can test retrieval of CRLs. If you look hard enough you can even get an IKE toolkit which includes support for both signature modes. Bye. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com From owner-ipsec@portal.ex.tis.com Wed Jan 20 04:55:31 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA23385 for ; Wed, 20 Jan 1999 04:55:30 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id EAA07772 for ipsec-outgoing; Wed, 20 Jan 1999 04:42:48 -0500 (EST) Date: Wed, 20 Jan 1999 12:02:26 +0200 (EET) From: Markku Savela Message-Id: <199901201002.MAA09907@anise.tte.vtt.fi> To: ipsec@tis.com In-reply-to: (message from Ricky Charlet on Mon, 18 Jan 1999 10:27:11 -0800) Subject: Re: Q about SA bundles Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@ex.tis.com Precedence: bulk > OK, so everyone knows from ARCH sec 4.1 that: > "Security services are afforeded to an SA by the use of AH, or ESP, but > not both. IF both AH and ESP prtection is applied to a traffic stream, then > two (or more) SAs are created to afford protection to the traffic stream." > > Why is this? What was the original thinking that went into this > "seperation of SAs" requirement. One could envision a standardized > architecture which called for bundeling ordered security services under a > single SA. Then the SA managemnet construct would have modled very closly > the virtual link. That would have been an nice modle for VPN management. I'm not quite sure what you ask, as there are two separate issues here 1) AH and ESP? Do we really need both or would just one IPSEC protocol have served better? 2) "the SA bundle issue" For the first (1) issue I don't have much opininions. It might have been possible to do with a single, but somewhat more complex IP protocol instead of AH and ESP. But, I don't see much problems with the current ones either. The second appears to relate to issue about which I have written here before, and people seem to have very differing views (something like Complex vs. Reduced Instruction Set issue). I prefer the "RISC" approach in IPSEC and bundles: standard defines the basic "RISC" operations and implementations can build more "complex and optimized programs" from using these "instructions". In my RISC view each unidirectional/monopole SA is totally independent of every other SA. The basic IPSEC Key management transaction with PFKEY v2 between H1 and H2 starts when H1 needs to send a packet to H2: H1 H2 ------------------------ ---------------------- (0) IP:H1->H2 ->SA0 -> SA1 ==================> SA1 \ ^ ^ \ | | \ | | (1) ACQUIRE SA: H1->H2 | <-- Key Mgmnt --> | \ | ------------------------------> (2) GETSPI: dst=H2 | UPDATE SA: dst=H2 | / / (3) ADD SA: dst=H2 <-------------------- 0) The security policy catches the packet H1->H2, no SA exists, so it generates the ACQUIRE REQUEST for the key management. - the only information about the security policy that applies to the packet and connection, is present in the PFKEY ACQUIRE MESSAGE. 1) The key management contacts the other end (H2) and passess the proposals from the ACQUIRE message to the other end. - note specially that there is *no* information about the possible SA going from H2 -> H1! Any key management that negotiates both SA's at same time, is making some out of band assumptions about the policies (for example, assuming they are symmetric). 2) Having chosen one combination of the proposed parameters, the H2 Key Management allocates an SPI (GETSPI) and then completes the SA with all necessary parameters using UPDATE. 3) The agreed on combination and chosen SPI is comminucated back to H1 and it can complete the negotiation by adding the other end of the SA to the IPSEC kernel (this could be seen as a reply, in PFKEY sense, to the original ACQUIRE request--use PID=0 and SEQ from ACQUIRE). This is from single AH or ESP in a bundle specified by the policy. If the bundle has more elements, each of them repeats the above independently (with tunnels present, some of them can involve other end points than H2). The association from H2 -> H1 is negotiated and created, if it is ever needed, when H2 tries to send a packet to H1. Above is repeated, except that H2 is the initiator. All I am asking/hoping that, the all key managements provide this basic primitive: negotiating a monopole SA. Then, there will be no limitations for the policy writer. He can specify any combination of tunnels and ESP/AH in a bundle. This doesn't prevent the keymanagement imlplementations from trying to "second guess" the other necessary SA's using some out of band information. In such case, it can "pre-load" more SA's than the originaly requested monopole. >From the discussions, it seems that the ISAKMP implementations are monolithic and don't allow "RISC approach". The monolithic approach is the root of all these questions and interoperability problems relating to the ordering of transforms etc.. -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@portal.ex.tis.com Wed Jan 20 09:50:46 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA25761 for ; Wed, 20 Jan 1999 09:50:46 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA09167 for ipsec-outgoing; Wed, 20 Jan 1999 09:55:48 -0500 (EST) Message-ID: <447A3F40A07FD211BA2700A0C99D759B0C4A48@md-exchange1.nai.com> From: "Fesman, Dina" To: "'ipsec@tis.com'" Subject: Certificate Usage Validation Date: Tue, 19 Jan 1999 14:23:25 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Does anyone know what extension is "Certificate Usage Validate" as defined in the ICSA requirements 1.0.97 for phase I. Thanks, Dina Fesman dfesman@nai.com From owner-ipsec@portal.ex.tis.com Wed Jan 20 09:56:53 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA25811 for ; Wed, 20 Jan 1999 09:56:52 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA09236 for ipsec-outgoing; Wed, 20 Jan 1999 09:59:45 -0500 (EST) Date: Tue, 19 Jan 1999 18:43:08 -0600 (CST) From: Tina Bird To: Sandy Harris cc: ipsec@tis.com Subject: Re: Where are IPSec Conformance Test Sites In-Reply-To: <36A50073.9BBD96D1@sympatico.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk You might also try http://www.anxo.com the Web site of the Automotive Network eXchange, which financed a lot of interoperability tests. On Tue, 19 Jan 1999, Sandy Harris wrote: > Date: Tue, 19 Jan 1999 17:00:19 -0500 > From: Sandy Harris > To: ipsec@tis.com > Subject: Re: Where are IPSec Conformance Test Sites > > PJ Kirner wrote: > > > > Can anyone help by pointing me to IPSec conformance > > test sites. . . . > > > > I found : http://www.antd.nist.gov/antd/html/wit.html > > > > Are there any others out there? > > I'm not sure either tests what you need but try: > > http://www.rsa.com/rsa/SWAN/swan_test.htm > http://freecerts.entrust.com/vpncerts/index.htm > > -- > "The real aim of current [cryptography] policy is to ensure the > continued effectiveness of US information warfare assets against > individuals, businesses and governments in Europe and elsewhere" > Ross Anderson, Cambridge University > From owner-ipsec@portal.ex.tis.com Wed Jan 20 10:08:09 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA25885 for ; Wed, 20 Jan 1999 10:08:09 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA10644 for ipsec-outgoing; Wed, 20 Jan 1999 10:22:10 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: Date: Tue, 19 Jan 1999 12:08:18 -0500 To: Ricky Charlet From: Stephen Kent Subject: Re: Q about SA bundles Cc: "'ipsec@tis.com'" Sender: owner-ipsec@ex.tis.com Precedence: bulk Ricky, That's a fair question. Originally, one could have an SA that embraced both AH and ESP, but they became separated some time ago, as part of the refinement of the IPsec architecture, and the fleshing out of the ESP definition. Also, the definition of an SA changed to call for inclusion of the IPsec protocol as part of the triple (dest addr, protocol, and SPI). I think a (the?) major motivation for this separation is the desire to be able to share SAs among multiple traffic flows, which argues for more the discrete definition of SAs that we now have. Steve From owner-ipsec@portal.ex.tis.com Thu Jan 21 08:15:59 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA01229 for ; Thu, 21 Jan 1999 08:15:59 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id HAA16099 for ipsec-outgoing; Thu, 21 Jan 1999 07:36:15 -0500 (EST) Date: Thu, 21 Jan 1999 14:55:57 +0200 (EET) From: Markku Savela Message-Id: <199901211255.OAA11876@anise.tte.vtt.fi> To: ipsec@tis.com In-reply-to: <199901202255.OAA23137@locked.eng.sun.com> (message from Mohan Parthasarathy on Wed, 20 Jan 1999 14:55:39 -0800 (PST)) Subject: Re: Q about SA bundles Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Mohan Parthasarathy > Last time this was discussed, somebody replied > "While you are negotiating AH IPSEC SA, and the other end's policy > requirement is ESP + AH, how does the other end know you will > negotiate ESP after negotiating AH i.e should the other side > accept the negotiation assuming you will negotiate ESP in > a short while or reject assuming that you are not negotiating > ESP " ? A short answer: While negotiating AH IPSEC SA, the responder site doesn't need to know or care whether it is associated with a AH+ESP bundle or not. Longer answer: H1 H2 ------------------------ ------------------ (0) IP:H1->H2 ->SA0 -> SA1 ==================> SA1 \ ^ ^ \ | | \ | | (1) ACQUIRE SA: H1->H2 | <-- Key Mgmnt --> | \ | ------------------------------> (2) GETSPI: dst=H2 | UPDATE SA: dst=H2 | / / (3) ADD SA: dst=H2 <-------------------- The initiator (H1) only has the PFKEY ACQUIRE information to go with, and it simply includes a list of algorithms from which to choose (the other information is address and identity) Thus assume, a policy saying dst=H2 => AH(md5, sha1, foo), ESP(3des, idea, blowfish, md5) then, the ACQUIRE for AH contains combinations 1) md5 2) sha1 3) foo all of these supported by the initiator side. This list is passed to the responder (H2). The responder host only supports md5 and sha1 (known to the key management from the reply of the PFKEY REGISTER message). My claim and goal is: The responder side of the negotiation does not need to care about the policy. It only selects the SPI and chooses the algorithm from the proposed list (md5, sha1, foo), and as it only knows the first two, it can pick either one, say sha1. It creates the end point SA and reports back to the initiator the SA attributes, so that it can create the starting point of the SA. The ESP is handled exactly the same way, independently. and ending with, for example, (3des,md5) for ESP. With SAs set SA1 (AH: sha1) --------------------> SA1 (AH: sha1) SA2 (ESP: 3des,md5) ----------------> SA2 (ESP: 3des,md5) H1 is finally able to send a packet to the H2. H2 receives the packet and successfully applies SA1 and SA2 to this. And, only *after* this it needs to be checked whether the policy is matched. For example src=H1 => AH(md5, sha1, foo), ESP(3des, idea, blowfish, md5) Looking for a matching SA for AH(md5, sha1, foo) and packet, it should return SA1, and for ESP(3des, idea, blowfish, md5) it should return SA2. If this happens, the policy condition is filled and packet passes, and otherwise not. [I admit that the above matching part is somewhat untraversed territory for me, as my policy defition doesn't (yet) have alternatives for the algorithm, policy just says use one or don't communicate. With multiple choices of algorithms, the search may(?) result with one SA per algorithm, and my guess is that if the applied SA is included in such result, the policy passes.] My key premise here is still: policies on both ends must be same. Note also, that I have included 'foo' in the policy of H2, even though it does not support it. The idea is that, if the support for 'foo' is added to the kernel IPSEC, then it becomes automatically available for the negotiations. This allows gradual deployment of new algorithms. ******************************** SOME OTHER COMMENTS: - assuming policy with bundle ESP+AH, there is nothing in PFKEY ACQUIRE (unless I missed something), that would tell the key management that these two ACQUIREs are actually from the same bundle. [And I think this is a good thing ] - with all this, I am only trying cut down the implementation work into manageable pieces, most important being the ability to describe the pieces of IPSEC in exact manner. These descriptions can be used to decide which implementation is correct, when problems surface. - there are many fuzzy areas, for example, how do ACQUIRE information and the resulting SA information relate to each other, specifically things like SRC_ADDRESS, PROXY_ADDRESS, IDENTITY etc. How much freedom the keymanagement really has? For example, my current implementation if ACQUIRE has exlicit SRC_ADDRESS, and the resulting ADD SA does not include the same source address extension, then my SA locating does not find the SA. And vice versa, if ACQUIRE does not have the SRC address, it should not be present in the SA either (IADDR_ANY). [The presence of SRC and other things in ACQUIRE is mostly controlled by the policy definition, which is very delicately involved in the SA locating, as can be deduced from my descriptions... ] -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@portal.ex.tis.com Thu Jan 21 08:17:35 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA01244 for ; Thu, 21 Jan 1999 08:17:35 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id HAA16086 for ipsec-outgoing; Thu, 21 Jan 1999 07:34:14 -0500 (EST) X-Mailer: exmh version 2.0.2 To: ipsec@tis.com Subject: IPsec implementations sought Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Jan 1999 12:53:16 +0100 Message-ID: <835.916923196@cs.ucl.ac.uk> From: Theo PAGTZIS Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, I am looking to find some IPSec implementations available for research. Could anyone point me to such locations? Platforms used: FreeBSD, Linux, Solaris (IP either v4 or v6) Theo From owner-ipsec@portal.ex.tis.com Thu Jan 21 09:51:07 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA02190 for ; Thu, 21 Jan 1999 09:51:06 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA16584 for ipsec-outgoing; Thu, 21 Jan 1999 09:17:13 -0500 (EST) Date: Wed, 20 Jan 1999 14:55:39 -0800 (PST) From: Mohan Parthasarathy Message-Id: <199901202255.OAA23137@locked.eng.sun.com> To: msa@hemuli.tte.vtt.fi Subject: Re: Q about SA bundles Cc: ipsec@tis.com X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > > All I am asking/hoping that, the all key managements provide this > basic primitive: negotiating a monopole SA. Then, there will be no > limitations for the policy writer. > Last time this was discussed, somebody replied "While you are negotiating AH IPSEC SA, and the other end's policy requirement is ESP + AH, how does the other end know you will negotiate ESP after negotiating AH i.e should the other side accept the negotiation assuming you will negotiate ESP in a short while or reject assuming that you are not negotiating ESP " ? -mohan From owner-ipsec@portal.ex.tis.com Thu Jan 21 15:25:27 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA11793 for ; Thu, 21 Jan 1999 15:25:27 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA18880 for ipsec-outgoing; Thu, 21 Jan 1999 14:10:27 -0500 (EST) Message-Id: <4.1.19990121111104.03cf30d0@idi-fk-gw.abhiweb.com> X-Sender: rodney@idi-fk-gw.abhiweb.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 21 Jan 1999 11:21:23 -0800 To: ipsec@tis.com From: Rodney Thayer Subject: update -- next testing event Cc: rodney@tillerman.nu, rodney@internetdevices.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk This is a PRELIMINARY note about the efforts to do another Testing Event. There is a plan to have a bake-off on the west coast of the US in April. Plans are _NOT_ firm. There will be on soon. If you want more information you can contact me. I am volunteering to be a temporary contact for this, as the organzation around the bake-off gels, someone will make a more formal announcement. Rodney Thayer Principal Architect Internet Devices, Inc. +1 408 541 1400 x333 From owner-ipsec@portal.ex.tis.com Thu Jan 21 18:25:06 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA13427 for ; Thu, 21 Jan 1999 18:25:06 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA19972 for ipsec-outgoing; Thu, 21 Jan 1999 17:50:29 -0500 (EST) Message-Id: <199901212310.PAA00322@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: dharkins owned process doing -bs X-Authentication-Warning: dharkins-ss20.cisco.com: dharkins@localhost didn't use HELO protocol To: msa@hemuli.tte.vtt.fi (Markku Savela) cc: ipsec@tis.com Subject: Re: Q about SA bundles In-reply-to: Your message of "Thu, 21 Jan 1999 14:55:57 +0200." <199901211255.OAA11876@anise.tte.vtt.fi> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <320.916960243.1@cisco.com> Date: Thu, 21 Jan 1999 15:10:43 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk There is a great leap of faith in this statement: "H2 receives the packet and successfully applies SA1 and SA2 to this." If both sides have identical configs your scheme could work but that seems somewhat limited to me. What about permiscuous policy or opportunistic encryptors? They might not know that SA1 _AND_ SA2 have to be applied because they were not told so. Also, H2 doesn't know that H1 will end up making that 2nd offer. H2 could end up receiving packets protected by SA1 that he'll just end up dropping because they weren't also protected with SA2. In fact, I'd wager that you'd probably fully process the packet before deciding to drop it. That would almost be the moral equivalent of a DOS attack and it would be a bitch to debug to boot. If you don't think compound policy statements like "AH AND ESP" or "ESP AND PCP" are particularly useful then you can just ignore the whole SA bundle issue. It will be impossible to configure such policy in your implementation so you'll never have to worry about offering it and you can just hope the the other box won't offer it to you. But if you do think they're useful then such a policy statement is valid. So we have a valid policy which can be properly expressed by KM in a straightforward, interoperable way that precludes the problems described above but because a PF_KEY ACQUIRE message is unable to express conjunctions you're hoping that the problem can just go away if everyone agrees to constrain their implementations in a similar manner. The responder _does_ need to know whether the offer is part of a bundle. That was the whole reason that confusing parsing and payload numbering text was added to RFC2408. It seems that PF_KEY has put you in a box that you're (intentionally?) not looking out of. Imagine an ACQUIRE-like message (with the corresponding ADD/UPDATE-like message) that could express compound, conjunctive offers.... Dan. On Thu, 21 Jan 1999 14:55:57 +0200 you wrote > > > From: Mohan Parthasarathy > > Last time this was discussed, somebody replied > > "While you are negotiating AH IPSEC SA, and the other end's policy > > requirement is ESP + AH, how does the other end know you will > > negotiate ESP after negotiating AH i.e should the other side > > accept the negotiation assuming you will negotiate ESP in > > a short while or reject assuming that you are not negotiating > > ESP " ? > > A short answer: > > While negotiating AH IPSEC SA, the responder site doesn't need > to know or care whether it is associated with a AH+ESP bundle > or not. > > Longer answer: > > H1 H2 > ------------------------ ------------------ > (0) IP:H1->H2 ->SA0 -> SA1 ==================> SA1 > \ ^ ^ > \ | | > \ | | > (1) ACQUIRE SA: H1->H2 | <-- Key Mgmnt --> | > \ | > ------------------------------> (2) GETSPI: dst=H2 > | UPDATE SA: dst=H2 > | / > / > (3) ADD SA: dst=H2 <-------------------- > > > The initiator (H1) only has the PFKEY ACQUIRE information to go with, > and it simply includes a list of algorithms from which to choose (the > other information is address and identity) > > Thus assume, a policy saying > > dst=H2 => AH(md5, sha1, foo), ESP(3des, idea, blowfish, md5) > > then, the ACQUIRE for AH contains combinations > 1) md5 > 2) sha1 > 3) foo > all of these supported by the initiator side. This list is passed to > the responder (H2). > > The responder host only supports md5 and sha1 (known to the key > management from the reply of the PFKEY REGISTER message). > > My claim and goal is: The responder side of the negotiation > does not need to care about the policy. > > It only selects the SPI and chooses the algorithm from the proposed > list (md5, sha1, foo), and as it only knows the first two, it can pick > either one, say sha1. It creates the end point SA and reports back to > the initiator the SA attributes, so that it can create the starting > point of the SA. > > The ESP is handled exactly the same way, independently. and ending > with, for example, (3des,md5) for ESP. With SAs set > > SA1 (AH: sha1) --------------------> SA1 (AH: sha1) > SA2 (ESP: 3des,md5) ----------------> SA2 (ESP: 3des,md5) > > H1 is finally able to send a packet to the H2. H2 receives the packet > and successfully applies SA1 and SA2 to this. And, only *after* this > it needs to be checked whether the policy is matched. For example > > src=H1 => AH(md5, sha1, foo), ESP(3des, idea, blowfish, md5) > > Looking for a matching SA for AH(md5, sha1, foo) and packet, it should > return SA1, and for ESP(3des, idea, blowfish, md5) it should return > SA2. If this happens, the policy condition is filled and packet > passes, and otherwise not. > > [I admit that the above matching part is somewhat untraversed > territory for me, as my policy defition doesn't (yet) have > alternatives for the algorithm, policy just says use one or > don't communicate. With multiple choices of algorithms, the > search may(?) result with one SA per algorithm, and my guess > is that if the applied SA is included in such result, the > policy passes.] > > My key premise here is still: policies on both ends must be same. > > Note also, that I have included 'foo' in the policy of H2, even though > it does not support it. The idea is that, if the support for 'foo' is > added to the kernel IPSEC, then it becomes automatically available for > the negotiations. This allows gradual deployment of new algorithms. > > ******************************** > > SOME OTHER COMMENTS: > > - assuming policy with bundle ESP+AH, there is nothing in PFKEY > ACQUIRE (unless I missed something), that would tell the key > management that these two ACQUIREs are actually from the same > bundle. [And I think this is a good thing ] > > - with all this, I am only trying cut down the implementation work > into manageable pieces, most important being the ability to > describe the pieces of IPSEC in exact manner. These descriptions > can be used to decide which implementation is correct, when > problems surface. > > - there are many fuzzy areas, for example, how do ACQUIRE information > and the resulting SA information relate to each other, specifically > things like SRC_ADDRESS, PROXY_ADDRESS, IDENTITY etc. How much > freedom the keymanagement really has? For example, my current > implementation > > if ACQUIRE has exlicit SRC_ADDRESS, and the resulting ADD SA > does not include the same source address extension, then my > SA locating does not find the SA. And vice versa, if ACQUIRE > does not have the SRC address, it should not be present in > the SA either (IADDR_ANY). [The presence of SRC and other > things in ACQUIRE is mostly controlled by the policy > definition, which is very delicately involved in the SA > locating, as can be deduced from my descriptions... ] > > -- > Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland > Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/ms >a/ From owner-ipsec@portal.ex.tis.com Fri Jan 22 04:11:53 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA14791 for ; Fri, 22 Jan 1999 04:11:53 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id EAA21558 for ipsec-outgoing; Fri, 22 Jan 1999 04:12:37 -0500 (EST) Date: Fri, 22 Jan 1999 11:32:23 +0200 (EET) From: Markku Savela Message-Id: <199901220932.LAA13144@anise.tte.vtt.fi> To: dharkins@cisco.com CC: ipsec@tis.com In-reply-to: <199901212310.PAA00322@dharkins-ss20.cisco.com> (message from Daniel Harkins on Thu, 21 Jan 1999 15:10:43 -0800) Subject: Re: Q about SA bundles Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Daniel Harkins > There is a great leap of faith in this statement: "H2 receives the > packet and successfully applies SA1 and SA2 to this." There is probably different interpretation of "successfully apply" between me and you. For me it just means that the IPSEC transforms defined by SA1 and SA2 are successful on the received packet (authenctications, replay checks, decryptions etc. all succeed). I don't see any need for "faith" here, either the packet selects the correct SA by (dst, protocol, SPI) or not. > If both sides have identical configs your scheme could work but that > seems somewhat limited to me. What about permiscuous policy or > opportunistic encryptors? First, the IPSEC RFC's do not specify such features. However, I do think things could be desirable and have considered possibilities of implementing. But, before it can be done, the base of the IPSEC must be firmly in place, and this is what I am trying to achieve. > H2 could end up receiving packets protected by SA1 that he'll just > end up dropping because they weren't also protected with SA2. In > fact, I'd wager that you'd probably fully process the packet before > deciding to drop it. That would almost be the moral equivalent of a > DOS attack and it would be a bitch to debug to boot. Anyone can sniff the line and mount an attempt for a DOS attack by generating correct looking packets using sniffed SPI's and sequence numbers as a guide. Receiving end would have to process these packets exactly as much as "real packets" (like compute the digest value). My way of dealing with bundles doesn't make a difference. > If you don't think compound policy statements like "AH AND ESP" or > "ESP AND PCP" are particularly useful then you can just ignore the > whole SA bundle issue. I'm still trying to follow RFC-2401 and it doesn't appear to allow for selector -> apply bundle1 or bundle2 My IPSEC version uses bundles exactly as defined in RFC-2401. What I am trying to achieve is 1) The key management does not need to know about bundling at all. 2) The key management does not need to know about policy (other than what it gets via PFKEY interface) I believe we can achieve all that IPSEC is set to achieve even with above statements in force. Wouldn't it be nice to have a simple key management definition that just "managed keys", without any fuzzy issues that seems to surface, when you mix it with policy. *IF* there is a need of negotiating policy issues, let that be a different and independent standard (it could be even an extension to ISAKMP). This negotiation could transform the "meta policy" selector -> apply bundle1 or bundle2 into either selector -> apply bundle1 or selector -> apply bundle2 to be used in the SPD as specified in RFC-2401. Note: PCP is one example where a concept of optional bundle item would be useful, e.g have a policy as selector -> PCP(null,lzv,gz)?,ESP(..),AH(..) and the "SA" for PCP would be negotiated independently, and if result is NULL algorithm, no PCP headers would be generated. (Perhaps a kludge, but would avoid a need for a separate policy negotation for simple cases). The "optional" part is needed on receiver end to accept packets, even when they don't have the PCP "SA" applied. The sending side would need the PCP "SA" place holder to indicate omission of PCP by having 'null' as algorithm. > interoperable way that precludes the problems described above but > because a PF_KEY ACQUIRE message is unable to express conjunctions > you're hoping that the problem can just go away if everyone agrees > to constrain their implementations in a similar manner. In this sense you are right, I'm trying to reach a solution, where the "problem" goes away. But, without constraining the implementations. I'm just trying get the key and policy management separated. > The responder _does_ need to know whether the offer is part of a > bundle. That was the whole reason that confusing parsing and > payload numbering text was added to RFC2408. Thus making it more complex. My view is that they should have backed off and looked at the situtaion from the viewpoint I'm advocating, and made the result simpler :-) > It seems that PF_KEY has put you in a box that you're > (intentionally?) not looking out of. Imagine an ACQUIRE-like > message (with the corresponding ADD/UPDATE-like message) that could > express compound, conjunctive offers.... Yes, intentionally. I prefer to use simple concepts to build very complex systems (hey, I like LISP approach!!). If the current ISAMKP is to be used, what you suggest (complex ACQUIRE with conjuctive offers) does become necessary. The current ISKAMP and PFKEY v2 do not work together. And, of course, my point is: ISAMKP should adjust, not the PFKEY v2. -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@portal.ex.tis.com Fri Jan 22 10:08:19 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA18019 for ; Fri, 22 Jan 1999 10:08:18 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA22743 for ipsec-outgoing; Fri, 22 Jan 1999 09:22:28 -0500 (EST) Message-ID: <36A88EC6.DEA1CB3D@ibm.net> Date: Fri, 22 Jan 1999 09:44:23 -0500 From: Mike Williams X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@tis.com Subject: Multiple transforms offered in an aggressive exchange Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk RFC2408 (ISAKMP) explains the Aggressive Exchange in section 4.7. One of the points made is that "There can be only one Proposal and one Transform offered (i.e. no choices) in order for the aggressive exchange to work.". RFC2409 (IKE) takes this one step further and explains that SA negotiation is limited with Aggressive Mode. For example, the DH group can not be negotiated, additionally some of the different authentication methods may limit what can be negotiated. Understanding these limitations, I believe that there are cases where it would be possible and desirable to send multiple transforms in aggressive mode. For example, using pre-shared keys an offer could be made that includes a single proposal with several transforms all having the same DH group, but having different encryption and hash algorithms. Is this true? Is there any reason why this would not work properly? Mike Williams From owner-ipsec@portal.ex.tis.com Fri Jan 22 10:19:01 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA18149 for ; Fri, 22 Jan 1999 10:19:01 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA23327 for ipsec-outgoing; Fri, 22 Jan 1999 10:16:33 -0500 (EST) X-Authentication-Warning: valuewe1.kisite.com: Host maxdialin8.iprg.nokia.com [205.226.20.238] claimed to be riflemanii Message-ID: <01BE459A.CE6A36A0.sdavidso@nokiaip.com> From: Scott Davidson Reply-To: "sdavidso@nokiaip.com" To: "'Theo PAGTZIS'" , "ipsec@tis.com" Subject: RE: IPsec implementations sought Date: Fri, 22 Jan 1999 00:04:40 -0600 Organization: Nokia IP X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk A good place to start is the ANX project. Scott Davidson, Central US Systems Engineer Nokia IPRG Office 214-632-6191 Pager 800-246-4920 scott.davidson@iprg.nokia.com www.iprg.nokia.com -----Original Message----- From: Theo PAGTZIS [SMTP:T.Pagtzis@cs.ucl.ac.uk] Sent: Thursday, January 21, 1999 5:53 AM To: ipsec@tis.com Subject: IPsec implementations sought Hi, I am looking to find some IPSec implementations available for research. Could anyone point me to such locations? Platforms used: FreeBSD, Linux, Solaris (IP either v4 or v6) Theo From owner-ipsec@portal.ex.tis.com Fri Jan 22 12:19:11 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA19013 for ; Fri, 22 Jan 1999 12:19:11 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA23795 for ipsec-outgoing; Fri, 22 Jan 1999 12:07:32 -0500 (EST) Message-Id: <199901221728.JAA10408@chip.cisco.com> To: msa@hemuli.tte.vtt.fi (Markku Savela) cc: ipsec@tis.com Subject: Re: Q about SA bundles In-reply-to: Your message of "Fri, 22 Jan 1999 11:32:23 +0200." <199901220932.LAA13144@anise.tte.vtt.fi> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10406.917026082.1@cisco.com> Date: Fri, 22 Jan 1999 09:28:02 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk On Fri, 22 Jan 1999 11:32:23 +0200 Markku Savela wrote > > *IF* there is a need of negotiating policy issues, let that be a > different and independent standard (it could be even an extension to > ISAKMP). This negotiation could transform the "meta policy" > selector -> apply bundle1 or bundle2 > into either > selector -> apply bundle1 > or > selector -> apply bundle2 > to be used in the SPD as specified in RFC-2401. So write a draft then! What we already have as draft standard is _not_ what you're proposing. Neither is it in violation of RFC2401 in any way. People wanted to make conjunctive offers in KM and so IKE does that. That doesn't break any concepts in RFC2401. > > interoperable way that precludes the problems described above but > > because a PF_KEY ACQUIRE message is unable to express conjunctions > > you're hoping that the problem can just go away if everyone agrees > > to constrain their implementations in a similar manner. > > In this sense you are right, I'm trying to reach a solution, where the > "problem" goes away. But, without constraining the > implementations. I'm just trying get the key and policy management > separated. The "problem" goes away if you don't use PF_KEY or if you change your PF_KEY (so that it's not RFC2367). If you truely want to get "key and policy management separated" then write some drafts and try to get everyone to agree to depricate RFC2407-2409. Don't just ask people to not use a portion of a protocol that exists for a good reason. That's not gonna happen, especially since there's many independent, interoperable implementations which do it this way. > > It seems that PF_KEY has put you in a box that you're > > (intentionally?) not looking out of. Imagine an ACQUIRE-like > > message (with the corresponding ADD/UPDATE-like message) that could > > express compound, conjunctive offers.... > > Yes, intentionally. I prefer to use simple concepts to build very > complex systems (hey, I like LISP approach!!). > > If the current ISAMKP is to be used, what you suggest (complex ACQUIRE > with conjuctive offers) does become necessary. The current ISKAMP and > PFKEY v2 do not work together. And, of course, my point is: ISAMKP > should adjust, not the PFKEY v2. You're asking for a standards track RFC to change to accomodate an informational RFC? An informational RFC that has absolutely no impact on the bits-on-the-wire (except to constrain the richness of IKE). An informational RFC which is not even required to implement to have a fully compliant IPSec system! And the reason for this request is some heart-felt belief in the separation of KM and policy? Sounds like religious fundamentalism to me. I like the idea of PFKEY. I wrote one of the first apps with PFKEYv1. IKE and ISAKMP are complicated protocols. At times I hate them. But with them I can express complex statements like: "I must authenticate everything with either HMAC-SHA or HMAC-MD5, in addition I'm willing to also encrypt with either CAST-CBC or Blowfish-CBC, and in addition to that I'm willing to compress using either LZS or DEFLATE". And that's cool. To hamstring it merely to satisfy another document which is _intentionally_ not compatible with IKE is ludicrous. Dan. From owner-ipsec@portal.ex.tis.com Fri Jan 22 14:17:49 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA20189 for ; Fri, 22 Jan 1999 14:17:49 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA24329 for ipsec-outgoing; Fri, 22 Jan 1999 13:57:33 -0500 (EST) Date: Fri, 22 Jan 1999 21:17:07 +0200 (EET) From: Markku Savela Message-Id: <199901221917.VAA14073@anise.tte.vtt.fi> To: dharkins@cisco.com CC: ipsec@tis.com In-reply-to: <199901221728.JAA10408@chip.cisco.com> (message from Daniel Harkins on Fri, 22 Jan 1999 09:28:02 -0800) Subject: Re: Q about SA bundles Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@ex.tis.com Precedence: bulk Whoa! Lets cool a bit, please! I didn't really mean to ask a change into ISAKMP because of PFKEY v2 (I got carried away, sorry!). I just happened to use PFKEY v2 and found it *so far* sufficient to express the IPSEC needs, and wondered why ISAKMP appeared more complex than necessary for that purpose [In which I may be in error, and the whole reason for this debate is to find out.] Let's take another start from another angle (which has already been mentioned earlier by someone). Assume I have IPSEC that - is based on premise that the policy specification are unnegotiable and set by administration. - policy can specify any combination of AH, ESP and tunnels (currently no PCP, but I don't see any problems in adding another SA type for it). - it asks each SA independently via PFKEY v2 ACQUIRE message (and all that it expects, is that the unidirectional SA forms between the hosts on succesful negotiation; e.g. the transaction I have shown in previous messages). For example, policy on H1 could be "dst=h2" -> ESP(blowfish,sha1) AH(md5) tunnel(SG) ESP(des3 md5) AH(sha1) <-----SA's with h2 ----> <---SA's with SG - --> Transforms applied to outgoing packet in the order they are listed above. H2 would generate following independent ACQUIRE's: ACQUIRE: h1->h2 ESP(blowfish,sha1) ACQUIRE: h1->h2 AH(md5) ACQUIRE: h1->SG ESP(des3,md5) ACQUIRE: h1->SG AH(sha1) The order of the ACQUIRE's is totally irrelevant to my IPSEC. The packet can go out when all of them complete. With matching policies at SG and H2, my version of IPSEC can verify that the required transforms are done in the order as specified by the policy. It does not need any bundling support from the key management. The question that now worries me: My implementation cannot communicate with other IPSEC implementations, because they require SAs to be negotiated in bundles by ISAKMP? (A side note: in above, I need to negotiate with H2 and SG. At H1 there is one bundle, but the bundles that SG and H2 see, are only subsets of it. So, In ISAKMP world, H1 needs to split the big bundle into two bundles?) How do I solve this problem? Does ISAKMP allow me to generate SAs individually, while other IPSEC still does the bundle checking correctly (it should, there are lots of verbage in RFC-2401 about checking the bundles while assuming totally random collection of SAs in SAD; at least my implementation is done that way). One more clarification: I don't have a key management implemented myself, only the IPSEC kernel. -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@portal.ex.tis.com Fri Jan 22 18:11:28 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA22184 for ; Fri, 22 Jan 1999 18:11:28 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA25186 for ipsec-outgoing; Fri, 22 Jan 1999 18:12:33 -0500 (EST) Message-ID: From: Ricky Charlet To: "'ipsec@tis.com'" Subject: RE: Q about SA bundles Date: Fri, 22 Jan 1999 15:29:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk Howdy () So let me see if I got this right: IPSEC allows for the sharing of one SA among many SA bundles. ISAKMP does not allow for the negotiation of new bundles which make use of a pre-existing / shared SA. And furthermore there is a MIB draft out which also will not allow SA sharing among bundles. (will others my reading here)? So it either takes draft work on ISAKMP and MIB to preserve the sharing / reuse ideas or we admit that sharing/reuse of SAs among different bundles will not happen in IPSEC. Just honestly trying to come up to speed... is this where we are? ################################### # Ricky Charlet # rcharlet@RedCreek.com # (510) 795-6903 ################################### end Howdy; > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Tuesday, January 19, 1999 9:08 AM > To: Ricky Charlet > Cc: 'ipsec@tis.com' > Subject: Re: Q about SA bundles > > > Ricky, > > That's a fair question. > > Originally, one could have an SA that embraced both AH and > ESP, but they > became separated some time ago, as part of the refinement of the IPsec > architecture, and the fleshing out of the ESP definition. Also, the > definition of an SA changed to call for inclusion of the > IPsec protocol as > part of the triple (dest addr, protocol, and SPI). > > I think a (the?) major motivation for this separation is the > desire to be > able to share SAs among multiple traffic flows, which argues > for more the > discrete definition of SAs that we now have. > > Steve > From owner-ipsec@portal.ex.tis.com Sat Jan 23 07:37:59 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA16926 for ; Sat, 23 Jan 1999 07:37:59 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id HAA26638 for ipsec-outgoing; Sat, 23 Jan 1999 07:58:34 -0500 (EST) Message-Id: <3.0.32.19990122110232.009afe20@bl-mail1.corpeast.baynetworks.com> X-Sender: smamros@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 22 Jan 1999 11:02:33 -0500 To: Markku Savela From: Shawn_Mamros@BayNetworks.COM (Shawn Mamros) Subject: Re: Q about SA bundles Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk >If the current ISAMKP is to be used, what you suggest (complex ACQUIRE >with conjuctive offers) does become necessary. The current ISKAMP and >PFKEY v2 do not work together. And, of course, my point is: ISAMKP >should adjust, not the PFKEY v2. Let me get this straight: You're suggesting that we "adjust" the over- the-wire protocol - a protocol which, by the way, has been successfully tested for interoperability and which has been fielded all over the world - just because some internal API does things differently? Why don't we go and "adjust" the order of the source and destination addresses in the IPv4 header while we're at it? After all, some router implementations might be faster if they didn't have to look as far in the packet header for the destination address. I'm sorry if this sounds harsh. I don't really want it to be so harsh, but I just don't have any better way of making the point I'm trying to make here. The IKE (and IPSEC) protocols as they stand now are the product of *years* of debate. A lot of compromises had to be made along the way. But the end result is a protocol that does work, and that does solve real-world problems. If it were a couple years ago, when we were still hashing out the key management protocol details, then maybe this would be the right time to be discussing it as an issue. But that time is long past now. And even if we were still debating the protocol, I'd have to agree with Dan. If you want to do AH and ESP at the same time, then that's what you should say. The protocol is capable of expressing that unambiguously, as two proposals joined together with the same proposal number. If you want to do just ESP, or just AH, then state it that way. -Shawn Mamros E-mail to: smamros@BayNetworks.com From owner-ipsec@portal.ex.tis.com Sat Jan 23 17:26:09 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA22911 for ; Sat, 23 Jan 1999 17:26:09 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA27533 for ipsec-outgoing; Sat, 23 Jan 1999 17:28:30 -0500 (EST) Message-Id: <199901232248.OAA01488@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: dharkins owned process doing -bs X-Authentication-Warning: dharkins-ss20.cisco.com: dharkins@localhost didn't use HELO protocol To: msa@hemuli.tte.vtt.fi (Markku Savela) cc: ipsec@tis.com Subject: Re: Q about SA bundles In-reply-to: Your message of "Fri, 22 Jan 1999 21:17:07 +0200." <199901221917.VAA14073@anise.tte.vtt.fi> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1486.917131699.1@cisco.com> Date: Sat, 23 Jan 1999 14:48:19 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk On Fri, 22 Jan 1999 21:17:07 +0200 Markku Savela wrote > > For example, policy on H1 could be > > "dst=h2" -> ESP(blowfish,sha1) AH(md5) tunnel(SG) ESP(des3 md5) AH(sha1) > <-----SA's with h2 ----> <---SA's with SG - --> > > Transforms applied to outgoing packet in the order they are listed > above. H2 would generate following independent ACQUIRE's: > > ACQUIRE: h1->h2 ESP(blowfish,sha1) > ACQUIRE: h1->h2 AH(md5) > ACQUIRE: h1->SG ESP(des3,md5) > ACQUIRE: h1->SG AH(sha1) > > The order of the ACQUIRE's is totally irrelevant to my IPSEC. The > packet can go out when all of them complete. With matching policies at > SG and H2, my version of IPSEC can verify that the required transforms > are done in the order as specified by the policy. It does not need > any bundling support from the key management. As the Prime Minister says during Prime Minister's Question Time, "I refer the Right Honourable Gentleman to the comments I made some moments ago". Specificially, those in 199901221728.JAA10408@chip.cisco.com. > The question that now worries me: > > My implementation cannot communicate with other IPSEC > implementations, because they require SAs to be negotiated in > bundles by ISAKMP? > > (A side note: in above, I need to negotiate with H2 and SG. At > H1 there is one bundle, but the bundles that SG and H2 see, > are only subsets of it. So, In ISAKMP world, H1 needs to split > the big bundle into two bundles?) Actually there are 2 bundles here. One is AH and ESP protecting traffic from h1 to h2, with destination h2, and another of AH and ESP protecting AH (since that'll be the protocol of the packet as it comes by) from h1 to h2, with destination SG. SG can't have policy with selectors identifying traffic from h1 to h2 because it won't be able to look into the packet to identify that traffic. Also there's no mechanism to inform SG of the SPI chosen by h2 to use to protect this traffic. SG must have selectors for AH from h1 to h2. Since you're assuming identical configs on each side h1 must also have selectors to identify AH traffic to h2 for bundle #2. The selectors on h1 have to be different for each bundle. The way this works in our implementation is that the packet from h1 to h2 triggers an IKE negotiation to h2 to negotiate bundle #1. Depending on policy (whether h1 and SG say that IKE traffic to h2 must also be IPSec protected with the rest of the h1->h2 traffic) that may trigger another IKE exchange with SG for bundle #2. If it doesn't, if IKE can go in the clear, then the IKE exchange for bundle #2 is triggered by the first IPSec protected packet from h1 to h2, which will have a protocol of AH. Once the 2nd IKE exchange is finished the nested tunnels are formed and everything works. On the way back from h2 to h1 SG will see AH traffic and that'll match the selectors for that SPD entry. > How do I solve this problem? Does ISAKMP allow me to generate SAs > individually, while other IPSEC still does the bundle checking > correctly (it should, there are lots of verbage in RFC-2401 about > checking the bundles while assuming totally random collection of SAs > in SAD; at least my implementation is done that way). You can generate them one at a time and IKE will express them as atomic units but as I said I think your implementation will have trouble talking to other implementations sometimes. > One more clarification: I don't have a key management implemented > myself, only the IPSEC kernel. We have key management and also IPSec and nested tunnels with bundled SAs-- what you described above-- work just fine. Of course, we're not using PFKEYv2 and, therefore, are not restricted to individual, non-conjunctive, ACQUIREs. Dan. From owner-ipsec@portal.ex.tis.com Sun Jan 24 11:30:25 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA23091 for ; Sun, 24 Jan 1999 11:30:16 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA28969 for ipsec-outgoing; Sun, 24 Jan 1999 11:36:29 -0500 (EST) Message-Id: <199901241656.IAA05541@orator.netus.com> From: "Timothy M. Lyons" Organization: DigitalVooDoo, LLC To: "'Theo PAGTZIS'" , ipsec@tis.com Date: Sun, 24 Jan 1999 11:54:41 -0500 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: IPsec implementations sought In-reply-to: <01BE459A.CE6A36A0.sdavidso@nokiaip.com> X-mailer: Pegasus Mail for Win32 (v3.01d) Sender: owner-ipsec@ex.tis.com Precedence: bulk For ANX information, you may want to check out http://www.anxo.com/ and http://www.aiag.com (or is it .org?).... --Tim From: Scott Davidson Send reply to: "sdavidso@nokiaip.com" To: "'Theo PAGTZIS'" , "ipsec@tis.com" Subject: RE: IPsec implementations sought Date sent: Fri, 22 Jan 1999 00:04:40 -0600 Organization: Nokia IP > A good place to start is the ANX project. > > Scott Davidson, Central US Systems Engineer > Nokia IPRG > Office 214-632-6191 > Pager 800-246-4920 > scott.davidson@iprg.nokia.com > www.iprg.nokia.com > > -----Original Message----- > From: Theo PAGTZIS [SMTP:T.Pagtzis@cs.ucl.ac.uk] > Sent: Thursday, January 21, 1999 5:53 AM > To: ipsec@tis.com > Subject: IPsec implementations sought > > Hi, > > I am looking to find some IPSec implementations available for research. > Could anyone point me to such locations? > > Platforms used: FreeBSD, Linux, Solaris (IP either v4 or v6) > > Theo > > > > > From owner-ipsec@portal.ex.tis.com Mon Jan 25 05:09:09 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA04564 for ; Mon, 25 Jan 1999 05:09:08 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id EAA01339 for ipsec-outgoing; Mon, 25 Jan 1999 04:21:25 -0500 (EST) Date: Mon, 25 Jan 1999 11:41:51 +0200 (EET) From: Markku Savela Message-Id: <199901250941.LAA16226@anise.tte.vtt.fi> To: dharkins@cisco.com CC: ipsec@tis.com In-reply-to: <199901232248.OAA01488@dharkins-ss20.cisco.com> (message from Daniel Harkins on Sat, 23 Jan 1999 14:48:19 -0800) Subject: Re: Q about SA bundles Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@ex.tis.com Precedence: bulk Policy on H1: "dst=h2" -> ESP(blowfish,sha1) AH(md5) tunnel(SG) ESP(des3 md5) AH(sha1) generates ACQUIRE: h1->h2 ESP(blowfish,sha1) -> SA1 ACQUIRE: h1->h2 AH(md5) -> SA2 ACQUIRE: h1->SG ESP(des3,md5) -> SA3 ACQUIRE: h1->SG AH(sha1) -> SA4 > SG can't have policy with selectors identifying traffic from h1 to h2 > because it won't be able to look into the packet to identify that > traffic. There appears to be some difference in thinking. I had the following selector and policy in mind at SG: "dst=h2,src=h1" -> tunnel(h1) ESP(des3,md5) AH(sha1) The selector works, as I explained earlier, because when the tunneled packet from h1->h2 arrives at SG, it has "AH ESP IP(h1->h2) AH ESP ...". SG "unwraps" the layers addressed to it (AH, ESP, IP) *before* the policy check, and ends up with a packet from h1->h2. This is used to see what policy applies to it, fiding the above, SG notes that it matches the applied transforms and the packet can pass. > Also there's no mechanism to inform SG of the SPI chosen by h2 to > use to protect this traffic. I don't have this problem, as H1 would negotiate the two latter SA's directly with SG. H2 knows nothing about them. On H2 I would just have the policy "src=h1" -> ESP(blowfish,sha1) AH(md5) Two comments 1) I've written the policy examples for h1->SG->h2 direction only, the reverse flow (h2->sg->h1) policies could be totally different, or derived automaticly from the ones shown here to get symmetric flow. 2) If SG is not on the default path of h2 -> h1 (if SG is not the router for h2), then there is the question of how H2 knows that traffic to h1 should be routed to SG. This could be handled by explicit non-IPSEC tunnel request in the policy, for example "dst=h1" -> ESP(blowfish,sha1) AH(md5) tunnel(SG) (the packet would be "h2->sg: IPIP(h2->h1) AH ESP"), or could just have asymmetric communication, and allow the return traffic h2->h1 to go directly, without SG in between, resulting h1 ----------> SG ^ \ \ \ \ V <---------------h2 h1 would have a different policy for the return traffic "dst=h1,src=h2" -> ESP(des3,md5) AH(sha1) > Of course, we're not using PFKEYv2 and, therefore, are not > restricted to individual, non-conjunctive, ACQUIREs. More restrictive in respect to conjunctive ACQUIREs, but less restrictive in other areas, as it allows asymmetric IPSEC, sharing of SAs. And, could even do "conjunctive bundles", if there is some outside-PFKEY method to modify the policy rules. The conclusion appears to be, that the compatibility with ISAKMP requires that I need to provide the key management with access to the same policy information as the kernel has, so that it can decide on which of the bundles to accept. And, it may need a way to modify the policies in the kernel. I guess this is doable, if the need arises (I will put IPSEC to rest for few months and after that re-evaluate the situation). -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@portal.ex.tis.com Mon Jan 25 08:21:53 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA06828 for ; Mon, 25 Jan 1999 08:21:53 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA02015 for ipsec-outgoing; Mon, 25 Jan 1999 08:01:24 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <3.0.5.32.19990119223234.009876c0@smtp.datafellows.com> References: <70C20C1647EBD11183F800805FA67B43011394@vpnet.com> Date: Sun, 24 Jan 1999 19:21:48 -0500 To: Joern Sierwald From: Stephen Kent Subject: Re: No Subject Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Joern, >At 11:43 19/01/99 -0800, you wrote: >> >>Hi, >> >>I ran into an interoperability situation between 2 ipsec implementations >>when the >>customer tried to set up 2 networks behind a security gateway as part of the >>same vpn. >> >>network1 ----- >> | >> SG1----x x--SG2--- peer network >> | >>networks ----- >> > >In a QM negotiation, you use IDs to specify the networks that are >supposed to talk to each other. That could be >192.168.1.0/24 (behind SG1) and 192.168.2.0/24 (behind SG2). >I would be very surprised if the resulting SA was used for something else >than traffic between these networks. > >If SG1 really sends data from 192.168.3.0/24 through that SA, >I'd say that this implementation is faulty. > >You need several SAs here. And if each SG has 10 subnets, there will >be 100 SAs. A possible workaround would be to do QM with 0.0.0.0/0 >IDs and some policy-based filtering. > >If you want the most interoperable approach: >When sending packets, mind the QM IDs used to create the SA. >When receiving packets, you could invent a policy setting to >allow traffic that does not match the IDs. You could. I don't >say that you should. One needs to establish an SA at the granularity of each subnet, if one cannot aggregate the subnet addresses under the IPaddress range feature allowed in IKE and in the SPD definition. The SPD originally allowed for a set of disjoint addresses as a selector, but since IKE does not support that negotiation, we dropped the facility in later versions. The IPsec architecture requires a receiver to check any header fields that are used as selectors for an SA, so an implementation in which a receiver did not do so would not be compliant with RFC 2401. Steve From owner-ipsec@portal.ex.tis.com Mon Jan 25 16:29:13 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA13675 for ; Mon, 25 Jan 1999 16:29:12 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA04483 for ipsec-outgoing; Mon, 25 Jan 1999 16:45:36 -0500 (EST) Message-ID: <4FC3655B6D7DD21195E208002BB760FB09AA9E@ntwikkit> From: Waters Stephen To: ipsec@tis.com Subject: SSL v IPSEC for management? Date: Mon, 25 Jan 1999 22:08:35 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Does anyone have any details on the good/bad points of using SSL to protect management flows between a management station and a security gateway? Is SSL exposed to replay attacks for instance? Any web-page pointer on the subject? Thanks, Steve. Stephen Waters Devon, UK Tel: National 01548 551012 or 550474 International 44 1548 " or " Stephen.Waters@Cabletron.com From owner-ipsec@portal.ex.tis.com Mon Jan 25 22:35:23 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA06676 for ; Mon, 25 Jan 1999 22:35:23 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id WAA05407 for ipsec-outgoing; Mon, 25 Jan 1999 22:56:32 -0500 (EST) Message-Id: <4.1.19990125201012.00bae2e0@mail.imc.org> X-Sender: phoffman@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 25 Jan 1999 20:13:41 -0800 To: ipsec@tis.com From: Paul Hoffman Subject: New archive of the IPsec mailing list Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Greetings. The now-formaing VPN Consortium has archives of the IPsec mailing list in handier formats than those at tis.com. For each year, there is HTML-based archives as well as a text files that cover the entire year. The archives can be found at . --Paul Hoffman, Director --VPN Consortium From owner-ipsec@portal.ex.tis.com Tue Jan 26 08:32:50 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA14880 for ; Tue, 26 Jan 1999 08:32:49 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA07131 for ipsec-outgoing; Tue, 26 Jan 1999 08:10:31 -0500 (EST) Message-ID: <4FC3655B6D7DD21195E208002BB760FB1044@ntwikkit> From: Waters Stephen To: "John Shriver at EUROINTERNET" Cc: ipsec@tis.com Subject: RE: SSL v IPSEC for management? Date: Tue, 26 Jan 1999 10:15:27 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk SSL is a general socket-level protection that does allow two-way authentication. S-HTTP is security at the 'application' layer just for HTTP. Since neither of these protect the IP header (or other bits?), then I'm assuming it is not as secure as IPSEC streams - e.g. exposure to address spoofing, relay-attacks, others? Cheers, Steve. -----Original Message----- From: John Shriver at EUROINTERNET Sent: Monday, January 25, 1999 6:30 PM To: Waters Stephen Subject: RE: SSL v IPSEC for management? If SSL is what's under Secure HTTP, there's the issue that only the "server" is authenticated, not the client. From owner-ipsec@portal.ex.tis.com Tue Jan 26 08:37:13 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA14922 for ; Tue, 26 Jan 1999 08:37:12 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA07234 for ipsec-outgoing; Tue, 26 Jan 1999 08:30:30 -0500 (EST) Message-ID: <51BF55C30B4FD1118B4900207812701E2A69AF@WUHER> From: Steven Lee To: "'Waters Stephen'" Cc: "Ipsec (E-mail)" Subject: RE: SSL v IPSEC for management? Date: Tue, 26 Jan 1999 08:47:32 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen, There are some trade-offs in using the SSL; however, one of the top issue would be that a client cannot authenticate the server. Therfore, a server could someone pretending to be a trusted party and there is no way for the client to authenticate this information. You can also find more information in the following web sites: http://www.consensus.com/security/ssl-talk-faq.html You can also find the 3.0 standard in http://home.netscape.com/eng/ssl3/3-SPEC.HTM#4 Steven Lee Senior Security Engineer CygnaCom Solutions slee@cygnacom.com > -----Original Message----- > From: Waters Stephen [SMTP:stephen.Waters@cabletron.com] > Sent: Monday, January 25, 1999 5:09 PM > To: ipsec@tis.com > Subject: SSL v IPSEC for management? > > > Hi, > > Does anyone have any details on the good/bad points of using SSL to > protect > management flows between a management station and a security gateway? > Is > SSL exposed to replay attacks for instance? Any web-page pointer on > the > subject? > > Thanks, Steve. > > Stephen Waters > Devon, UK > > Tel: > National 01548 551012 or 550474 > International 44 1548 " or " > Stephen.Waters@Cabletron.com From owner-ipsec@portal.ex.tis.com Tue Jan 26 10:32:03 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA15971 for ; Tue, 26 Jan 1999 10:32:02 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA07514 for ipsec-outgoing; Tue, 26 Jan 1999 09:25:31 -0500 (EST) Message-ID: <19990126154504.A2197@laser.dsi.unimi.it> Date: Tue, 26 Jan 1999 15:45:04 +0100 From: Thomas To: ipsec@tis.com Subject: m-to-m multicast and SAs Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello everybody, I am new to the ipseC mailing list so you will forgive me if this topic has just been discussed. Your feedback together with pointers to any previous discussion are welcome. Kent & Atkinson said in RFC 2401 : "[...] A security association is uniquely identified by a triple consisting of a Security Parameter Index (SPI), an IP Destination Address, and a security protocol (AH or ESP) identifier [...]" In my opinion this definition omits an attribute, which I call *direction*, that in particulare cases (and among these some interesting multicast typologies) is indispensable for a correct SA identification. It seems that there is an implicit hypothesis that Sender and Receiver are *distinct*. This is certainly true in the typical case of unicast transmission, and in multicast contexts where transmission is really 1-TO-M, but not in the more general case. Let's start considering this unicast pathologic case: S ---------------> S SA[1] SA[1] = If we look at it 'from right', the direction is INBOUND and it is possible to correctly determine it on the basis of the *IP Destination Address* attribute; See algorithm : if ( dst == MYADDR ) direction = IN else direction = OUT But if we apply the same reasoning 'from left' we should conclude that direction is still INBOUND, where it isn't. We have two conceptually distinct objects but not enough attributes to discern them. The situation just considered has a significant impact in Multicast/Broadcast transmission schemes for which we wish to use the security mechanisms offered by IPsec and where Senders are potential Receivers and vice versa (so that SA relationship includes the loop s----->s). Multicast example: Taken m, member of the multicast group M, we want to protect outgoing traffic to M. We need a SA as : m ---------------> M SA[2] SA[2] = If m does not recognize M address as belonging to its, SA[2] behaves exactly as SA[0] and there should be no problem in applying it to the outgoing packets to the Multicast group. Consider now the specular situation by which we would ensure the traffic generated by group members and received by m (under the same algorithm-key). m <--------------- M SA[3] Now SA[2] == SA[3] (protocol identifier and SPI are the same because ingoing and outgoing traffic must be processed under the same (inverted) functions, and destination is in both cases M) Again we have two distinct SAs (SA[2] OUTBOUND and SA[3] INBOUND) but we can't discern them as they correspond to the same tuplet. Conclusion: The actual definition of SA doesn't apply to the point-to-multipoint case. We thought of two solutions for this problem: The first extends the definition of SA adding the attribute Direction (SA*), the second sets a new semantics for multicast addressing (MVH, Multicast Virtual Host). SA* = SA + Direction This modifies specs in RFC2401 : "[...] A security association is uniquely identified by a tuple consisting of a Security Parameter Index (SPI), an IP Destination Address, a security protocol (AH or ESP) identifier, and a Direction[...]" Multicast Virtual Host We map the group address to a Multicast Virtual Host: All the traffic from m to the group is directed to MVH, whereas the group traffic intercepted by m *comes* from MVH. In this way actual definition of SA can easily support multicast, but not the unicast 'pathologic' case. Note that RFC1122 [Braden] is not contraddicted: address translation is done locally and no datagram on the net has a multicast source address: MVH only exists in a sw layer between IP input routine and IPSec engine: if ( IS_MULTICAST(iphdr.dst) ) { ipFAKEhdr.dst = MYADDR; ipFAKEhdr.src = iphdr.dst; ... } Please tell me where I go wrong. THomas From owner-ipsec@portal.ex.tis.com Tue Jan 26 10:39:34 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA16069 for ; Tue, 26 Jan 1999 10:39:33 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA07758 for ipsec-outgoing; Tue, 26 Jan 1999 10:12:32 -0500 (EST) X-Mailer: exmh version 2.0.2 2/24/98 From: marcvh@aventail.com (Marc VanHeyningen) To: Steven Lee cc: "'Waters Stephen'" , "Ipsec (E-mail)" Subject: Re: SSL v IPSEC for management? In-reply-to: Your message of "Tue, 26 Jan 1999 08:47:32 EST." <51BF55C30B4FD1118B4900207812701E2A69AF@WUHER> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Jan 1999 07:32:23 -0800 Message-ID: <18943.917364743@smtp.aventail.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk Steven Lee said: > There are some trade-offs in using the SSL; however, one of the top > issue would be that a client cannot authenticate the server. Therfore, > a server could someone pretending to be a trusted party and there is no > way for the client to authenticate this information. What? That's not true at all; it's just as possible for an SSL client to verify the server's certificate information as it is for a client of any other public-key based security protocol. Regarding the other discussion, in SSL (and HTTPS, which is HTTP inside SSL/TLS) authentication of the client to the server is generally available as an optional service, while authentication of the server to the client is generally mandatory. Re the original poster, no, SSL is not known to be vulnerable to replay attacks. Which one is more suited to your purpose is hard to say from the information you give; SSL is at a higher level, can easily be entirely contained within an application instead of requiring network stack issues, can't protect UDP data, may be more vulnerable to denial-of-service attacks, is probably more vulnerable to traffic analysis, etc. relative to IPSEC. You'll have to decide which of these things are important to you. I don't understand how SSL per se is vunlerable to things like relay attacks or address-spoofing attacks, although a poorly designed application that used SSL could have such weaknesses. - Marc -- Marc VanHeyningen marcvh@aventail.com Internet Security Architect Aventail http://www.aventail.com/ From owner-ipsec@portal.ex.tis.com Tue Jan 26 10:49:53 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA16150 for ; Tue, 26 Jan 1999 10:49:51 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA07833 for ipsec-outgoing; Tue, 26 Jan 1999 10:31:32 -0500 (EST) Message-ID: <51BF55C30B4FD1118B4900207812701E2A69B1@WUHER> From: Steven Lee To: "'marcvh@aventail.com'" , Steven Lee Cc: "'Waters Stephen'" , "Ipsec (E-mail)" Subject: RE: SSL v IPSEC for management? Date: Tue, 26 Jan 1999 10:48:18 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk If the server certificate is not signed by one of the root CA installed in your browser, then you cannot authenticate. Marc, are you assuming that the certificate is issued by one of the root CA? > -----Original Message----- > From: marcvh@aventail.com [SMTP:marcvh@aventail.com] > Sent: Tuesday, January 26, 1999 10:32 AM > To: Steven Lee > Cc: 'Waters Stephen'; Ipsec (E-mail) > Subject: Re: SSL v IPSEC for management? > > Steven Lee said: > > There are some trade-offs in using the SSL; however, one of the top > > issue would be that a client cannot authenticate the server. > Therfore, > > a server could someone pretending to be a trusted party and there is > no > > way for the client to authenticate this information. > > What? That's not true at all; it's just as possible for an SSL client > to > verify the server's certificate information as it is for a client of > any > other public-key based security protocol. Regarding the other > discussion, > in SSL (and HTTPS, which is HTTP inside SSL/TLS) authentication of the > client > to the server is generally available as an optional service, while > authentication of the server to the client is generally mandatory. > > Re the original poster, no, SSL is not known to be vulnerable to > replay > attacks. Which one is more suited to your purpose is hard to say from > the information you give; SSL is at a higher level, can easily be > entirely > contained within an application instead of requiring network stack > issues, > can't protect UDP data, may be more vulnerable to denial-of-service > attacks, > is probably more vulnerable to traffic analysis, etc. relative to > IPSEC. > You'll have to decide which of these things are important to you. > > I don't understand how SSL per se is vunlerable to things like relay > attacks or address-spoofing attacks, although a poorly designed > application > that used SSL could have such weaknesses. > > - Marc > > -- > Marc VanHeyningen marcvh@aventail.com > Internet Security Architect > Aventail http://www.aventail.com/ > > From owner-ipsec@portal.ex.tis.com Tue Jan 26 11:18:11 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA16378 for ; Tue, 26 Jan 1999 11:18:10 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA07922 for ipsec-outgoing; Tue, 26 Jan 1999 10:43:31 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF7750E8@exchange> From: Tim Jenkins To: "'ipsec@tis.com'" Subject: New IPSec Monitoring MIB draft Date: Tue, 26 Jan 1999 11:05:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk Greetings, A completely brand new IPSec Monitoring MIB draft is available. It is based on the previous series of 'draft-ietf-ipsec-mib-xx.txt' series, but has removed all application specific uses of IPSec, and is the basis for a new series. As such, it is called 'draft-ietf-ipsec-monitor-mib-00.txt'. The URL is . A proposal for a VPN overlay MIB will be available within 2 weeks. This will add back some of the functionality of the previous series that was removed. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 From owner-ipsec@portal.ex.tis.com Tue Jan 26 11:38:31 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA16574 for ; Tue, 26 Jan 1999 11:38:27 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA07955 for ipsec-outgoing; Tue, 26 Jan 1999 10:45:32 -0500 (EST) X-Mailer: exmh version 2.0.2 2/24/98 From: marcvh@aventail.com (Marc VanHeyningen) To: Steven Lee cc: "Ipsec (E-mail)" Subject: Re: SSL v IPSEC for management? In-reply-to: Your message of "Tue, 26 Jan 1999 10:48:18 EST." <51BF55C30B4FD1118B4900207812701E2A69B1@WUHER> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Jan 1999 08:05:53 -0800 Message-ID: <18963.917366753@smtp.aventail.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk Steven Lee said: > If the server certificate is not signed by one of the root CA installed > in your browser, then you cannot authenticate. Marc, are you assuming > that the certificate is issued by one of the root CA? Um, yes; in any certificate-based system the certificates have to be issued by someone trusted by the verifier. I don't see how this is an SSL-specific issue; it's just as applicable to lots of other security situations, including IPSEC key management. - Marc -- Marc VanHeyningen marcvh@aventail.com Internet Security Architect Aventail http://www.aventail.com/ From owner-ipsec@portal.ex.tis.com Tue Jan 26 11:49:31 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA16696 for ; Tue, 26 Jan 1999 11:49:20 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA08068 for ipsec-outgoing; Tue, 26 Jan 1999 10:59:36 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF775111@exchange> From: Paul Kierstead To: Steven Lee , "'marcvh@aventail.com'" Cc: "'Waters Stephen'" , "Ipsec (E-mail)" Subject: RE: SSL v IPSEC for management? Date: Tue, 26 Jan 1999 11:19:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk You can install additional certificates into your browser and treat them as trusted. Naturally, these should be retrieved in a secure manner (usually some out-of-band mechanism). This problem is no different then using certs with IPSec. You always require a trusted 'root' certificate. Paul Kierstead TimeStep Corporation mailto:pmkierst@timestep.com http:\\www.timestep.com > -----Original Message----- > From: Steven Lee [mailto:slee@cygnacom.com] > Sent: Tuesday, January 26, 1999 10:48 AM > To: 'marcvh@aventail.com'; Steven Lee > Cc: 'Waters Stephen'; Ipsec (E-mail) > Subject: RE: SSL v IPSEC for management? > > > If the server certificate is not signed by one of the root CA > installed > in your browser, then you cannot authenticate. Marc, are you assuming > that the certificate is issued by one of the root CA? > > > > > -----Original Message----- > > From: marcvh@aventail.com [SMTP:marcvh@aventail.com] > > Sent: Tuesday, January 26, 1999 10:32 AM > > To: Steven Lee > > Cc: 'Waters Stephen'; Ipsec (E-mail) > > Subject: Re: SSL v IPSEC for management? > > > > Steven Lee said: > > > There are some trade-offs in using the SSL; however, one > of the top > > > issue would be that a client cannot authenticate the server. > > Therfore, > > > a server could someone pretending to be a trusted party > and there is > > no > > > way for the client to authenticate this information. > > > > What? That's not true at all; it's just as possible for an > SSL client > > to > > verify the server's certificate information as it is for a client of > > any > > other public-key based security protocol. Regarding the other > > discussion, > > in SSL (and HTTPS, which is HTTP inside SSL/TLS) > authentication of the > > client > > to the server is generally available as an optional service, while > > authentication of the server to the client is generally mandatory. > > > > Re the original poster, no, SSL is not known to be vulnerable to > > replay > > attacks. Which one is more suited to your purpose is hard > to say from > > the information you give; SSL is at a higher level, can easily be > > entirely > > contained within an application instead of requiring network stack > > issues, > > can't protect UDP data, may be more vulnerable to denial-of-service > > attacks, > > is probably more vulnerable to traffic analysis, etc. relative to > > IPSEC. > > You'll have to decide which of these things are important to you. > > > > I don't understand how SSL per se is vunlerable to things like relay > > attacks or address-spoofing attacks, although a poorly designed > > application > > that used SSL could have such weaknesses. > > > > - Marc > > > > -- > > Marc VanHeyningen marcvh@aventail.com > > Internet Security Architect > > Aventail http://www.aventail.com/ > > > > > From owner-ipsec@portal.ex.tis.com Tue Jan 26 13:38:20 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA17928 for ; Tue, 26 Jan 1999 13:38:17 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA08628 for ipsec-outgoing; Tue, 26 Jan 1999 12:16:32 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF775195@exchange> From: Tim Jenkins To: "'ipsec@tis.com'" Subject: RE: New IPSec Monitoring MIB draft Date: Tue, 26 Jan 1999 12:38:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk A typo shows in the URL. Use the line above it to change it to The URL is . --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Tim Jenkins [mailto:tjenkins@TimeStep.com] > Sent: Tuesday, January 26, 1999 11:05 AM > To: 'ipsec@tis.com' > Subject: New IPSec Monitoring MIB draft > > > Greetings, > > A completely brand new IPSec Monitoring MIB draft is > available. It is based > on the previous series of 'draft-ietf-ipsec-mib-xx.txt' > series, but has > removed all application specific uses of IPSec, and is the > basis for a new > series. As such, it is called 'draft-ietf-ipsec-monitor-mib-00.txt'. > > The URL is . > > A proposal for a VPN overlay MIB will be available within 2 > weeks. This will > add back some of the functionality of the previous series > that was removed. > > --- > Tim Jenkins TimeStep Corporation > tjenkins@timestep.com http://www.timestep.com > (613) 599-3610 x4304 Fax: (613) 599-3617 > From owner-ipsec@portal.ex.tis.com Tue Jan 26 23:59:58 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA08442; Tue, 26 Jan 1999 23:59:54 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id AAA11300 for ipsec-outgoing; Wed, 27 Jan 1999 00:42:32 -0500 (EST) From: dbastien@galea.com X-Lotus-FromDomain: GALEA To: ipsec@tis.com Message-ID: <85256705.005A38D5.00@gotlib.galea.com> Date: Tue, 26 Jan 1999 11:32:55 -0500 Subject: Legal claims on encryption and authentication algorithm Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, While reading RFC 1321, I noted that if we use MD5, we must state that it was developped by RSA Data Security, Inc. We use other encryption and authentication algorithms. Is there any legal claims (copyrights, patents, etc.) tied to the following algorithms? - Blowfish - DES - 3DES - SHA-1 Thank you From owner-ipsec@portal.ex.tis.com Wed Jan 27 04:20:50 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA18658; Wed, 27 Jan 1999 04:20:49 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id EAA11956 for ipsec-outgoing; Wed, 27 Jan 1999 04:20:33 -0500 (EST) Date: Wed, 27 Jan 1999 11:40:18 +0200 (EET) From: Markku Savela Message-Id: <199901270940.LAA18926@anise.tte.vtt.fi> To: tho@laser.dsi.unimi.it CC: ipsec@tis.com In-reply-to: <19990126154504.A2197@laser.dsi.unimi.it> (message from Thomas on Tue, 26 Jan 1999 15:45:04 +0100) Subject: Re: m-to-m multicast and SAs Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Not sure if I'm qualified to answer this, but having posted quite a few cryptic messages to this list in hopes of getting good answers, I feel I need to do something in return.. So, I try to answer something... > From: Thomas > Consider now the specular situation by which we would ensure the traffic > generated by group members and received by m (under the same algorithm-key). > > m <--------------- M > SA[3] > Now SA[2] == SA[3] (protocol identifier and SPI are the same because ingoing > and outgoing traffic must be processed under the same (inverted) functions, > and destination is in both cases M) > > Again we have two distinct SAs (SA[2] OUTBOUND and SA[3] INBOUND) but we > can't discern them as they correspond to the same tuplet. Why distinct? A single SA for multicast group would work for both receives and sends with multicast group. One could also have source specific SA's negotiated within a multicast group, however I don't think any one has yet thought about Key management in multicast groups. Your multicast host would just have policy inbound dst=M -> Apply SA[2] (applying to inconming) outbound dst=M -> Apply SA[2] (applying to outgoing) inbound src=m2 dst=M -> Apply SA[4] (source specific SA) You don't test the INBOUND and OUTBOUND status from the packet addresses, you know it implicitly from the context (or you test the SRC address!). Aside from the conceptual problems in multicast key distributions and negotiations, I don't see any problems applyinc SA's to multicast. -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@portal.ex.tis.com Wed Jan 27 09:04:04 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA20953; Wed, 27 Jan 1999 09:04:02 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA13023 for ipsec-outgoing; Wed, 27 Jan 1999 08:47:30 -0500 (EST) Message-ID: <002501be49b1$f9e7ce30$0100140a@ne.mediaone.net> From: "kwok c. lee" To: "Steven Lee" Cc: "Ipsec (E-mail)" Subject: Re: SSL v IPSEC for management? Date: Wed, 27 Jan 1999 00:00:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.0810.800 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Sender: owner-ipsec@ex.tis.com Precedence: bulk In this case, the client simply cannot trust the server. The issue here is that it is possible for the SSL client to authenticate the server. ----- Original Message ----- From: Steven Lee To: ; Steven Lee Cc: 'Waters Stephen' ; Ipsec (E-mail) Sent: Tuesday, January 26, 1999 10:48 AM Subject: RE: SSL v IPSEC for management? >If the server certificate is not signed by one of the root CA installed >in your browser, then you cannot authenticate. Marc, are you assuming >that the certificate is issued by one of the root CA? > > > >> -----Original Message----- >> From: marcvh@aventail.com [SMTP:marcvh@aventail.com] >> Sent: Tuesday, January 26, 1999 10:32 AM >> To: Steven Lee >> Cc: 'Waters Stephen'; Ipsec (E-mail) >> Subject: Re: SSL v IPSEC for management? >> >> Steven Lee said: >> > There are some trade-offs in using the SSL; however, one of the top >> > issue would be that a client cannot authenticate the server. >> Therfore, >> > a server could someone pretending to be a trusted party and there is >> no >> > way for the client to authenticate this information. >> >> What? That's not true at all; it's just as possible for an SSL client >> to >> verify the server's certificate information as it is for a client of >> any >> other public-key based security protocol. Regarding the other >> discussion, >> in SSL (and HTTPS, which is HTTP inside SSL/TLS) authentication of the >> client >> to the server is generally available as an optional service, while >> authentication of the server to the client is generally mandatory. >> >> Re the original poster, no, SSL is not known to be vulnerable to >> replay >> attacks. Which one is more suited to your purpose is hard to say from >> the information you give; SSL is at a higher level, can easily be >> entirely >> contained within an application instead of requiring network stack >> issues, >> can't protect UDP data, may be more vulnerable to denial-of-service >> attacks, >> is probably more vulnerable to traffic analysis, etc. relative to >> IPSEC. >> You'll have to decide which of these things are important to you. >> >> I don't understand how SSL per se is vunlerable to things like relay >> attacks or address-spoofing attacks, although a poorly designed >> application >> that used SSL could have such weaknesses. >> >> - Marc >> >> -- >> Marc VanHeyningen marcvh@aventail.com >> Internet Security Architect >> Aventail http://www.aventail.com/ >> >> > From owner-ipsec@portal.ex.tis.com Wed Jan 27 09:09:42 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA20998; Wed, 27 Jan 1999 09:09:42 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA12963 for ipsec-outgoing; Wed, 27 Jan 1999 08:42:31 -0500 (EST) Message-Id: <3.0.32.19990126220306.00977e80@intotoinc.com> X-Sender: sathyan@intotoinc.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 26 Jan 1999 22:03:07 -0800 To: ipsec@tis.com From: Sathyan Iyengar Subject: US govt. restrictions on export/import of IPSEC implementations Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, I am in the process of finding latest information on US Govt. restrictions on export/import of encryption related implementations. Searching in DOC is difficult. Please direct me to specific URLs or govt. documents which have latest information on this. We make IPSEC software for Embedded Systems. Is there any trade group or any law firm which is on top of all these? If anyone knows any encryption/export-control attorney, please send me their contacts. Thanks, -Sathyan /******************************************************************* IEEE-1394, PCMCIA, Flash, IPSEC Solution Provider for Embedded Sys**/ Intoto Inc. Ph : 408-844-0480 Ext:302 3160, De La Cruz Blvd. Fax : 408-844-0488 Suite #100, Santa Clara e-mail: sathyan@intotoinc.com CA - 95054, USA Web : www.intotoinc.com ********************************************************************/ From owner-ipsec@portal.ex.tis.com Wed Jan 27 09:55:28 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA21412; Wed, 27 Jan 1999 09:55:28 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA13313 for ipsec-outgoing; Wed, 27 Jan 1999 09:29:37 -0500 (EST) Date: Wed, 27 Jan 1999 09:49:19 -0500 Message-Id: <199901271449.JAA04843@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: tjenkins@TimeStep.com Cc: ipsec@tis.com Subject: RE: New IPSec Monitoring MIB draft References: <319A1C5F94C8D11192DE00805FBBADDF775195@exchange> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk Tim, This draft looks promising. It shows a structure that can do the job it sets out to do. Looking ahead, though, I wonder if it is the optimal structure for the longer term. This MIB is a monitoring MIB, and it certainly shows most or all of what you might want to monitor. But at some point we will also want to have a configuration MIB. Clearly, those two MIBs would ideally use a similar way of organizing the data. Your draft shows all the IPSEC/IPCOMP related data in one place: the protection suite table rows. That method of organization may not be all that convenient in a configuration MIB. For example, parameters such as expiration limits, security services to use, etc., could be organized in a table ("policies" -- or maybe that name is already taken?) where they are named and then referred to. If lots of protection suites are set up to a common pattern, this simplifies configuration. Such an organization could also be applied to the monitoring MIB if we want to do that. So do we want to do that? I can see several possible approaches: 1. Continue with the monitoring MIB in its present form; when we get to a configuration MIB, that one may have a different organization, but that's ok. 2. Spend some time outlining a skeleton configuration MIB organization, and adjust the monitoring MIB to have an analogous organization. Obviously, #1 is quicker. Which one is better depends on whether people feel it's more important to have a monitoring MIB soon vs. having one closely patterned after the configuration MIB. To put a stake in the ground, I'd prefer #2 because in the long run it will make for a clearer and easier to understand picture. paul From owner-ipsec@portal.ex.tis.com Wed Jan 27 10:06:42 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA21542; Wed, 27 Jan 1999 10:06:41 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA13394 for ipsec-outgoing; Wed, 27 Jan 1999 09:42:37 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF775443@exchange> From: Tim Jenkins To: Paul Koning Cc: ipsec@tis.com Subject: RE: New IPSec Monitoring MIB draft Date: Wed, 27 Jan 1999 10:04:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk Paul, Thanks for the comments. Regarding the ideas about a configuration MIB, I believe that configuration of IPSec is really configuration of policy. After all, it is the occurrence of events/traffic/etc. that, when applied against the policy of a system, cause the creation of SAs. This MIB is supposed to indicate what you have, but not how you got there. Since we have no standard way do define policy, a configuration MIB will probably not get done until after policy is defined. There are already a number of proposals for defining standard policy; drawing this MIB into that will only slow its progress. The only reason you would ever want to write to this MIB would be if you wanted to change something about an existing SA. However, I don't believe that this is the appropriate method to do that. Tim --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Paul Koning [mailto:pkoning@xedia.com] > Sent: Wednesday, January 27, 1999 9:49 AM > To: tjenkins@TimeStep.com > Cc: ipsec@tis.com > Subject: RE: New IPSec Monitoring MIB draft > > > Tim, > > This draft looks promising. It shows a structure that can do the job > it sets out to do. > > Looking ahead, though, I wonder if it is the optimal structure for the > longer term. This MIB is a monitoring MIB, and it certainly shows > most or all of what you might want to monitor. But at some point we > will also want to have a configuration MIB. Clearly, those two MIBs > would ideally use a similar way of organizing the data. > > Your draft shows all the IPSEC/IPCOMP related data in one place: the > protection suite table rows. That method of organization may not be > all that convenient in a configuration MIB. For example, parameters > such as expiration limits, security services to use, etc., could be > organized in a table ("policies" -- or maybe that name is already > taken?) where they are named and then referred to. If lots of > protection suites are set up to a common pattern, this simplifies > configuration. > > Such an organization could also be applied to the monitoring > MIB if we > want to do that. So do we want to do that? I can see several > possible approaches: > > 1. Continue with the monitoring MIB in its present form; when we get > to a configuration MIB, that one may have a different organization, > but that's ok. > > 2. Spend some time outlining a skeleton configuration MIB > organization, and adjust the monitoring MIB to have an analogous > organization. > > Obviously, #1 is quicker. Which one is better depends on whether > people feel it's more important to have a monitoring MIB soon > vs. having one closely patterned after the configuration MIB. To put > a stake in the ground, I'd prefer #2 because in the long run it will > make for a clearer and easier to understand picture. > > paul > From owner-ipsec@portal.ex.tis.com Wed Jan 27 10:45:21 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA21872; Wed, 27 Jan 1999 10:45:20 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA13839 for ipsec-outgoing; Wed, 27 Jan 1999 10:56:38 -0500 (EST) Message-ID: <36AF3BDF.39064616@sympatico.ca> Date: Wed, 27 Jan 1999 11:16:31 -0500 From: Sandy Harris Organization: Crash Test Dummies on the Information Highway X-Mailer: Mozilla 4.5 [en]C-SYMPA (Win95; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: Sathyan Iyengar CC: ipsec@tis.com Subject: Re: US govt. restrictions on export/import of IPSEC implementations References: <3.0.32.19990126220306.00977e80@intotoinc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Sathyan Iyengar wrote: > > Hi, > > I am in the process of finding latest information on US Govt. > restrictions on export/import of encryption related implementations. > Searching in DOC is difficult. Please direct me to specific URLs > or govt. documents which have latest information on this. A new version of Linux FreeSWAN docs in HTML should appear on distribution site: ftp://ftp.xs4al.nl/pub/crypto/freeswan in a few days. Here are its links for what you're asking:

Cryptography law and policy

If you find other relevant links, please post or mail & I'll add them there. You might also want to look at the Wassenaar Agreement: Wassenaar details available from the Wassenaar Secretariat and elswhere in an HTML version. -- "The real aim of current [cryptography] policy is to ensure the continued effectiveness of US information warfare assets against individuals, businesses and governments in Europe and elsewhere" Ross Anderson, Cambridge University From owner-ipsec@portal.ex.tis.com Wed Jan 27 16:34:08 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA02280; Wed, 27 Jan 1999 16:34:07 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA15132 for ipsec-outgoing; Wed, 27 Jan 1999 16:04:42 -0500 (EST) From: "Michael H. Warfield" Message-Id: <199901272124.QAA25250@alcove.wittsend.com> Subject: Re: SSL v IPSEC for management? In-Reply-To: <002501be49b1$f9e7ce30$0100140a@ne.mediaone.net> from "kwok c. lee" at "Jan 27, 1999 0: 0:35 am" To: kclee@mediaone.net (kwok c. lee) Date: Wed, 27 Jan 1999 16:24:52 -0500 (EST) Cc: slee@cygnacom.com, ipsec@tis.com X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk kwok c. lee enscribed thusly: > In this case, the client simply cannot trust the server. > The issue here is that it is possible for the SSL client to authenticate > the server. The client shouldn't have to trust the server. The server presents a certificate which, presumably, has some information which indelibly links that certificate to the server. In the case of web servers, that's generally the common name in the certificate matching the server name you are contacting. This does rely on information in the DNS being acurate. My server, www.wittsend.com, presents a certificate claiming to be www.wittsend.com and DNS lookup on www.wittsend.com confirms this. Now, how do we know that this is not some bogus certificate? The certificate is signed by Verisign or some other well known certifying authority. Can the client authenticate the server? Of course. It all depends upon what degree of trust you want to place in that authentication. To break this system, someone would have to steal (or forge - much tougher) my server certificate, get past the pass phrase, and poison the DNS so that you think his address is mine. Is that enough? Maybe, maybe not. If it is enough, then the client can authenticate the server to its own satisfaction. Now the question of "am I the server that you wanted to talk to" is another story and outside the scope of simple authentication. Maybe someone mistyped a name and it should have been www.witsend.com (one 't'). You would authenticate my server just fine, but I'm not the one you wanted to talk to. That's not an authentication problem. At least not in terms of authenticating the certificates. None of this differs from authenticating certificates with respect to IPSEC certificates. Unless you are dealing with out of band communication to handle certificates, or manual keying, I just don't see the differences in the authentication issues here... > > ----- Original Message ----- > From: Steven Lee > To: ; Steven Lee > Cc: 'Waters Stephen' ; Ipsec (E-mail) > > Sent: Tuesday, January 26, 1999 10:48 AM > Subject: RE: SSL v IPSEC for management? > > > >If the server certificate is not signed by one of the root CA installed > >in your browser, then you cannot authenticate. Marc, are you assuming > >that the certificate is issued by one of the root CA? > > > > > > > >> -----Original Message----- > >> From: marcvh@aventail.com [SMTP:marcvh@aventail.com] > >> Sent: Tuesday, January 26, 1999 10:32 AM > >> To: Steven Lee > >> Cc: 'Waters Stephen'; Ipsec (E-mail) > >> Subject: Re: SSL v IPSEC for management? > >> > >> Steven Lee said: > >> > There are some trade-offs in using the SSL; however, one of the top > >> > issue would be that a client cannot authenticate the server. > >> Therfore, > >> > a server could someone pretending to be a trusted party and there is > >> no > >> > way for the client to authenticate this information. > >> > >> What? That's not true at all; it's just as possible for an SSL client > >> to > >> verify the server's certificate information as it is for a client of > >> any > >> other public-key based security protocol. Regarding the other > >> discussion, > >> in SSL (and HTTPS, which is HTTP inside SSL/TLS) authentication of the > >> client > >> to the server is generally available as an optional service, while > >> authentication of the server to the client is generally mandatory. > >> > >> Re the original poster, no, SSL is not known to be vulnerable to > >> replay > >> attacks. Which one is more suited to your purpose is hard to say from > >> the information you give; SSL is at a higher level, can easily be > >> entirely > >> contained within an application instead of requiring network stack > >> issues, > >> can't protect UDP data, may be more vulnerable to denial-of-service > >> attacks, > >> is probably more vulnerable to traffic analysis, etc. relative to > >> IPSEC. > >> You'll have to decide which of these things are important to you. > >> > >> I don't understand how SSL per se is vunlerable to things like relay > >> attacks or address-spoofing attacks, although a poorly designed > >> application > >> that used SSL could have such weaknesses. > >> > >> - Marc > >> > >> -- > >> Marc VanHeyningen marcvh@aventail.com > >> Internet Security Architect > >> Aventail http://www.aventail.com/ Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 925-8248 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From owner-ipsec@portal.ex.tis.com Wed Jan 27 16:35:55 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA02385; Wed, 27 Jan 1999 16:35:54 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA15126 for ipsec-outgoing; Wed, 27 Jan 1999 16:04:32 -0500 (EST) Date: Wed, 27 Jan 1999 20:11:25 +0200 (EET) Message-Id: <199901271811.UAA21213@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Tim Jenkins Cc: "'ipsec@tis.com'" Subject: RE: New IPSec Monitoring MIB draft In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDF775195@exchange> References: <319A1C5F94C8D11192DE00805FBBADDF775195@exchange> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 3 min X-Total-Time: 2 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Tim Jenkins writes: > A typo shows in the URL. Use the line above it to change it to > The URL is . Some comments about the draft: There doesn't seem to be any way to identify what ISAKMP SA (phase 1) was used to create IPSec SA (phase 2). There is no index from the IpsecProtSuiteEntry to the IpsecIkeSaEntry. I think there should be a way to find the Phase 1 SA based on the Phase 2 SA, so users can find for example the certificate and the identities used to create that IPSec SA. > -- protection suite selectors > ipsecProtSuiteLocalId OCTET STRING, > ipsecProtSuiteLocalIdType Unsigned32, > ipsecProtSuiteRemoteId OCTET STRING, > ipsecProtSuiteRemoteIdType Unsigned32, > ipsecProtSuiteProtocol Integer32, I think the ISAKMP doesn't restrict the protocol to be same in both local and remote id, but it really doesn't make sence to have them different. > -- creation mechanism > ipsecProtSuiteDifHelGroupDesc Integer32, > ipsecProtSuiteDifHelGroupType Integer32, > ipsecProtSuitePFS TruthValue, Do we really need the PFS flag? If we have ipsecProtSuiteDifHelGroupDesc that is different from zero then we have PFS, otherwise we do not have it. I would leave it out completely, because it is just duplication of the data. > -- expiration limits > ipsecProtSuiteCreationTime DateAndTime, > ipsecProtSuiteTimeLimit OCTET STRING, -- sec., 0 if none > ipsecProtSuiteTrafficLimit OCTET STRING, -- 0 if none > ipsecProtSuiteInTrafficCount OCTET STRING, > ipsecProtSuiteOutTrafficCount OCTET STRING, Why octet string. I know that those can be variable length, but I think Counter64 or similar is enough for them. > ipsecProtSuiteTimeLimit OBJECT-TYPE > SYNTAX OCTET STRING (SIZE (4..255)) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The maximum lifetime in seconds of the protection suite, > or 0 if there is no time constraint on its expiration." > ::= { ipsecProtSuiteEntry 27 } Are they ascii representation of the number or just binary value of the number (I assume binary)? If they are binary values then the minimum size should be 2, because if those lifetimes are expressed as basic encoding then their length is 2 bytes. > ipsecProtSuiteEspEncKeyLength Unsigned32, ... > ipsecProtSuiteEspEncKeyLength OBJECT-TYPE > SYNTAX Unsigned32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The length of the encryption key in bits used for the > algorithm specified in the 'ipsecTunnelEspEncAlg' object, > or 0 if the key length is implicit in the specified > algorithm or there is no encryption specified." > ::= { ipsecProtSuiteEntry 22 } The key length must be basic encoded, so its maximum value is 65535. > -- security algorithm information > ipsecIkeSaEncAlg INTEGER, > ipsecIkeSaEncKeyLength Integer32, > ipsecIkeSaHashAlg Integer32, > ipsecIkeSaDifHelGroupDesc Integer32, > ipsecIkeSaDifHelGroupType Integer32, > ipsecIkeSaDifHelFieldSize Integer32, > ipsecIkeSaPRF Integer32, Why ipsecIkeSaEncAlg is INTEGER and rest are Integer32? > ipsecIkeSaEncKeyLength OBJECT-TYPE > SYNTAX Integer32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The length of the encryption key in bits used for > algorithm specified in the ipsecIkeSaEncAlg object or 0 > if the key length is implicit in the specified > algorithm." > ::= { ipsecIkeSaEntry 18 } Here is a same thing that maximum value of the key length is 65535, so SYNTAX Integer32 (0..65535) should be used. Is there any reason why ipsecProtSuiteEspEncKeyLength was Unsigned32 and ipsecIkeSaEncKeyLength is Integer32? > ipsecIkeSaDifHelFieldSize OBJECT-TYPE > SYNTAX Integer32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The field size, in bits, of the Diffie-Hellman group > used to generate the key-pair, or 0 if unknown." > ::= { ipsecIkeSaEntry 22 } This have also maximum value of 65535, because of basic encoding of the value in the IKE. > ipsecIkeSaPFS OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "A value that indicates that perfect forward secrecy is > used for all IPSec SAs created by this IKE SA." > ::= { ipsecIkeSaEntry 24 } This is a policy information, that cannot be found from anywhere in the packets in the wire. If this MIB tries to remove all policy information it should remove this one too. > ipsecIkeSaTimeLimit OBJECT-TYPE > SYNTAX OCTET STRING > UNITS "seconds" > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The maximum lifetime in seconds of the SA, or 0 if there > is no time constraint on its expiration." > ::= { ipsecIkeSaEntry 26 } > > ipsecIkeSaTrafficLimit OBJECT-TYPE > SYNTAX OCTET STRING > UNITS "Kbytes" > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The maximum traffic in 1024-byte blocks that the SA is > allowed to carry, or 0 if there is no traffic constraint > on its expiration." > ::= { ipsecIkeSaEntry 27 } Is this again ascii number or binary, and why this doesn't have size constraints while the ipsec versions have? > ipsecIkeSaEncAlg - Encryption Algorithm > DES40-CBC 65001 > ipsecTunnelEspEncAlg > ESP_DES40 249 Again. Do we need the Appendix A at all? Anyways it looks quite good now... -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@portal.ex.tis.com Wed Jan 27 18:46:00 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA17199; Wed, 27 Jan 1999 18:45:59 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA15744 for ipsec-outgoing; Wed, 27 Jan 1999 18:12:43 -0500 (EST) From: "Michael H. Warfield" Message-Id: <199901272332.SAA29285@alcove.wittsend.com> Subject: Re: SSL v IPSEC for management? In-Reply-To: <592.917478951@smtp.aventail.com> from Marc VanHeyningen at "Jan 27, 1999 3:15:51 pm" To: marcvh@aventail.com (Marc VanHeyningen) Date: Wed, 27 Jan 1999 18:32:58 -0500 (EST) Cc: mhw@wittsend.com, kclee@mediaone.net, slee@cygnacom.com, ipsec@tis.com X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Marc VanHeyningen enscribed thusly: > Michael H. Warfield said: > > The client shouldn't have to trust the server. The server presents > > a certificate which, presumably, has some information which indelibly > > links that certificate to the server. In the case of web servers, that's > > generally the common name in the certificate matching the server name > > you are contacting. This does rely on information in the DNS being > > acurate. My server, www.wittsend.com, presents a certificate claiming > > to be www.wittsend.com and DNS lookup on www.wittsend.com confirms this. > I agree with everything you say except the part about DNS. > A good SSL (or anything else, for that matter) implementation should not > rely on DNS resolution. The DNS lookup of the address is necessary so > that the IP layer can know where it is connecting to, but the SSL layer > should be comparing the name as typed in by the user with the name as > presented in the certificate, not a name which has undergone forward or > reverse or any other form of DNS. Oh! I agree... The SSL layer should compare the name typed in by the user with the name presented in the certificate. What I meant was that it should ALSO compare with DNS. You type in www.wittsend.com and you get back a certificate that says www.wittsend.com but the DNS says "no, that's really foo.scruffy.lowlife.offshore". Ok, what do you do then? > This can pose some issues; if instead of trying to connect to www.wittsend.com > I instead type in the IP address it happens to resolve to, then I'll be > unable to know whether I connected to the right place unless either the > certificate contains the IP address as well as the name, or I choose to > trust reverse DNS. The easiest solution is "don't do that." Agreed. What I meant was that DNS should be yet another level of double check that you are doing what you think you are doing. I didn't mean it instead of checking you got what you asked for. Same thing holds true with virtual servers. You can get to the same server as "www.wittsend.com" or "alcove.wittsend.com" (same address) or "www.bdcustom.com" (same system, different address). The certificate will only match on "www.wittsend.com" (I don't have a cert for bdcustom and alcove is the cname for the iron). You want to contact www.wittsend.com you use www.wittsend.com, you don't use alcove.wittsend.com or 130.205.0.22. > - Marc > -- > Marc VanHeyningen marcvh@aventail.com > Internet Security Architect > Aventail http://www.aventail.com/ Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 925-8248 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From owner-ipsec@portal.ex.tis.com Wed Jan 27 18:47:45 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA17234; Wed, 27 Jan 1999 18:47:44 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA15713 for ipsec-outgoing; Wed, 27 Jan 1999 17:55:43 -0500 (EST) X-Mailer: exmh version 2.0.2 2/24/98 From: marcvh@aventail.com (Marc VanHeyningen) To: "Michael H. Warfield" cc: kclee@mediaone.net (kwok c. lee), slee@cygnacom.com, ipsec@tis.com Subject: Re: SSL v IPSEC for management? In-reply-to: Your message of "Wed, 27 Jan 1999 16:24:52 EST." <199901272124.QAA25250@alcove.wittsend.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Jan 1999 15:15:51 -0800 Message-ID: <592.917478951@smtp.aventail.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk Michael H. Warfield said: > The client shouldn't have to trust the server. The server presents > a certificate which, presumably, has some information which indelibly > links that certificate to the server. In the case of web servers, that's > generally the common name in the certificate matching the server name > you are contacting. This does rely on information in the DNS being > acurate. My server, www.wittsend.com, presents a certificate claiming > to be www.wittsend.com and DNS lookup on www.wittsend.com confirms this. I agree with everything you say except the part about DNS. A good SSL (or anything else, for that matter) implementation should not rely on DNS resolution. The DNS lookup of the address is necessary so that the IP layer can know where it is connecting to, but the SSL layer should be comparing the name as typed in by the user with the name as presented in the certificate, not a name which has undergone forward or reverse or any other form of DNS. This can pose some issues; if instead of trying to connect to www.wittsend.com I instead type in the IP address it happens to resolve to, then I'll be unable to know whether I connected to the right place unless either the certificate contains the IP address as well as the name, or I choose to trust reverse DNS. The easiest solution is "don't do that." - Marc -- Marc VanHeyningen marcvh@aventail.com Internet Security Architect Aventail http://www.aventail.com/ From owner-ipsec@portal.ex.tis.com Wed Jan 27 20:50:49 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA04250; Wed, 27 Jan 1999 20:50:48 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id VAA16199 for ipsec-outgoing; Wed, 27 Jan 1999 21:14:45 -0500 (EST) Message-Id: <199901280234.VAA03373@smb.research.att.com> X-Mailer: exmh version 1.6.9 8/22/96 From: Steve Bellovin To: ipsec@tis.com, end2end-interest@isi.edu, tsv@ee.lbl.gov, diff-serv@BayNetworks.COM, ecn-interest@research.att.com, red-impl@lbl.gov Subject: transport-friendly ESP Cc: jis@MIT.EDU, mleech@nortel.ca Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Jan 1999 21:34:35 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk I've set up a new mailing list, tf-esp@research.att.com, to discuss the design of a transport-friendly variant of ESP (a core piece of IPSEC). Subscription is via majordomo@research.att.com. The problem is that ESP, by hiding all of the TCP (and UDP) headers, makes life difficult for other purposes, such as discerning flows, building firewalls, etc. Can we come up with a variant of ESP that -- optionally -- leaves some of the packet header in the clear? A strawman proposal can be found in http://www.research.att.com/~smb/talks/mesp .ps or http://www.research.att.com/~smb/talks/mesp.pdf (content is the same). It leaves an indicated amount of the prefix in the clear. It's reasonably efficient in both space and time. However, it is based on the tacit assumption that the prefix of the packet headers are the least significant from a security perspective -- is this true? Do we need a more complex format that permits individual fields or ranges to be in the clear? How do we prevent careless leakage of sensitive data? For example, if the TCP checksum is exposed, an enemy can read all one- and two-byte payloads. How is this negotiated? It can't be a simple length, since that doesn't take into account UDP vs. TCP, IP options, IPv6 headers, etc. Is there any need to permit controlled modifications to packets? If so, how do we protect against nasty changes? Apart from discussing these questions on the list, we need to decide if we want to hold a BoF in Minneapolis. If the answer is yes, we'd also need to write up a charter and select chairs, preferably one from the security area and one from the transport area. Nominations are hereby solicited. The output of an eventual tfesp working group would be two or three RFCs -- standards-track RFCs to define the new header, to define the additions to IKE to negotiate use of this modified format, and possibly an informational RFC setting out the rationale for the change -- and the security caveats that would attend its use. From owner-ipsec@portal.ex.tis.com Wed Jan 27 23:13:54 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA17572; Wed, 27 Jan 1999 23:13:54 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id XAA16535 for ipsec-outgoing; Wed, 27 Jan 1999 23:52:43 -0500 (EST) Message-Id: <3.0.3.32.19990127200721.00b553e0@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Wed, 27 Jan 1999 20:07:21 -0800 To: Steve Bellovin , ipsec@tis.com, end2end-interest@isi.edu, tsv@ee.lbl.gov, diff-serv@BayNetworks.COM, ecn-interest@research.att.com, red-impl@lbl.gov From: Alex Alten Subject: Re: transport-friendly ESP Cc: jis@MIT.EDU, mleech@nortel.ca In-Reply-To: <199901280234.VAA03373@smb.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 09:34 PM 1/27/99 -0500, Steve Bellovin wrote: >I've set up a new mailing list, tf-esp@research.att.com, to discuss the >design of a transport-friendly variant of ESP (a core piece of IPSEC). >Subscription is via majordomo@research.att.com. > >The problem is that ESP, by hiding all of the TCP (and UDP) headers, makes >life difficult for other purposes, such as discerning flows, building >firewalls, etc. Can we come up with a variant of ESP that -- optionally -- >leaves some of the packet header in the clear? > Interesting. The end-to-end (e.g. host-to-host) nature of ESP conflicts with the need for intermediate nodes to access header information. Wouldn't it make more sense to let ESP secure per hop IP links? This way the transport headers are automatically decrypted coming into a node and re-encrypted exiting it. This allows firewall software, etc., to operate as-is. If one needs end-to-end security then TLS/SSL could then be layered on top. I know that that trusting intermediate nodes with clear IP packets in their RAM is a hard sell. But if TLS/SSL is being used to protect end-to-end user data payloads, why not just use ESP to protect the management and use of individual IP links? I.e. the routing packets, nearest neighbor discovery, etc., along with the datagrams (ICMP would need to handle its own end-to-end security). This would eliminate the need for doing transport-friendly ESP variants. - Alex -- Alex Alten Alten@Home.Com Alten@TriStrata.Com P.O. Box 11406 Pleasanton, CA 94588 USA (925) 417-0159 From owner-ipsec@portal.ex.tis.com Thu Jan 28 07:45:34 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA00611; Thu, 28 Jan 1999 07:45:34 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA18282 for ipsec-outgoing; Thu, 28 Jan 1999 08:06:42 -0500 (EST) From: Lixia Zhang Message-Id: <199901280614.WAA17897@aurora.cs.ucla.edu> Subject: Re: transport-friendly ESP To: deering@cisco.com (Steve Deering) Date: Wed, 27 Jan 1999 22:14:25 -0800 (PST) Cc: smb@research.att.com, ipsec@tis.com, end2end-interest@isi.edu, tsv@ee.lbl.gov, diff-serv@BayNetworks.COM, ecn-interest@research.att.com, red-impl@lbl.gov, jis@MIT.EDU, mleech@nortel.ca In-Reply-To: from "Steve Deering" at Jan 27, 99 09:56:03 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > Gee, Steve, you oughta have a job in marketing. "Transport-friendly ESP" > sounds great, compared to, say, "layer-violation-abetting ESP". Regular > ol' ESP is plenty friendly to the transport layer, just not to those who > want to snoop on or muck with the transport layer's headers in transit. > > Steve although the above might not sound very "Steve-friendly":-), I somehow share the concern with opening up transport fields. So rather than taking the necessity as given (which I know has been stated/discussed many times), could some more informed parties help briefly re-iterate the needs for making ESP *more* transport-friendliness (than what it is now)? I remember hearing some sound reasons at the last TSV meeting but can't recall them all. If we see the list of reasons, then either Mr. Deering could be convinced, or maybe the list of reasons indeed deserves a revisit. Lixia From owner-ipsec@portal.ex.tis.com Thu Jan 28 07:47:01 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA00632; Thu, 28 Jan 1999 07:47:00 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA18306 for ipsec-outgoing; Thu, 28 Jan 1999 08:07:46 -0500 (EST) Message-Id: To: Steve Bellovin , ipsec@tis.com cc: Steve Deering , end2end-interest@isi.edu, tsv@ee.lbl.gov, diff-serv@BayNetworks.COM, ecn-interest@research.att.com, red-impl@lbl.gov, jis@MIT.EDU, mleech@nortel.ca Subject: Re: transport-friendly ESP In-reply-to: Your message of "Wed, 27 Jan 1999 21:56:03 PST." Date: Thu, 28 Jan 1999 07:44:27 -0500 From: "Mike O'Dell" Sender: owner-ipsec@ex.tis.com Precedence: bulk why isn't the answer "just use TLS"??? a requirements doc which did a "compare and contrast" analysis would be interesting reading. if we had a nickel's worth of session layer in the APIs, this would be easy to insert even for apps which "don't know nothin'". moreover, a flyweight session mechanism would solve a bunch of other problems as well which people are addressing by inventing a zillion different new flat tires. so the recurring decision is... fix the architecture? hack yet more ugly cruft? fix the architecture? hack yet more ugly cruft? fix the architecture? hack yet more ugly cruft? to the casual observer, it sure seems like the second alternative has become "The DOH! of the IETF" -mo From owner-ipsec@portal.ex.tis.com Thu Jan 28 07:48:39 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA00663; Thu, 28 Jan 1999 07:48:39 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA18271 for ipsec-outgoing; Thu, 28 Jan 1999 08:05:43 -0500 (EST) X-Sender: deering@postoffice Message-Id: In-Reply-To: <199901280234.VAA03373@smb.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Jan 1999 21:56:03 -0800 To: Steve Bellovin From: Steve Deering Subject: Re: transport-friendly ESP Cc: ipsec@tis.com, end2end-interest@isi.edu, tsv@ee.lbl.gov, diff-serv@BayNetworks.COM, ecn-interest@research.att.com, red-impl@lbl.gov, jis@MIT.EDU, mleech@nortel.ca Sender: owner-ipsec@ex.tis.com Precedence: bulk Gee, Steve, you oughta have a job in marketing. "Transport-friendly ESP" sounds great, compared to, say, "layer-violation-abetting ESP". Regular ol' ESP is plenty friendly to the transport layer, just not to those who want to snoop on or muck with the transport layer's headers in transit. Steve From owner-ipsec@portal.ex.tis.com Thu Jan 28 08:13:10 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA00923; Thu, 28 Jan 1999 08:13:09 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA18444 for ipsec-outgoing; Thu, 28 Jan 1999 08:33:26 -0500 (EST) Message-Id: <3.0.3.32.19990128085207.00977100@shultz.argon.com> X-Sender: kasten@shultz.argon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 28 Jan 1999 08:52:07 -0500 To: Alex Alten , Steve Bellovin , ipsec@tis.com, end2end-interest@isi.edu, tsv@ee.lbl.gov, diff-serv@BayNetworks.COM, ecn-interest@research.att.com, red-impl@lbl.gov From: Frank Kastenholz Subject: Re: transport-friendly ESP Cc: jis@MIT.EDU, mleech@nortel.ca In-Reply-To: <3.0.3.32.19990127200721.00b553e0@mail> References: <199901280234.VAA03373@smb.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 08:07 PM 1/27/99 -0800, Alex Alten wrote: >Wouldn't >it make more sense to let ESP secure per hop IP links? No, No, No, and I say again, No. You don't want to have to distribute that keying information to routers that you may not trust. You don't want to have high speed-silicon-based-lifeforms in the core of the Internet have to grok the latest-encryption-algorithm-du-jour, process entire packets with said algorithm (including looking up more stuff to determine _which_ key to use) and have to be updated with new hardware every time a hyperadenoidal teenager cracks the l.e.a.d.j. Frank Kastenholz Silicon-Based-Lifeform-Foozler Argon Networks From owner-ipsec@portal.ex.tis.com Thu Jan 28 08:14:30 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA00940; Thu, 28 Jan 1999 08:14:30 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA18378 for ipsec-outgoing; Thu, 28 Jan 1999 08:24:29 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF77571B@exchange> From: Tim Jenkins To: Tero Kivinen Cc: "'ipsec@tis.com'" Subject: RE: New IPSec Monitoring MIB draft Date: Thu, 28 Jan 1999 08:45:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@ssh.fi] > Sent: Wednesday, January 27, 1999 1:11 PM > To: Tim Jenkins > Cc: 'ipsec@tis.com' > Subject: RE: New IPSec Monitoring MIB draft > > > Tim Jenkins writes: > > A typo shows in the URL. Use the line above it to change it to > > The URL is > . > > Some comments about the draft: > > There doesn't seem to be any way to identify what ISAKMP SA (phase 1) > was used to create IPSec SA (phase 2). There is no index from the > IpsecProtSuiteEntry to the IpsecIkeSaEntry. I think there should be a > way to find the Phase 1 SA based on the Phase 2 SA, so users can find > for example the certificate and the identities used to create that > IPSec SA. Not directly. The reason for that is that phase 2 lifetimes are independent of phase 1 lifetimes. If the phase 1 SA that created a particular phase 2 SA expires before the phase 2 SA, where do you point the phase 2 SA? The indirect way is to take the 'ipsecProtSuiteLocalAddress' and 'ipsecProtSuiteRemoteAddress' values from the protection suite entry of interest, and do a search in the 'ipsecIkeSaTable' using the values 'ipsecIkeSaLocalIpAddress' and 'ipsecIkeSaPeerIpAddress', since that's where the protection suite pairs (inbound and outbound) go to and come from. Yes, it's ugly. That's why I had the concept of a phase 1 control channel in the previous MIB document stream. > > > -- protection suite selectors > > ipsecProtSuiteLocalId OCTET STRING, > > ipsecProtSuiteLocalIdType Unsigned32, > > ipsecProtSuiteRemoteId OCTET STRING, > > ipsecProtSuiteRemoteIdType Unsigned32, > > ipsecProtSuiteProtocol Integer32, > > I think the ISAKMP doesn't restrict the protocol to be same in both > local and remote id, but it really doesn't make sence to have them > different. Interesting point. In this case though, the inbound and outbound protection suites would then require separate entries, and it would the same as two asymmetric uses of the table, as discussed in the document. However, it makes me think that the definition of the source and destination ports needs to be redone. > > > -- creation mechanism > > ipsecProtSuiteDifHelGroupDesc Integer32, > > ipsecProtSuiteDifHelGroupType Integer32, > > ipsecProtSuitePFS TruthValue, > > Do we really need the PFS flag? If we have > ipsecProtSuiteDifHelGroupDesc that is different from zero then we have > PFS, otherwise we do not have it. I would leave it out completely, > because it is just duplication of the data. Yes, that sounds right. > > > -- expiration limits > > ipsecProtSuiteCreationTime DateAndTime, > > ipsecProtSuiteTimeLimit OCTET STRING, -- > sec., 0 if none > > ipsecProtSuiteTrafficLimit OCTET STRING, -- 0 if none > > ipsecProtSuiteInTrafficCount OCTET STRING, > > ipsecProtSuiteOutTrafficCount OCTET STRING, > > Why octet string. I know that those can be variable length, but I > think Counter64 or similar is enough for them. The main reason was to make it the same as the attribute used. You make a good point below about the size, though, if it is a basic attribute format. > > > ipsecProtSuiteTimeLimit OBJECT-TYPE > > SYNTAX OCTET STRING (SIZE (4..255)) > > ::= { ipsecProtSuiteEntry 27 } > > Are they ascii representation of the number or just binary value of > the number (I assume binary)? If they are binary values then the > minimum size should be 2, because if those lifetimes are expressed as > basic encoding then their length is 2 bytes. > Good catches; I'll clean these up. I'll also add some DISPLAY-HINT clauses to assist in presentation. > > > ipsecIkeSaPFS OBJECT-TYPE > > SYNTAX TruthValue > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "A value that indicates that perfect forward > secrecy is > > used for all IPSec SAs created by this IKE SA." > > ::= { ipsecIkeSaEntry 24 } > > This is a policy information, that cannot be found from anywhere in > the packets in the wire. If this MIB tries to remove all policy > information it should remove this one too. Okay. Consider it removed. > > > ipsecIkeSaEncAlg - Encryption Algorithm > > DES40-CBC 65001 > > ipsecTunnelEspEncAlg > > ESP_DES40 249 > > Again. Do we need the Appendix A at all? John Shriver has volunteered to write a MIB that will allow the display by SNMP browsers of the meanings of all the integer values used. Its use will make Appendix A unnecessary. > > Anyways it looks quite good now... Thanks. At least it appears that we're discussing small things, rather than the entire architecture. > -- > kivinen@iki.fi Work : +358-9-4354 3218 > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > From owner-ipsec@portal.ex.tis.com Thu Jan 28 10:45:56 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA02380; Thu, 28 Jan 1999 10:45:55 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA19111 for ipsec-outgoing; Thu, 28 Jan 1999 10:32:30 -0500 (EST) From: dbastien@galea.com X-Lotus-FromDomain: GALEA To: ipsec@tis.com Message-ID: <85256707.00571E68.00@gotlib.galea.com> Date: Thu, 28 Jan 1999 10:52:11 -0500 Subject: Legal claims on encryption and authentication algorithm Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, While reading RFC 1321, I noted that if we use MD5, we must state that it was developped by RSA Data Security, Inc. We use other encryption and authentication algorithms. Is there any legal claims (copyrights, patents, etc.) tied to the following algorithms? - Blowfish - DES - 3DES - SHA-1 Thank you From owner-ipsec@portal.ex.tis.com Thu Jan 28 11:14:08 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA02638; Thu, 28 Jan 1999 11:14:07 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA19342 for ipsec-outgoing; Thu, 28 Jan 1999 11:11:31 -0500 (EST) Message-Id: <199901281629.IAA05100@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: dharkins owned process doing -bs X-Authentication-Warning: dharkins-ss20.cisco.com: dharkins@localhost didn't use HELO protocol To: "Mike O'Dell" cc: Steve Bellovin , ipsec@tis.com, Steve Deering , end2end-interest@isi.edu, tsv@ee.lbl.gov, diff-serv@BayNetworks.COM, ecn-interest@research.att.com, red-impl@lbl.gov, jis@MIT.EDU, mleech@nortel.ca Subject: Re: transport-friendly ESP In-reply-to: Your message of "Thu, 28 Jan 1999 07:44:27 EST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5098.917540960.1@cisco.com> Date: Thu, 28 Jan 1999 08:29:20 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Because TLS is TCP-only and there's lots of stuff that goes on top of UDP. VoIP is a prime reason why not to use TLS (multicast is another) and a good reason why you'd want some sort of snooping/layer-violation. VoIP needs a higher quality of service than most anything else and service providers usually don't let you just set the TOS bits on packets you inject into their network. Dan. On Thu, 28 Jan 1999 07:44:27 EST you wrote > > why isn't the answer "just use TLS"??? > > a requirements doc which did a "compare and contrast" > analysis would be interesting reading. > > > > if we had a nickel's worth of session layer in the APIs, > this would be easy to insert even for apps which "don't > know nothin'". moreover, a flyweight session mechanism > would solve a bunch of other problems as well which people > are addressing by inventing a zillion different new flat > tires. > > so the recurring decision is... > > fix the architecture? hack yet more ugly cruft? > fix the architecture? hack yet more ugly cruft? > fix the architecture? hack yet more ugly cruft? > > to the casual observer, it sure seems like the > second alternative has become > > "The DOH! of the IETF" > > -mo > > > > From owner-ipsec@portal.ex.tis.com Thu Jan 28 11:19:27 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA02692; Thu, 28 Jan 1999 11:19:26 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA19156 for ipsec-outgoing; Thu, 28 Jan 1999 10:41:28 -0500 (EST) Message-Id: <3.0.32.19990128104213.00894cec@bl-mail1.corpeast.baynetworks.com> X-Sender: ndoraswa_pop@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 28 Jan 1999 10:42:14 -0500 To: Frank Kastenholz , Alex Alten , Steve Bellovin , ipsec@tis.com, end2end-interest@isi.edu, tsv@ee.lbl.gov, diff-serv@BayNetworks.COM, ecn-interest@research.att.com, red-impl@lbl.gov From: Naganand Doraswamy Subject: Re: transport-friendly ESP Cc: jis@MIT.EDU, mleech@nortel.ca Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 08:52 AM 1/28/99 -0500, Frank Kastenholz wrote: >At 08:07 PM 1/27/99 -0800, Alex Alten wrote: > >>Wouldn't >>it make more sense to let ESP secure per hop IP links? > I completly agree with Frank. Doing per hop decryption/encyrption should not even be an option. --Naganand ----------------------------------------------------------------- Naganand Doraswamy (978)916-1323 (O) Internet Core Routers (978)916-0620 (Fax) 3 Federal St, Mail Stop BL3-03 Billerica, MA 01821 From owner-ipsec@portal.ex.tis.com Thu Jan 28 11:32:55 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA02831; Thu, 28 Jan 1999 11:32:55 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA19413 for ipsec-outgoing; Thu, 28 Jan 1999 11:25:32 -0500 (EST) Message-Id: <199901281645.LAA06988@smb.research.att.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Daniel Harkins Subject: Re: transport-friendly ESP Cc: "Mike O'Dell" , ipsec@tis.com, Steve Deering , end2end-interest@isi.edu, tsv@ee.lbl.gov, diff-serv@BayNetworks.COM, ecn-interest@research.att.com, red-impl@lbl.gov, jis@MIT.EDU, mleech@nortel.ca Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 28 Jan 1999 11:45:32 -0500 From: "Steven M. Bellovin" Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks -- let's have this discussion on the tf-esp mailing list -- this message went to far too many places for this sort of argument. Whether or not we need this facility is certainly worth discussing, but I suspect I'm not the only one to see three or four copies of every reply... From owner-ipsec@portal.ex.tis.com Thu Jan 28 12:14:56 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA03447; Thu, 28 Jan 1999 12:14:56 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA19573 for ipsec-outgoing; Thu, 28 Jan 1999 12:11:31 -0500 (EST) Date: Thu, 28 Jan 1999 12:31:34 -0500 Message-Id: <199901281731.MAA06483@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: tjenkins@TimeStep.com Cc: ipsec@tis.com Subject: Some more IPSEC MIB comments X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk Tim, I'll second Tero's comment that the current draft generally looks good. And I also have some comments on a few items. Key length objects: I would prefer to show the actual key length even when it is implied by the transform. Yes, that's not how it's encoded in the protocol. I don't think that's relevant. Protocol encoding is done for convenience in processing, MIB objects are designed for ease of management. Often they match but there is no reason why they should. Time limit, traffic limit, traffic count: you showed those as octet strings. You mentioned in your reply to Tero that's because they are encoded that way. (Wow, bizarre.) But it is really nasty to use octet strings to show integer data because it will display strangely, and you might even get into byte order issues, and so on. Clearly these parameters are integers (unsigned, actually). So the MIB data type should be integer, or unsigned integer, or, in the case of traffic count, Counter. Traffic count and traffic limit: it might be easier to read these if they showed the byte counts rather than the Kbyte counts. Inbound and outbound traffic: are these the uncompressed byte counts or the compressed counts? (For traffic limit related count, it's compressed bytes, though it might be good to say that explicitly. For the user level traffic counts it could be either.) IKE SA peer cert issuer: you might mention exactly how this field is encoded. I would guess it's the DER encoding of the X.50x DN of the issuer. Ipsec total traffic (page 28) -- why is this in Kbytes? Counters normally are in bytes, and when you use Counter64 as the data type (great!) there's no need to go to Kbytes. Ipsec other receive errors (page 30) -- not mentioned in the description, but presumably unknown SPI errors are also errors that are not counted as "other". paul From owner-ipsec@portal.ex.tis.com Thu Jan 28 12:16:32 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA03491; Thu, 28 Jan 1999 12:16:32 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA19488 for ipsec-outgoing; Thu, 28 Jan 1999 11:54:32 -0500 (EST) From: "Kalyan Chakravarthy Bade" To: Subject: Questions on CERT payload Date: Thu, 28 Jan 1999 19:08:12 +0530 Message-ID: <01be4ac3$739252c0$320110ac@garfield.roc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Can anyone help me in clarifying some of the basic doubts in IKE (authentication with digiatal signatures). 1. What is the format in which certificates are exchanged in a bake-off ? 2. Can we assume that if the CERT payload is not sent, the certificates are exchanged in a out of band mechanism in a bake-off ? 3. If the chain of certificates are to be sent, will they come as a single CERT payload or multiple CERT payloads ? Is the order of the chain fixed or the CERTS can come in any order ? thanks in advance -kalyan. From owner-ipsec@portal.ex.tis.com Thu Jan 28 12:47:34 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA03862; Thu, 28 Jan 1999 12:47:34 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA19590 for ipsec-outgoing; Thu, 28 Jan 1999 12:18:32 -0500 (EST) Message-ID: <6236E58EC451D1119E80006097040ED9B0553E@lobester.rsa.com> From: Bob Baldwin To: ipsec@tis.com Subject: RE: Legal claims on encryption and authentication algorithm Date: Thu, 28 Jan 1999 09:42:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk In case this group has not heard, RSA Data Security has clarified that there is no charge for using the DESX algorithm, which is described in draft-simpson-desx-02.txt. --Bob Baldwin Technical Director RSA Data Security -----Original Message----- From: dbastien@galea.com [mailto:dbastien@galea.com] Sent: Thursday, January 28, 1999 7:52 AM To: ipsec@tis.com Subject: Legal claims on encryption and authentication algorithm Hello, While reading RFC 1321, I noted that if we use MD5, we must state that it was developped by RSA Data Security, Inc. We use other encryption and authentication algorithms. Is there any legal claims (copyrights, patents, etc.) tied to the following algorithms? - Blowfish - DES - 3DES - SHA-1 Thank you From owner-ipsec@portal.ex.tis.com Thu Jan 28 13:59:44 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA04398; Thu, 28 Jan 1999 13:59:43 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA19854 for ipsec-outgoing; Thu, 28 Jan 1999 13:45:32 -0500 (EST) Date: Thu, 28 Jan 1999 14:04:49 -0500 Message-Id: <199901281904.OAA07248@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: dbastien@galea.com Cc: ipsec@tis.com Subject: Re: Legal claims on encryption and authentication algorithm References: <85256707.00571E68.00@gotlib.galea.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "dbastien" == dbastien writes: dbastien> Hello, While reading RFC 1321, I noted that if we use MD5, dbastien> we must state that it was developped by RSA Data Security, dbastien> Inc. FWIW, it seems to say that you have to acknowledge if you use the sample code given in the appendix. I didn't see anything requiring an ack if you use the hash but not the sample code. paul From owner-ipsec@portal.ex.tis.com Thu Jan 28 15:44:38 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA05483; Thu, 28 Jan 1999 15:44:38 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA20202 for ipsec-outgoing; Thu, 28 Jan 1999 15:29:31 -0500 (EST) Message-ID: <36B0967E.3DBF11C9@hursley.ibm.com> Date: Thu, 28 Jan 1999 16:55:26 +0000 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Steve Bellovin CC: ipsec@tis.com, end2end-interest@isi.edu, tsv@ee.lbl.gov, diff-serv@BayNetworks.COM, ecn-interest@research.att.com, red-impl@lbl.gov, jis@MIT.EDU, mleech@nortel.ca Subject: Re: transport-friendly ESP - use the dedicated list! References: <199901280234.VAA03373@smb.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I would really appreciate it if folks could take this thread to the list Steve has set up, rather than discuss it on 6 lists in parallel. Thanks Brian > I've set up a new mailing list, tf-esp@research.att.com, to discuss the > design of a transport-friendly variant of ESP (a core piece of IPSEC). > Subscription is via majordomo@research.att.com. > From owner-ipsec@portal.ex.tis.com Thu Jan 28 16:07:38 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA05734; Thu, 28 Jan 1999 16:07:37 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA20298 for ipsec-outgoing; Thu, 28 Jan 1999 16:10:30 -0500 (EST) Message-ID: <5F6AA2CAD4A4D1119C3D00A0C99D6AC6B83CBE@ca-exchange2.nai.com> From: "Glawitsch, Gregor" To: "'ipsec@tis.com'" Subject: RE: Legal claims on encryption and authentication algorithm Date: Thu, 28 Jan 1999 13:33:42 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk The DES patent is owned by IBM, but IBM has waived the license fee, i.e. anyone can use DES free of charge. The DES patent is **not** owned by RSA Data Security. On a sidenote, the patent for the RSA public key algorithm will expire in how many months? 11? 13? :-))) Greg Glawitsch Network Associates, Inc. > In case this group has not heard, RSA Data Security has > clarified that there is no charge for using the DESX algorithm, > which is described in draft-simpson-desx-02.txt. > --Bob Baldwin > Technical Director > RSA Data Security > > -----Original Message----- > From: dbastien@galea.com [mailto:dbastien@galea.com] > Sent: Thursday, January 28, 1999 7:52 AM > To: ipsec@tis.com > Subject: Legal claims on encryption and authentication algorithm > > > > Hello, > While reading RFC 1321, I noted that if we use MD5, we must state > that > it was developped by RSA Data Security, Inc. > We use other encryption and authentication algorithms. Is there any > legal claims (copyrights, patents, etc.) tied to the following algorithms? > - Blowfish > - DES > - 3DES > - SHA-1 > Thank you From owner-ipsec@portal.ex.tis.com Thu Jan 28 16:09:47 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA05787; Thu, 28 Jan 1999 16:09:46 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA20322 for ipsec-outgoing; Thu, 28 Jan 1999 16:18:30 -0500 (EST) Message-ID: <91AE69321799D211AEC500105A9C469605D865@sothmxs05.entrust.com> From: Greg Carter To: ipsec@tis.com, "'Kalyan Chakravarthy Bade'" Subject: RE: Questions on CERT payload Date: Thu, 28 Jan 1999 16:33:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk > ---------- > From: Kalyan Chakravarthy Bade[SMTP:kalyan@trinc.com] > Sent: Thursday, January 28, 1999 8:38 AM > To: ipsec@tis.com > Subject: Questions on CERT payload > > Hi > > Can anyone help me in clarifying some of the basic doubts > in IKE (authentication with digiatal signatures). > > 1. What is the format in which certificates are exchanged in > a bake-off ? > HI, Within IKE it is binary ASN.1 DER. If you mean during the bakeoff event when a vendor wants to get a certificate from a CA then the certificate request and response can be in any format (binary, base64, ascii hex etc..) that the CA and vendor support. The most common is base - 64, however most CA's will accept either in the request. > 2. Can we assume that if the CERT payload is not sent, > the certificates are exchanged in a out of band mechanism > in a bake-off ? > If you don't request one in IKE (using the Cert Request payload) and the peer doesn't request one, then yes. Technically you don't NEED certificates to do IKE signature mode. > 3. If the chain of certificates are to be sent, will they come as > a single CERT payload or multiple CERT payloads ? Is the > order of the chain fixed or the CERTS can come in any order ? > As multiple CERT payloads, or if you request a single CERT payload with type set to PKCS-7. It would be best to program that they come in any order, however that could be clarified in the future. Bye > ---- > Greg Carter, Entrust Technologies > greg.carter@entrust.com From owner-ipsec@portal.ex.tis.com Thu Jan 28 16:43:05 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA06482; Thu, 28 Jan 1999 16:43:04 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA20341 for ipsec-outgoing; Thu, 28 Jan 1999 16:27:30 -0500 (EST) Message-Id: <199901282147.QAA11398@postal.research.att.com> To: "Glawitsch, Gregor" Cc: "'ipsec@tis.com'" Subject: Re: Legal claims on encryption and authentication algorithm Date: Thu, 28 Jan 1999 16:47:26 -0500 From: Steve Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <5F6AA2CAD4A4D1119C3D00A0C99D6AC6B83CBE@ca-exchange2.nai.com>, "Glaw itsch, Gregor" writes: > The DES patent is owned by IBM, but IBM has waived the license > fee, i.e. anyone can use DES free of charge. And it expired some years ago. > > The DES patent is **not** owned by RSA Data Security. > > On a sidenote, the patent for the RSA public key algorithm will expire > in how many months? 11? 13? :-))) Early September, 2000, as I recall. From owner-ipsec@portal.ex.tis.com Thu Jan 28 20:40:46 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA22527; Thu, 28 Jan 1999 20:40:46 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id UAA20844 for ipsec-outgoing; Thu, 28 Jan 1999 20:20:30 -0500 (EST) X-Lotus-FromDomain: CERTICOM From: "Paul Lambert" To: Steve Bellovin , "'ipsec@tis.com'" Message-ID: <88256708.0006AA1B.01@domino2.certicom.com> Date: Thu, 28 Jan 1999 17:33:41 -0800 Subject: Re: Legal claims on encryption and authentication algorithm Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@ex.tis.com Precedence: bulk >> On a sidenote, the patent for the RSA public key algorithm will expire >> in how many months? 11? 13? :-))) > >Early September, 2000, as I recall. The RSA patent expires Wednesday September 20, 2000 to be exact. Please send me a note if you're interested in joining the steering committe that will organize the going away party! Paul From owner-ipsec@portal.ex.tis.com Thu Jan 28 21:26:15 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA23696; Thu, 28 Jan 1999 21:26:14 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id VAA21012 for ipsec-outgoing; Thu, 28 Jan 1999 21:32:30 -0500 (EST) Message-ID: <36B12287.4CDB9F8@sympatico.ca> Date: Thu, 28 Jan 1999 21:52:55 -0500 From: Sandy Harris Organization: Crash Test Dummies on the Information Highway X-Mailer: Mozilla 4.5 [en]C-SYMPA (Win95; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "'ipsec@tis.com'" Subject: Re: Legal claims on encryption and authentication algorithm References: <5F6AA2CAD4A4D1119C3D00A0C99D6AC6B83CBE@ca-exchange2.nai.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk "Glawitsch, Gregor" wrote: > > The DES patent is owned by IBM, but IBM has waived the license > fee, i.e. anyone can use DES free of charge. > > The DES patent is **not** owned by RSA Data Security. Correct, but he was discussing DESX. > > In case this group has not heard, RSA Data Security has > > clarified that there is no charge for using the DESX algorithm, > > which is described in draft-simpson-desx-02.txt. > > --Bob Baldwin > > Technical Director > > RSA Data Security DESX was invented by RSA's Rivest, if I recall correctly, so RSA (could? do?) claim rights to it, subject I suppose to negotiation with IBM who own DES. -- "The real aim of current [cryptography] policy is to ensure the continued effectiveness of US information warfare assets against individuals, businesses and governments in Europe and elsewhere" Ross Anderson, Cambridge University From owner-ipsec@portal.ex.tis.com Fri Jan 29 08:41:01 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA13350; Fri, 29 Jan 1999 08:41:01 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id HAA22370 for ipsec-outgoing; Fri, 29 Jan 1999 07:50:29 -0500 (EST) Message-Id: <199901291309.IAA16941@newman.gte.com> X-Sender: sjj0@pophost.gte.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 29 Jan 1999 08:08:40 -0500 To: "Glawitsch, Gregor" From: Stuart Jacobs Subject: RE: Legal claims on encryption and authentication algorithm Cc: "'ipsec@tis.com'" In-Reply-To: <5F6AA2CAD4A4D1119C3D00A0C99D6AC6B83CBE@ca-exchange2.nai.co m> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk The RSA patent expires in September of 2000 At 1/28/99 01:33 PM, you wrote: >The DES patent is owned by IBM, but IBM has waived the license >fee, i.e. anyone can use DES free of charge. > >The DES patent is **not** owned by RSA Data Security. > >On a sidenote, the patent for the RSA public key algorithm will expire >in how many months? 11? 13? :-))) > >Greg Glawitsch >Network Associates, Inc. > >> In case this group has not heard, RSA Data Security has >> clarified that there is no charge for using the DESX algorithm, >> which is described in draft-simpson-desx-02.txt. >> --Bob Baldwin >> Technical Director >> RSA Data Security >> >> -----Original Message----- >> From: dbastien@galea.com [mailto:dbastien@galea.com] >> Sent: Thursday, January 28, 1999 7:52 AM >> To: ipsec@tis.com >> Subject: Legal claims on encryption and authentication algorithm >> >> >> >> Hello, >> While reading RFC 1321, I noted that if we use MD5, we must state >> that >> it was developped by RSA Data Security, Inc. >> We use other encryption and authentication algorithms. Is there any >> legal claims (copyrights, patents, etc.) tied to the following algorithms? >> - Blowfish >> - DES >> - 3DES >> - SHA-1 >> Thank you > ========================== Stuart Jacobs CISSP Network Security GTE Laboratories 40 Sylvan Road Waltham, MA 02454 USA telephone: (781) 466-3076 fax: (781) 466-2838 ========================== From owner-ipsec@portal.ex.tis.com Fri Jan 29 09:07:25 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA13682; Fri, 29 Jan 1999 09:07:25 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA22620 for ipsec-outgoing; Fri, 29 Jan 1999 08:46:28 -0500 (EST) Message-Id: <199901290014.QAA23460@mailman.cisco.com> X-Sender: anfreema@sj-email X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Wed, 28 Apr 1999 16:20:57 -0700 To: ipsec@tis.com, ietf-ppp@merit.edu From: Anita Freeman Subject: April IPSec and PPP Interoperability Workshop Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Greetings, We are preparing to sign a hotel contract for the next IPSec and PPP Interoperability Workshop for the week of April 19-23, 1999, in Santa Barbara, CA, with arrival and set up on April 18. It has been brought to our attention there is an Internet Security Conference taking place April 19-22, 1999, in San Jose, CA. The details are listed below. This email is sent for the participants of the interoperability workshop. Will this conference present a conflict in your company's resources to attend the IPSec and PPP interoperability workshop? Please respond at your earliest opportunity as this is the only week in April the hotel accommodations are available in Santa Barbara and we would like to complete our contract negotiations promptly if this is a viable week for the workshop. Thank you, Anita Freeman ------------------------------------ For Immediate Release Media Contact Paul Kent Mactivity, Inc (408) 354-2500 paul@mactivity.com The Internet Security Conference Making the Internet a Safer Place for Corporate Information Assets. Los Gatos, CA Dec 17, 1998 - Internet computing has become a critical component of corporate computing, but threats to electronic assets and information integrity are real, and information and communications privacy are difficult to achieve. The second presentation of The Internet Security Conference, to be held April 19-22 at the Fairmont Hotel in San Jose, California, promises to provide a wealth of solutions for the IT manager looking to find his way through the maze of threats that face the Internet-enabled corporation. The Internet Security Conference (TISC) presents a comprehensive curriculum on secure computing. Attendees can choose from sessions on anti-virus strategies, virtual private network deployment, IPSEC and IP v6 issues, secure mail and messaging options, secure ecommerce, databases and multicast security considerations. Eleven full day workshops, 30 conference sessions and two half-day seminars will be presented. A world reknown faculty of Internet security scientists, researchers and educators will conduct the sessions. Key presenters include: - Dr. Stephen Kent, Chief Scientist, Information Security, BBN Technologies - Marcus Ranum, CEO and Founder, Network Flight Recorder & author of several major Internet firewall products including DEC SEAL, TIS Gauntlet and TIS Internet Firewall Toolkit - Fred Avolio, independent consultant specializing in Internet security & former product manager for TIS Gauntlet Internet Firewall - Dr. Radia Perlman, Distinguished Engineer, Sun Microsystems, co- author of"Network Security: Private Communication in a Public World" - Rik Farrow, Internet Security consultant and trainer & author of "UNIX System Security" - Charlie Kaufman, Security Architect for Lotus Notes, IBM & co- author of "Network Security: Private Communication in a Public World" - Phil Carden, Managing Consultant, Renaissance Worldwide & author, "Internet Security for Windows NT" The faculty is complemented by fifty of the industry's leading security practitioners, including Char Sample, Tina Darmohray, John Rochlis, Daniel Geer, John Pescatore, Ian Poynter, Ray Kaplan and Joseph Saul. The conference is hosted by Dave Piscitello, president of Core Competence, a 20 year veteran of the Internet technical community and conference chairperson of Networld+Interop. "The purpose of The Internet Security Conference is to expose corporate computing professionals who have an urgent 'need to know' to the folks who designed or contributed to some of the most significant security technologies in the world," explains Piscitello. "I designed this to be a conference I would want to attend, one with a program so intensely interesting I'd have difficulty deciding what to attend myself." Industry publication Network Computing Magazine returns as the event's media sponsor. "Security is an important issue to the market and our readers," said Jill Thiry Bowers, publisher of Network Computing. "Because of our editorial coverage of Internet Security the past few years, Dave chose to partner with our editors to create compelling content for the conference. We also look forward to extending our Real World Labs (r) into the TISC Interoperability Lab to demonstrate enterprise-tested solutions to attendees." A unique feature of TISC is the Interoperabilty Lab - a working computer lab that demonstrates how an organization can combine solutions to create a secure environment. The TISC Interoperability Lab will feature interoperability demonstrations and unique presentations of policy management, intrusion detection and monitoring, virtual private networking and ethical hacking. Consultants from Ernst and Young will attempt to hack into the Lab while intrusion detection and monitoring experts attempt to catch them in a kind of high tech war game that attendees can observe. "Our Interoperability Lab is a throw-back to the days when technical staff demonstrated products at trade shows," explains Piscitello, "I view it as an extension of our education program. I want attendees to learn about security from experts in workshops and symposium sessions, then see it put to work in our Lab." The Internet Security Conference is sponsored by the key organizations driving the security industry. Corporate sponsorship is provided by Network Computing, Ernst and Young, Compatible Systems, Checkpoint Software, Microsoft, RSA Data Security, Aventail Corporation, InternetWeek, Internet Devices, Netscreen, enCommerce, Xedia, TimeStep, Exodus Communications, Xcert, Radguard, Network Flight Recorder and RedCreek with more sponsors being announced each week. Covad Communications Company is providing DSL Internet access at the conference. For more information contact (408) 354-2500 or browse http://tisc.corecom.com The Internet Security Conference is co-produced by Core Competence and Mactivity, Inc. Core Competence is a full service internetworking, fast packet and network management consulting firm located in Dresher, PA. Mactivity, located in Los Gatos, CA produces some of the most influential technology conferences in the high-tech industry including Voice on the Net, Loop'98, The Internet Service Providers Forum, Java Business Expo, Macworld Expo, Interop DotCom and the Mactivity conference series. Network Computing is the premier technology solutions magazine driving IT purchasing decisions. Every two weeks it delivers enterprise-tested technology solutions from its unique Real-World Labs to 220,000 information-technology buyers in print and online (http://www.networkcomputing.com). In addition, the publication consistently has the largest average-issue audience among all networking publications, according to Simmons and IntelliQuest. Network Computing received the 1997 Maggie Award for Best Computer & Telecommunications (trade) Publication. CMP Media Inc. (Nasdaq: CMPX) is the leading high-tech media company providing essential information and marketing services to the entire technology spectrum: the builders, sellers and users of technology worldwide. With its portfolio of newspapers, magazines, custom publishing, Internet products, research, consulting and conferences, CMP is uniquely positioned to offer marketers comprehensive, integrated solutions tailored to meet their individual needs. Online editions of the company's print publications, along with products and services created exclusively for the Internet, can be found on CMPnet at http://www.CMPnet.com. NSTL, the company's independent testing lab and consulting organization, serves government, corporate and technology vendor clients around the world. From owner-ipsec@portal.ex.tis.com Fri Jan 29 13:43:26 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA16547; Fri, 29 Jan 1999 13:43:26 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA23698 for ipsec-outgoing; Fri, 29 Jan 1999 13:17:30 -0500 (EST) Date: Fri, 29 Jan 1999 20:37:42 +0200 (EET) Message-Id: <199901291837.UAA04775@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Tim Jenkins Cc: "'ipsec@tis.com'" Subject: RE: New IPSec Monitoring MIB draft In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDF77571B@exchange> References: <319A1C5F94C8D11192DE00805FBBADDF77571B@exchange> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 8 min X-Total-Time: 10 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Tim Jenkins writes: > > There doesn't seem to be any way to identify what ISAKMP SA (phase 1) > > was used to create IPSec SA (phase 2). There is no index from the > > IpsecProtSuiteEntry to the IpsecIkeSaEntry. I think there should be a > > way to find the Phase 1 SA based on the Phase 2 SA, so users can find > > for example the certificate and the identities used to create that > > IPSec SA. > Not directly. The reason for that is that phase 2 lifetimes are independent > of phase 1 lifetimes. If the phase 1 SA that created a particular phase 2 SA > expires before the phase 2 SA, where do you point the phase 2 SA? Either keep the old index number (which cannot be reused as long the phase 2 SA is valid), or change it to some special number, meaning that phase 2 SA doesn't not have phase 1 SA. > The indirect way is to take the 'ipsecProtSuiteLocalAddress' and > 'ipsecProtSuiteRemoteAddress' values from the protection suite entry of > interest, and do a search in the 'ipsecIkeSaTable' using the values > 'ipsecIkeSaLocalIpAddress' and 'ipsecIkeSaPeerIpAddress', since that's where > the protection suite pairs (inbound and outbound) go to and come from. And then you can find several phase 1 SA entries having the same local and peer addresses, but having different certificates (and users). In multiuser environment you really need to keep the connection between phase 1 and phase 2 SAs if you want to have any kind of user based authentication. > > > ipsecProtSuiteTimeLimit OCTET STRING, -- > > Why octet string. I know that those can be variable length, but I > > think Counter64 or similar is enough for them. > The main reason was to make it the same as the attribute used. You make a > good point below about the size, though, if it is a basic attribute format. I think the MIBs in general are hard enough, without us adding special encodings of the integers from the another document. I think we should use the MIB way of representing integer numbers, even if we then limit ourselves to 64-bit numbers :-) -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@portal.ex.tis.com Fri Jan 29 14:53:16 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA17117; Fri, 29 Jan 1999 14:53:15 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA24145 for ipsec-outgoing; Fri, 29 Jan 1999 15:06:42 -0500 (EST) To: Lixia Zhang Cc: deering@cisco.com (Steve Deering), smb@research.att.com, ipsec@tis.com, end2end-interest@isi.edu, tsv@ee.lbl.gov, diff-serv@BayNetworks.COM, ecn-interest@research.att.com, red-impl@lbl.gov, jis@MIT.EDU, mleech@nortel.ca Subject: Re: transport-friendly ESP References: <199901280614.WAA17897@aurora.cs.ucla.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 29 Jan 1999 15:26:37 -0500 In-Reply-To: Lixia Zhang's message of "Wed, 27 Jan 1999 22:14:25 -0800 (PST)" Message-ID: <87ww25su4i.fsf@jekyll.piermont.com> Lines: 13 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-ipsec@ex.tis.com Precedence: bulk Lixia Zhang writes: > > Gee, Steve, you oughta have a job in marketing. "Transport-friendly ESP" > > sounds great, compared to, say, "layer-violation-abetting ESP". Regular > > ol' ESP is plenty friendly to the transport layer, just not to those who > > want to snoop on or muck with the transport layer's headers in transit. > > although the above might not sound very "Steve-friendly":-), I somehow > share the concern with opening up transport fields. As do I, even though I'm generally a fan of Steve's. Perry From owner-ipsec@portal.ex.tis.com Fri Jan 29 16:27:19 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA18301; Fri, 29 Jan 1999 16:27:18 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA24572 for ipsec-outgoing; Fri, 29 Jan 1999 16:53:31 -0500 (EST) Message-ID: From: Ricky Charlet To: "'ipsec@tis.com'" , "Tim Jenkins (E-mail)" Subject: RE: New IPSec Monitoring MIB draft Date: Fri, 29 Jan 1999 14:10:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk Howdy () A question about bypass and drop policy... Can the monitoring mib provide stats on how much traffic met with selecorts which shunted the traffic into a bypass or discard rule? I don't see it. ################################### # Ricky Charlet # rcharlet@RedCreek.com # (510) 795-6903 ################################### end Howdy; From owner-ipsec@portal.ex.tis.com Fri Jan 29 16:32:58 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA18332; Fri, 29 Jan 1999 16:32:57 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA24465 for ipsec-outgoing; Fri, 29 Jan 1999 16:31:31 -0500 (EST) Message-ID: From: Ricky Charlet To: "'Tim Jenkins'" , "'ipsec@tis.com'" Subject: RE: New IPSec Monitoring MIB draft Date: Fri, 29 Jan 1999 13:48:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk Howdy () I have some questions about the ipsecProtSuite Table and identities. Suppose that I have an IPSec SA bundle made up of one AH SA and one ESP SA and one Comp SA. This bundle was built as a unit by a single IKE negotiation with a single peer. So now I have in my box one each of: ipsecProtSuiteInboundEspSpi ipsecProtSuiteOutboundEspSpi ipsecProtSuiteInboundAhSpi ipsecProtSuiteOutboundAhSpi ipsecProtSuiteInboundCompCpi ipsecProtSuiteOutboundCompCpi Where ipsecProtSuiteLocalAddress and ~RemoteAddress are the same for all the above. Now I build a query for some statistical value (ex PolicyErrors)of a ProtSuite and get the whole table as ordered by 'index' I expect to get the "total number of inbound packets discarded [...] due to policy errors" which have passes across these THREE SAs since there instantiation (don't sweat counter wraps for this discussion) at one single indexed table entry. But, (and here come my questions) Is there a way to monitor individual SAs? Can I expect an indexed entry for EspSpis with 0 for the AH and Comp Spis/Cpis? Would I then get the total number of inbound packets discarded due to policy errors on just the ESP SA? This seems a little cumbersome to dig into individual SAs and also seems to allow enough ambiguity to muck with inter-vendor consistency. Did/could we consider an approach where we have a table of ESP SAs, a table of AH SAs, a table of Comp SAs and then a table of ProtSuite bundles which refers to appropriate values (or formulas of values) from those first three? Now let me anticipate the question, "What would be the value of measuring individual SAs?" First, I acknowledge that measuring statistics on "protSuites" is very useful! This closly paralles link monitoring which is of highest concern to O&M groups. I certainly believe that protSuite measuring (as opposed to individual SA measuring) will be the most common application for this mib and be the most customer demanded feature (just my gut feeling, not any official survey). But I see three needs for finer grain visibility into IPSec devices. 1. drill down trouble shootin' for finer fault isolation 2. pattern recognition to identify attack profiles 3. device capacity monitoring, so that total number of SAs may be tracked as well as traffic count summations on comp, ESP and AH So, I know this is a BIG SHIFT from the proposal (which has just undergone a BIG SHIFT). Let's talk it out... what do Y'all think? ################################### # Ricky Charlet # rcharlet@RedCreek.com # (510) 795-6903 ################################### end Howdy; From owner-ipsec@portal.ex.tis.com Fri Jan 29 16:47:38 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA18420; Fri, 29 Jan 1999 16:47:37 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA24593 for ipsec-outgoing; Fri, 29 Jan 1999 16:56:31 -0500 (EST) Date: Fri, 29 Jan 1999 17:17:19 -0500 Message-Id: <199901292217.RAA10569@brill.shiva.com> From: John Shriver To: tjenkins@TimeStep.com CC: ipsec@tis.com In-reply-to: <319A1C5F94C8D11192DE00805FBBADDF7750E8@exchange> (message from Tim Jenkins on Tue, 26 Jan 1999 11:05:13 -0500) Subject: Re: New IPSec Monitoring MIB draft Sender: owner-ipsec@ex.tis.com Precedence: bulk OK, now I've had a chance to work on my IPSec DOI textual conventions, I know the MIB well enough to comment on it in structure and in detail. Sorry folks, but it's a BIG message. I've got lots to say here... STRUCTURE ========= The first issue is that this is not, as written an IPSec Monitoring MIB. It is an IKE monitoring MIB. The structure assumes IKE in every grain, despite the notes that you could use it with manual keys. It also completely assumes the IPSec DOI, despite the fact that there have been active proposals for other DOIs (RIP, OSPF). Also, there are already two DOI's, ISAKMP (0), and IPSEC (1). So, we need to be more careful of where we hang this in the MIB tree. There should be a object identifier { ipsec }, but it shouldn't be where this MIB hangs directly on. Instead, this mib should be ikeMonitoring OBJECT IDENTIFIER ::= { ipsec 1 } or something like that. Well, really there should be branches for ipsec, for isakmp, for ike, etc... If you don't get the numbering right up front, you wind up having to throw a lot away later, unmaintainable. LAYERING ======== I think we need to try and be much more careful about our layering. There is a first layer that assumes nothing but IPSec proper. There is a next layer that assumes ISAKMP, but nothing above that. Then there is a layer that assumes IKE with the IPSEC DOI. (Or should we split that too?) This all works fine with the AUGMENTS model of SMIv2. PHASE 1 ======= So, there should be a isakmpSaTable. It would contain, and (in my opinion) be indexed by, the two cookies. As data, it would have only the IPv4/IPv6 address of each peer, the UDP port of each peer, the ISAKMP major version, the ISAKMP minor version, the mode, and the Domain of Interpretation. You can't put in the Protocol-ID, it's within the DOI. So you have: isakmpSaInitiatorCookie OCTET STRING (SIZE (16)) *** index isakmpSaResponderCookie OCTET STRING (SIZE (16)) *** index isakmpSaLocalIpAddress OCTET STRING (SIZE (4 | 16)) isakmpSaLocalUdpPort INTEGER (0..65535) isakmpSaLocalMajorVersion INTEGER (0..15) isakmpSaLocalMinorVersion INTEGER (0..15) isakmpSaRemoteIpAddress OCTET STRING (SIZE (4 | 16)) isakmpSaRemoteUdpPort INTEGER (0..65535) isakmpSaRemoteMajorVersion INTEGER (0..15) isakmpSaRemoteMinorVersion INTEGER (0..15) isakmpSaMode INTEGER { base(1), identityProtection(2), authOnly(3), agressive(4) } isakmpSaDoi Unsigned32 Note that I support all the Phase 1 ISAKMP modes, even though IKE only uses identityProtection(2) and aggressive(4). We need to note that the isakmpSaResponderCookie is 0 when the initiator has sent it's first packet, but no response has been received. As you can see, I still want to index without creating arbitrary indices. But, even if I lose on that issue, the table will have some index, allowing it to be augmented. Augmented tables aren't performance pigs, since the indexing code/hooks/overhead can be shared by all the tables if you like. There is a bit more overhead of skipping those entries that aren't relevant when the augmentation is partial. The first table augmenting this would be ISAKMP SA's using DOI 0 for Phase 1 identification. (Reference sections 3.4 and A.4 of RFC 2408 and section 4 paragraph 8 of RFC 2409.) This would be isakmpSaDoi0Table, partially augmenting isakmpSaTable, having: isakmpSaDoi0LocalIdType INTEGER { ipv4(0), ipv4Subnet(1), ipv6(2), ipv6Subnet(3) } isakmpSaDoi0LocalId OCTET STRING (SIZE (4 | 8 | 16 | 32)) isakmpSaDoi0RemoteIdType INTEGER { ipv4(0), ipv4Subnet(1), ipv6(2), ipv6Subnet(3) } isakmpSaDoi0RemoteId OCTET STRING (SIZE (4 | 8 | 16 | 32)) (Maybe this needs other elements?) The second, and far more commonly used, table augmenting isakmpSaTable would be isakmpSaDoi1Table, having: isakmpSaDoi1LocalIdType INTEGER { reserved(0), idIpv4Addr(1), idFqdn(2), idUserFqdn(3), idIpv4AddrSubnet(4), idIpv6Addr(5), idIpv6AddrSubnet(6), idIpv4AddrRange(7), idIpv6AddrRange(8), idDerAsn1Dn(9), idDerAsn1Gn(10), idKeyId(11) } isakmpSaDoi1LocalId OCTET STRING (SIZE (0..511)) isakmpSaDoi1RemoteIdType INTEGER { reserved(0), idIpv4Addr(1), idFqdn(2), idUserFqdn(3), idIpv4AddrSubnet(4), idIpv6Addr(5), idIpv6AddrSubnet(6), idIpv4AddrRange(7), idIpv6AddrRange(8), idDerAsn1Dn(9), idDerAsn1Gn(10), idKeyId(11) } isakmpSaDoi1RemoteId OCTET STRING (SIZE (0..511)) (You may ask why two tables? Well, the syntax of isakmpSaDoi1LocalIdType is not the same as isakmpSaDoi0LocalIdType. If you want to decode symbolically, you have to have a seperate table for each DOI.) Then we can work our way up to ikePhase1SaTable. This augments isakmpSaTable, since you can use IKE with Phase 1 ID's of DOI 0 or 1. This would have: ikePhase1SaAuthMethod INTEGER ikePhase1SaEncAlg INTEGER ikePhase1SaEncKeyLength INTEGER ikePhase1SaHashAlg INTEGER ikePhase1SaDifHelGroupDesc INTEGER ikePhase1SaDifHelGroupType INTEGER ikePhase1SaInboundOctets Counter64 ikePhase1SaOutboundOctets Counter64 ikePhase1SaInboundPackets Counter32 ikePhase1SaOutboundPackets Counter32 ikePhase1SaProtSuitesCreated Counter32 ikePhase1SaProtSuitesDeleted Counter32 ikePhase1SaCurrentProtSuites Gauge32 -- new... ikePhase1SaDecryptErrors Counter32 ikePhase1SaAuthErrors Counter32 ikePhase1SaOtherRecieveErrors Counter32 ikePhase1SaSendErrors Counter32 Now, this table needs some expansion over the variables that were in the ipsecIkeSaTable. We need the full parameters of the Diffie-Hellman group, since all are negotiable in Phase 1 and Phase 2. So, throw in: ikePhase1SaDifHelGroupPrime OCTET STRING ikePhase1SaDifHelGroupGenOne Integer32 (or must it be OCTET STRING?) ikePhase1SaDifHelGroupGenTwo Integer32 (") ikePhase1SaDifHelGroupCurveA Integer32 (") ikePhase1SaDifHelGroupCurveB Integer32 (") ikePhase1SaDifHelGroupOrder OCTET STRING Then, we have to decide if the MIB is obligated to fill in these values for standard Groups, or whether it is filled on only when the GroupType is 0. Or perhaps it's clearer if we define GroupType to be -1 if non-standard, or have a TruthValue SYNTAX variable incidating non-standard group. As for the SA lifetime variables, I think Counter64 is safe. Really, who is going to use "bignum" math in their SA's to count the lifetime in kbytes? Nobody will accept (or properly implement) a lifetime with a length greater than 8 bytes. For that matter, I think lifetimes in seconds can be limited to 4 bytes, that's 136 years. (68 years if you want to allow for sign bugs.) These are really flaws in the DOI, it doesn't prohibit insane values... Next, I'd rather have a seperate variable for lifetime in kbytes versus lifetime in seconds. Why? Becuase you can then put proper UNITS statements on each. So, we would have: ikePhase1SaLifeType INTEGER { none(0), seconds(1), kilobytes(2) } ikePhase1SaTimeStart DataAndTime ikePhase1SaTimeLimit Counter32 UNITS "Seconds" ikePhase1SaByteLimit Counter64 UNITS "Kilobytes" You might want to make ikePhase1SaTimeStart optional, not all systems may have the facilities to determine DateAndTime. This might raise the issue of wanting to add: ikePhase1SaTimeActive Counter32 UNITS "Seconds" for calendar-challenged implementations. Now we come to another major issue. There is no limit of one Certificate Payload per SA. You ROUTINELY will have a chain of certificates. But that's not possible with this MIB. So, we need a table for certs. But, the cert formats are all documented in ISAKMP, not IKE, so we push it back to being more generic. Thus we create isakmpPhase1CertTable. The first two indices would be the augmentation of isakmpSaTable. The last index would be an integer from 1 to (say) 1000, for each of the Phase 1 certs for this SA. (There has to be some upper limit on the number of certs, if only due to maximum UDP packet size of 65535!) Here's the data I'd put in: isakmpPhase1SaCertIndex INTEGER (1..1000) *** last index isakmpPhase1SaCertType INTEGER { pkcs7(1), pgp(2), ... } isakmpPhase1SaCertData OCTET STRING (SIZE (1..65530)) isakmpPhase1SaCertSerial OCTET STRING (SIZE (1..63)) isakmpPhase1SaCertIssuer OCTET STRING I don't see the need to put "Peer" in the name, since this is a table only of Peer certificates. (Does bring up the issue, should we have a global table of our own Certs?) Another thing to think about when we reach peer certificates is the identity protection issues. ISAKMP and IKE go to great lengths to ensure identity protection. Now we go and put all those identities in a MIB. Obviously, there have to be different MIB views that can and cannot see the identity information. (These views would probably be different for SNMPv1, SNMPv2c, SNMPv3 with crypto, and perhaps any SNMP with Transport mode ESP.) We should be careful to have seperate tables with sensitive information, to make it easier to configure the MIB views. (Otherwise they will have to protect individual collumns in tables, which is a configuration pain in the butt.) So far, I'm OK on that score, as isakmpSaDoi0Table, isakmpSaDoi1Table, and isakmpPhase1CertTable, are all standalone tables full of "identity" information. DATA SA'S ========= As I've noted before, I really want to see tables of the individual SA's, indexed by the true indices of the SA's. However, we have to have one table per SA type, because SPI's are unique only within one security protocol (AH, ESP, IPCOMP). (See section 2.1 of RFC 2408.) We also have to do this because the additional uniqueness criteria (IP address, which is optional as a SPI discriminator in ISAKMP) are not necessarily the same for each security protocol. Also, the other annoying problem is that the numbering space for security protocols is DOI-specific. So, I would like to see ahSaTable, espSaTable, and ipcompSaTable. Each is indexed by destination IP address and SPI. Another reason for seperate tables is that ipcomp is optional. This makes it easy to leave out everything about ipcomp. Further, after the Destination and SPI, everything else is specific to DOI 1. (Magic numbers.) That's handy, since all the DOI 1 information is security-sensitive, you again you want it in a seperate table to simply view control. So, for instance, on AH: ahSaDestination OCTET STRING (SIZE (4 | 16)) ahSaSpi Unsigned32 Then there is ahSaDoi1Table, indexed by the previous table's indices: ahSaDoi1AuthAlgorithm INTEGER Similarly for ESP: espSaTable:: espSaDestination espSaSpi augmented by espSaDoi1Table:: espSaDoi1Encapsulation espSaDoi1EncryptAlg espSaDoi1EncryptKeyLength espSaDoi1AuthAlgorithm Finally, for IPCOMP: ipcompSaTable:: ipcompSaDestination ipcompSaSpi augmented by ipcompSaDoi1Table:: ipcompSaDoi1Algorithm PROTECTION SUITES ================= What does the proposed ipsecProtSuiteTable do during the 30 second rekey period (per Tim's draft-jenkins-ipsec-rekey-00.txt) when two sets of SA's are active? Just show the new ones and leave the old ones orphans? Very clear rules need to be laid out when a protection suite table entry can be changed in-place, and when it must be replaced by a new one. Certainly, if the Local ID or Remote ID change, it's a new protection suite. But changes in the SPI's don't cause a new row. Obviously, if the above AH, ESP, and IPCOMP tables are created, the corresponding entries would be removed from the protection suite table. Also, protection suites are a specifically IKE-specific concept, methinks. So, lets name the table ikeProtSuiteTable. It would be really nice if there was some way to have the Protection Suite entry point back to the Phase 1 SA. We could have the two cookies, with a syntax similar to IfIndexOrZero, where Zero means that the Phase I SA is no longer there. (If I can't win the cookie index, then it can be the arbitrary index, where 0 is a reserved index.) There's rather a mish-mosh between Inbound/Outbound and Local/Remote in the proposed table. That will get realy confusing if we create the proper 4 variables: ikeProtSuiteLocalLocalPort ikeProtSuiteLocalRemotePort ikeProtSuiteRemoteLocalPort ikeProtSuiteRemoteRemotePort Probably better to do Inbound/Outbound consistently. Another approach to inbound/outbound would be to have the table changed from full-duplex to half-duplex, and make the last index be INTEGER { inbound(1), outbound(2) }. Half as many MIB variables to define and implement, at the cost of one more dimension. Also addresses simplex connections, if such a thing becomes important. We probably want to make an augmenting table with the error counters, since that's security sensitive. Maybe the traffic counters belong there as well. Should there be a "status" variable? Again, as in the ISAKMP SA, we need the FULL set of Diffie-Hellman group parameters. REPLAY COUNTERS =============== I'd like to propose two more counters for receive replay events. The first would count "out of order" packets. The second wound count "lost" packets. The out of order counter would increment whenever you received an anti-replay counter lower than the previously received one, but it is has not be received before. This is a handy QOS measurement, you can tell if the Internet between the peers is shuffling packets on you. The lost counter would be incremented every time you slid the anti-replay window, and some of the "flags" that you slid away were for packets you never recieved. This is another indication of the QOS the Internet is providing. Since monitoring the QOS of the underlying Internet is generally a VERY hot button on VPN, I think that these would be really valuable counters. To interpret the latter counter, you also need to know the size of the receive anti-replay window, so add a variable for that. NOTIFY TABLE ============ Every notify message has a Protocol-ID field. This needs to be added as an index to the notify count table. Also, there's a DOI in the Notification Payload. So we need to make it DOI 1 specific. Also, some of the message types are DOI 1 specific. (Most are ISAKMP generic.) So, it should be isakmpNotifyDoi1CountTable: isakmpNotifyDoi1ProtocolId INTEGER { isakmp(1), ah(2), esp(3), ipcomp(4) } isakmpNotifyDoi1MessageType INTEGER { invalidPayloadType(1), doiNotSupported(2), ... } isakmpNotifyDoi1Count Counter32 With the first two variables being the two indices (in order). It would also be nice to have a scalar variable containing the Notification Data from the last received Notify Payload. This may be a helpful human-readable string. This could be passed along with the trap(s) generated on receiving such messages. However, we'd need to make the size rather limited, given the 576 byte limit on trap PDU's... From owner-ipsec@portal.ex.tis.com Fri Jan 29 21:43:10 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA06298; Fri, 29 Jan 1999 21:43:09 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id WAA25322 for ipsec-outgoing; Fri, 29 Jan 1999 22:09:30 -0500 (EST) Date: Sat, 30 Jan 1999 05:29:34 +0200 (EET) Message-Id: <199901300329.FAA06680@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: John Shriver Cc: tjenkins@TimeStep.com, ipsec@tis.com Subject: Re: New IPSec Monitoring MIB draft In-Reply-To: <199901292217.RAA10569@brill.shiva.com> References: <319A1C5F94C8D11192DE00805FBBADDF7750E8@exchange> <199901292217.RAA10569@brill.shiva.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 28 min X-Total-Time: 32 min Sender: owner-ipsec@ex.tis.com Precedence: bulk (I won't comment the generic structure of this proposal, just some details.) John Shriver writes: > ikePhase1SaDifHelGroupDesc INTEGER > ikePhase1SaDifHelGroupType INTEGER ... > ikePhase1SaDifHelGroupPrime OCTET STRING > ikePhase1SaDifHelGroupGenOne Integer32 (or must it be OCTET STRING?) > ikePhase1SaDifHelGroupGenTwo Integer32 (") > ikePhase1SaDifHelGroupCurveA Integer32 (") > ikePhase1SaDifHelGroupCurveB Integer32 (") Those must be octet string, because they are quite often real bignums. > ikePhase1SaDifHelGroupOrder OCTET STRING > > Then, we have to decide if the MIB is obligated to fill in these > values for standard Groups, or whether it is filled on only when the > GroupType is 0. Or perhaps it's clearer if we define GroupType to be > -1 if non-standard, or have a TruthValue SYNTAX variable incidating > non-standard group. Group type is MODP(1), ECP(2), or EC2N(3) for the non-standard groups. Because you cannot give Group Descriptor if you defined group in Phase 1, I assume easiest way would be to define it so that you give either only the group descriptor (for standard well known groups), or all necessary parameters (type, prime, gen1, gen2, curve a, curve b, order) except group descriptor for the private groups. > As for the SA lifetime variables, I think Counter64 is safe. Really, > who is going to use "bignum" math in their SA's to count the lifetime > in kbytes? Nobody will accept (or properly implement) a lifetime with > a length greater than 8 bytes. For that matter, I think lifetimes in > seconds can be limited to 4 bytes, that's 136 years. (68 years if you > want to allow for sign bugs.) These are really flaws in the DOI, it > doesn't prohibit insane values... Why do we want to use kilobytes? I think Counter64 in bytes is almost enough. It is constant 5 GBytes/second for 100 years, or 50 GBytes/second for 10 years, or 0.5 TByte/second for 1 year. I don't think anyone wants to use LIFETIME of that big... Yes, I agree that 4 bytes for lifetime in seconds is enough. > Next, I'd rather have a seperate variable for lifetime in kbytes versus > lifetime in seconds. Why? Becuase you can then put proper UNITS > statements on each. So, we would have: > ikePhase1SaLifeType INTEGER { none(0), seconds(1), kilobytes(2) } > ikePhase1SaTimeStart DataAndTime > ikePhase1SaTimeLimit Counter32 UNITS "Seconds" > ikePhase1SaByteLimit Counter64 UNITS "Kilobytes" Note, that in IKE you might have both second and kilobytes limit at the same time, so you need both(3) value above, or just leave it away and say that if TimeLimit or ByteLimit is zero then there is no limit for that unit. > Now we come to another major issue. There is no limit of one > Certificate Payload per SA. You ROUTINELY will have a chain of > certificates. But that's not possible with this MIB. So, we need a > table for certs. Yes, you can have multiple certificates, but at the end you only have ONE end user public key you use in the authentication take from the certificate. There isn't a reason to include the whole path, only the end user certificate used in the authentication is really interesting. > It would be really nice if there was some way to have the Protection > Suite entry point back to the Phase 1 SA. We could have the two > cookies, with a syntax similar to IfIndexOrZero, where Zero means that > the Phase I SA is no longer there. (If I can't win the cookie index, > then it can be the arbitrary index, where 0 is a reserved index.) This, I think, is quite important, because this really ties the IPSec SA to the authentication. This is needed if we ever want to do any kind of user based accounting etc for the IPSec traffic. > There's rather a mish-mosh between Inbound/Outbound and Local/Remote > in the proposed table. That will get realy confusing if we create the > proper 4 variables: > ikeProtSuiteLocalLocalPort > ikeProtSuiteLocalRemotePort > ikeProtSuiteRemoteLocalPort > ikeProtSuiteRemoteRemotePort What are these four variables? If they are quick mode identity port numbers, there are only two identities, not four. The responder must give back same identities what the initiator sent. > Again, as in the ISAKMP SA, we need the FULL set of Diffie-Hellman > group parameters. In that case should we add separate table describing the groups defined in the new group mode. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@portal.ex.tis.com Sat Jan 30 02:00:05 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA12903; Sat, 30 Jan 1999 02:00:04 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id CAA25630 for ipsec-outgoing; Sat, 30 Jan 1999 02:27:29 -0500 (EST) From: "Kalyan Chakravarthy Bade" To: Cc: Subject: Where should be the CERT payload in IKE ? Date: Fri, 29 Jan 1999 12:46:55 +0530 Message-ID: <01be4b57$59d323c0$320110ac@garfield.roc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ipsec@ex.tis.com Precedence: bulk In section 3.6 of isakmp draft, it is stated that the Certificate payload MUST be accepted at any point during an exchange. Whereas in IKE, it is given as part of only fifth and sixth messages in the main mode exchange. Can we assume that if at all CERT payload is exchanged, it is done ONLY in fifth and sixth messages of main mode ? Kalyan. From owner-ipsec@portal.ex.tis.com Sat Jan 30 14:25:10 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA19368; Sat, 30 Jan 1999 14:25:09 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA26679 for ipsec-outgoing; Sat, 30 Jan 1999 14:56:31 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: In-Reply-To: <4FC3655B6D7DD21195E208002BB760FB1044@ntwikkit> Date: Fri, 29 Jan 1999 12:08:07 -0500 To: Waters Stephen From: Stephen Kent Subject: RE: SSL v IPSEC for management? Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, SSL offers protection against replay, by assuming perfect delivery afforded over TCP. Thus attacks against the TCP layer can disrupt SSL sessions, and one is vulnerable to TCP SYN floods, etc. IPsec protects against replay, but operates below TCP and thus protects against a range of (denial of sevrice and other) attacks that tacke place at hat layer. Both protocols can make use of certificates for two-way authentication. Browsers come equipped with a set of root CA certificates, but generic SSL implementations need not contain this pre-defined set. Thus, if one makes use of SSL independent of a browser, one has the same sort of problem as in an IPsec implementation, i.e., initial acquisition of a CA certificate suitable for validating certificates issued to the gateway and to the management station. Steve From owner-ipsec@portal.ex.tis.com Sat Jan 30 14:25:10 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA19371; Sat, 30 Jan 1999 14:25:10 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA26681 for ipsec-outgoing; Sat, 30 Jan 1999 14:56:31 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: In-Reply-To: <199901280234.VAA03373@smb.research.att.com> Date: Fri, 29 Jan 1999 16:08:14 -0500 To: Steve Bellovin From: Stephen Kent Subject: Re: transport-friendly ESP Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, As you and I discussed after the last IPsec WG meeting in Orlando, I am concerned by the possible adverse consqeunces of this approach to "cheating" with what purports to be an IP layer security protocol. I'd rather offer ways of creating copies of pre-defined transport layer protocol information for access outside of the ESP protection boundary. A moveable window of the sort you descibe could be misconfigured and allow substantial amounts of data to be transmitted in plaintext form. In contrast, if we provide a means of carrying a plaingtext copy of selected transport layer info outside of the ESP payload, we can limit the damage that misconfiguration (bening or malicious) might inflict. Steve From owner-ipsec@portal.ex.tis.com Sat Jan 30 14:27:49 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA19399; Sat, 30 Jan 1999 14:27:48 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA26713 for ipsec-outgoing; Sat, 30 Jan 1999 15:06:27 -0500 (EST) Message-Id: <199901302023.PAA10319@smb.research.att.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Stephen Kent Subject: Re: transport-friendly ESP cc: ipsec@tis.com, tf-esp@research.att.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 30 Jan 1999 15:23:39 -0500 From: "Steven M. Bellovin" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message , Stephen Kent writes: >Steve, > >As you and I discussed after the last IPsec WG meeting in Orlando, I am >concerned by the possible adverse consqeunces of this approach to >"cheating" with what purports to be an IP layer security protocol. I'd >rather offer ways of creating copies of pre-defined transport layer >protocol information for access outside of the ESP protection boundary. A >moveable window of the sort you descibe could be misconfigured and allow >substantial amounts of data to be transmitted in plaintext form. In >contrast, if we provide a means of carrying a plaingtext copy of selected >transport layer info outside of the ESP payload, we can limit the damage >that misconfiguration (bening or malicious) might inflict. > That was, in fact, my original idea. A number of people objected, both on grounds of ugliness but also because it supplied high-quality known plaintext if the same information was both inside and outside. It's still a reasonable approach, and I'm certainly not committed to any particular design at this point. To deal with your concerns, my current thinking is that the the boundary be negotiated semantically, rather than as a byte count, and that the receiver MUST tear down any SA on which authentic (per the integrity check) packets are received with the wrong boundary. Btw -- I've cc'd both ipsec and tf-esp on this note, though the ongoing discussion should take place on the latter list. From owner-ipsec@portal.ex.tis.com Sat Jan 30 14:34:18 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA19428; Sat, 30 Jan 1999 14:34:18 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA26680 for ipsec-outgoing; Sat, 30 Jan 1999 14:56:31 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: In-Reply-To: <3.0.3.32.19990127200721.00b553e0@mail> References: <199901280234.VAA03373@smb.research.att.com> Date: Fri, 29 Jan 1999 15:55:41 -0500 To: Alex Alten From: Stephen Kent Subject: Re: transport-friendly ESP Cc: Steve Bellovin , ipsec@tis.com, end2end-interest@isi.edu, tsv@ee.lbl.gov, diff-serv@BayNetworks.COM, ecn-interest@research.att.com, red-impl@lbl.gov, jis@MIT.EDU, mleech@nortel.ca Sender: owner-ipsec@ex.tis.com Precedence: bulk Alex, The purpose of IPsec is to offer end-to-end protection, so applying IPsec on a per-hop basis is feasible, but findamentally counter to the underlying motivation for these protocols, since the begining of this work (too) many years ago. Steve From owner-ipsec@portal.ex.tis.com Sat Jan 30 22:52:06 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA08444; Sat, 30 Jan 1999 22:52:05 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id XAA27487 for ipsec-outgoing; Sat, 30 Jan 1999 23:32:29 -0500 (EST) Message-Id: <3.0.3.32.19990130194427.00afa230@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Sat, 30 Jan 1999 19:44:27 -0800 To: Stephen Kent From: Alex Alten Subject: Re: transport-friendly ESP Cc: Steve Bellovin , ipsec@tis.com, jis@MIT.EDU, mleech@nortel.ca, tf-esp@research.att.com In-Reply-To: References: <3.0.3.32.19990127200721.00b553e0@mail> <199901280234.VAA03373@smb.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve K., As a technology spreads it starts to be used in ways that may not have been intended by the original designers. Possibly IPSEC is better suited for per hop protection within a security system which maintains and enforces intermediate node trustworthiness. - Alex P.S. I reduced the cross posts to ipsec, tf-esp and some individuals. Good luck Steve B. with reconciling IPSEC and transport needs. At 03:55 PM 1/29/99 -0500, Stephen Kent wrote: >Alex, > >The purpose of IPsec is to offer end-to-end protection, so applying IPsec >on a per-hop basis is feasible, but findamentally counter to the underlying >motivation for these protocols, since the begining of this work (too) many >years ago. > >Steve > -- Alex Alten Alten@Home.Com Alten@TriStrata.Com P.O. Box 11406 Pleasanton, CA 94588 USA (925) 417-0159 From owner-ipsec@portal.ex.tis.com Sun Jan 31 17:47:28 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA14941; Sun, 31 Jan 1999 17:47:27 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA28923 for ipsec-outgoing; Sun, 31 Jan 1999 17:46:22 -0500 (EST) Message-ID: <36B4E0A2.F7FC3379@cs.umass.edu> Date: Sun, 31 Jan 1999 18:00:50 -0500 From: Lewis McCarthy Organization: Theoretical Computer Science Group, University of Massachusetts at Amherst X-Mailer: Mozilla 4.03 [en] (X11; U; IRIX 5.3 IP20) MIME-Version: 1.0 To: IP Security WG List Subject: Re: New IPSec Monitoring MIB draft References: <319A1C5F94C8D11192DE00805FBBADDF7750E8@exchange> <199901292217.RAA10569@brill.shiva.com> <199901300329.FAA06680@torni.ssh.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Tero Kivinen wrote in reply to John Shriver: > > Now we come to another major issue. There is no limit of one > > Certificate Payload per SA. You ROUTINELY will have a chain of > > certificates. But that's not possible with this MIB. So, we need a > > table for certs. > > Yes, you can have multiple certificates, but at the end you only have > ONE end user public key you use in the authentication take from the > certificate. There isn't a reason to include the whole path, only the > end user certificate used in the authentication is really interesting. This last point isn't obvious to me. In view of the work on trust metrics for certification paths, I imagine that examining the whole path might be useful. Since the overall authentication relies upon the entire path, I'm not sure why you would single out the terminal cert for inclusion in the MIB. -Lewis From owner-ipsec@portal.ex.tis.com Sun Jan 31 20:06:12 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA25133; Sun, 31 Jan 1999 20:06:11 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id UAA29143 for ipsec-outgoing; Sun, 31 Jan 1999 20:22:22 -0500 (EST) Message-Id: <199902010142.UAA26667@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: New IPSec Monitoring MIB draft In-Reply-To: Your message of "Sun, 31 Jan 1999 18:00:50 EST." <36B4E0A2.F7FC3379@cs.umass.edu> Date: Sun, 31 Jan 1999 20:42:39 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Lewis" == Lewis McCarthy writes: Lewis> This last point isn't obvious to me. In view of the work on trust Lewis> metrics for certification paths, I imagine that examining the Lewis> whole path might be useful. Since the overall authentication Lewis> relies upon the entire path, I'm not sure why you would single out Lewis> the terminal cert for inclusion in the MIB. I would agree. Would it be legal for an implementation to put Phase I SAs that *failed* to be set up due to authentication failures? :!mcr!: | Network and security consulting/contract programming Michael Richardson | Firewalls, TCP/IP and Unix administration Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine.