From owner-ipsec Mon Aug 3 11:06:09 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA23897 for ipsec-outgoing; Mon, 3 Aug 1998 10:55:28 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01C6E673@wade.reo.dec.com> From: Stephen Waters To: ipsec@tis.com Subject: an inbound SPD-check question Date: Mon, 3 Aug 1998 14:12:49 +0100 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 Say I am processing an inbound packet that has IPSEC protection. I have located the right SA and I have decoded the original packet. I am then required to check the SPD to see that the require security was applied for the packet I now have. If the SPD check comes back with the answer "BYPASS" (i.e. no security required), do I dump the packet, or forward it? A bit of silly case (probably some mis-config somewhere), but it could happen. If security has been successfully applied, it seems a bit naff to bin the packet because the inbound SPD check says the IPSEC protection was not required. Cheers, Steve. From owner-ipsec Mon Aug 3 12:07:22 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA24215 for ipsec-outgoing; Mon, 3 Aug 1998 12:01:29 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C01C6E673@wade.reo.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 3 Aug 1998 11:58:32 -0400 To: Stephen Waters From: Stephen Kent Subject: Re: an inbound SPD-check question Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen, >Say I am processing an inbound packet that has IPSEC protection. I have >located the >right SA and I have decoded the original packet. > >I am then required to check the SPD to see that the require security was >applied for the >packet I now have. If the SPD check comes back with the answer "BYPASS" >(i.e. no >security required), do I dump the packet, or forward it? > >A bit of silly case (probably some mis-config somewhere), but it could >happen. If security >has been successfully applied, it seems a bit naff to bin the packet because >the inbound SPD >check says the IPSEC protection was not required. I'd drop the packet and make an audit log entry. We want misconfigurations to be detected and the SPD changed and if we don't provide feedback ... Steve From owner-ipsec Mon Aug 3 14:29:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA25039 for ipsec-outgoing; Mon, 3 Aug 1998 14:26:39 -0400 (EDT) Message-Id: <199808031842.OAA23332@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-shima-ipsec-isakmp-cke-type-00.txt Date: Mon, 03 Aug 1998 14:42:56 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ISAKMP Certificate Key Exchange Type Specification Author(s) : S. Shima Filename : draft-shima-ipsec-isakmp-cke-type-00.txt Pages : 8 Date : 31-Jul-98 This document defines a new key exchange type of ISAKMP that reduce the number of transmission and encrypt message contents from first transmission. The Certificate Key Exchange is effective since it does not use Diffie-Hellman key exchange algorithm but public key cryptography. The Certificate Key Exchange use certificates as authentication information. Please send comments on this document to the ipsec@tis.com. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-shima-ipsec-isakmp-cke-type-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-shima-ipsec-isakmp-cke-type-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-shima-ipsec-isakmp-cke-type-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: <19980731134640.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-shima-ipsec-isakmp-cke-type-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-shima-ipsec-isakmp-cke-type-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980731134640.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Aug 3 14:54:11 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA25173 for ipsec-outgoing; Mon, 3 Aug 1998 14:52:39 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199807270005.RAA05146@kc.livingston.com> References: from "Stephen Kent" at Jul 25, 98 06:10:58 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 3 Aug 1998 15:05:52 -0400 To: suresh@livingston.com (Pyda Srisuresh) From: Stephen Kent Subject: Re: Comments on "Hybrid Auth. mode for IKE" Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Suresh, I'm glad we have clarified a number of misunderstandings, though a few still remain. >I see your clever rewording :-). >In reality, users dont have certs and there is a strong demand to >support existing auth. mechanisms to avail of the IPsec services. User's with passwords can be issued certs readily. User's have certs as much as they have SecurID cards, S-Key software, etc. Any time we move beyond what a user can do personally to authenticate himself, to require computation, the line is blurred. Hardware tokens are certainly a good way to personalize computatiionally intensive auth mechanisms, but they are not the only game in town. The primary differences seem to be that your primary goal is to find a way to make use of existing user auth mechanisms with IPsec, period. My goal is to not degrade the minimum quality of security service offered by the use of IPsec. Hopefully there may be a way to satosfy both goals, but I am not prepared to backoff on mine in the name of "market demands, legacy systems, etc." Steve From owner-ipsec Mon Aug 3 15:08:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA25200 for ipsec-outgoing; Mon, 3 Aug 1998 15:06:40 -0400 (EDT) From: Dan McDonald Message-Id: <199808031922.MAA06388@kebe.eng.sun.com> Subject: Re: an inbound SPD-check question To: kent@bbn.com (Stephen Kent) Date: Mon, 3 Aug 1998 12:22:50 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: from "Stephen Kent" at Aug 3, 98 11:58:32 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > >If security has been successfully applied, it seems a bit naff to bin the > >packet because the inbound SPD check says the IPSEC protection was not > >required. > > I'd drop the packet and make an audit log entry. We want misconfigurations > to be detected and the SPD changed and if we don't provide feedback ... I agree with Steve K. (to prevent ambigity), but he's missing a reason. Pardon my excessive paranoia, but if your inbound policy says "cleartext", there's a good chance your outbound policy will also say "cleartext". Now if someone sends you an encrypted packet which you can decrypt, but you send a cleartext reply, suddenly an eavesdropping adversary has a piece of data he/she didn't have before. We drop and log such packets. We made that decision based on not allowing an adversary free plaintext. Dan From owner-ipsec Mon Aug 3 15:22:22 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA25264 for ipsec-outgoing; Mon, 3 Aug 1998 15:20:40 -0400 (EDT) Message-Id: <199808031933.PAA28533@postal.research.att.com> To: Stephen Kent cc: suresh@livingston.com (Pyda Srisuresh), ipsec@tis.com Subject: Re: Comments on "Hybrid Auth. mode for IKE" Date: Mon, 03 Aug 1998 15:33:31 -0400 From: Steve Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk In message , Stephen Kent writes: > > User's with passwords can be issued certs readily. This is a very important point. Rather than touching ipsec and IKE, a better solution would be to define a certificate retrieval/generation protocol. That is, suppose a user has a "conventional" authentication mechanism, such as a password or a token. Use that mechanism to contact a server that will send you your stored certificate. If you don't have one, a short-lived certificate, suitable for use with IKE, can be generated for you on the fly. Its lifetime can be whatever is appropriate; if something like 4-8 hours, it need not use high-quality RSA moduli since ipsec will provide perfect forward secrecy. If I were to design such a protocol, I'd probably use something like EKE (www.research.att.com/~smb/papers/neke.ps or .pdf; also aeke.{ps,pdf}) to provide protection against password-guessing. (Disclaimer -- EKE and AEKE are patented.) Or the client can generate a certificate on the fly, and send the public portion off to the server, along with an authenticator, to be signed. Either way, there's no need to touch IKE. From owner-ipsec Mon Aug 3 15:36:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA25291 for ipsec-outgoing; Mon, 3 Aug 1998 15:33:42 -0400 (EDT) Message-Id: <199808031011.GAA29911@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: Comments on "Hybrid Auth. mode for IKE" In-reply-to: Your message of "Mon, 03 Aug 1998 15:05:52 EDT." Date: Mon, 03 Aug 1998 06:11:38 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Stephen" == Stephen Kent writes: Stephen> IPsec, period. My goal is to not degrade the minimum quality of Stephen> security service offered by the use of IPsec. Hopefully there Stephen> may be a way to satosfy both goals, but I am not prepared to Stephen> backoff on mine in the name of "market demands, legacy systems, Stephen> etc." So long as the market provides a superset of what you need, and provides knobs for the policy controls, shouldn't you be able to do what you want? [It would also be nice for all vendors on a particular platform to provide a way (an API) to subsitute a different certificate validation function so that PKIX name constraints could be introduced into products that don't understand the extensions, but that is something perhaps for PKIX to standardize] :!mcr!: | Network and security consulting/contract programming Michael Richardson | Firewalls, TCP/IP and Unix administration Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. ON HUMILITY: To err is human, to moo bovine. From owner-ipsec Mon Aug 3 22:44:16 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA26526 for ipsec-outgoing; Mon, 3 Aug 1998 22:41:48 -0400 (EDT) Message-ID: <35C6768C.DB367A67@checkpoint.com> Date: Mon, 03 Aug 1998 19:48:44 -0700 From: Moshe Litvin X-Mailer: Mozilla 4.5b1 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: Pyda Srisuresh , ipsec@tis.com Subject: Re: Comments on "Hybrid Auth. mode for IKE" References: from "Stephen Kent" at Jul 25, 98 06:10:58 pm Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen Kent wrote: > User's with passwords can be issued certs readily. This is correct from a technical point of view. But the reality is more complex, not to mention the current installation base. > User's have certs as > much as they have SecurID cards, S-Key software, etc. Any time we move > beyond what a user can do personally to authenticate himself, to require > computation, the line is blurred. Hardware tokens are certainly a good way > to personalize computatiionally intensive auth mechanisms, but they are not > the only game in town. > > The primary differences seem to be that your primary goal is to find a way > to make use of existing user auth mechanisms with IPsec, period. My goal > is to not degrade the minimum quality of security service offered by the > use of IPsec. Hopefully there may be a way to satosfy both goals, but I am > not prepared to backoff on mine in the name of "market demands, legacy > systems, etc." So what you are saying is that every one that is not yet ready to use certificates and want to use a method not vulnerable to dictionary attack is not allowed to use IPSEC? Moshe From owner-ipsec Tue Aug 4 05:02:19 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA27541 for ipsec-outgoing; Tue, 4 Aug 1998 05:00:58 -0400 (EDT) Message-ID: From: William Dixon To: "'ipsec@tis.com'" Subject: IPSec interop workshop Aug 31st - Sept 3 invitation Date: Tue, 4 Aug 1998 02:17:20 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipsec@ex.tis.com Precedence: bulk I am concerned that we are not having enough opportunities for comprehensive and/or sophisticated interoperability testing. So I'd like to offer one during the week after the IETF (not great timing I know). I've got room for about 30 people plus equipment. So please "r" me if interested and give me a few days to respond. I'd like someone from ICSA to attend also. By the end of the week I hope to have enough responses to determine if it will be worthwhile. Thanks, -Wm Announcement of IPSec Bakeoff Opportunity Mon-Thurs, Aug 31st- Sept 3 Microsoft Main Campus, Olympic Room in bldg. 27S Redmond, WA Contents: 1. Purpose - Criteria 2. Proposed functionality testing 3. Proposed daily agenda 1. Purpose Provide IPSec vendor developers of the most complete IPSec implementations a small-scale, mixed vendor environment to further test IPSec interoperability for transport and tunneling, under load, across a variety of network topologies, including dialup, 100Mbit Ethernet and across Internet WAN links. To test attack resilience of IPSec implementations. To begin testing L2TP/IPSec interop. No press releases, just interop work. Wider interop shake out for base and extended families of ICSA v2.0 criteria. Increase consensus among IPSec vendors for how to solve some common deployment problems and prepare for IBM's full bakeoff in October. Due to the small facility, I'd like to prioritize for those who can negotiate and perform ALL of the following functionality: IKE - Negotiate and perform - Multiple auth method proposals - Certificate authentication and certificate request payloads - Dynamic rekey with PFS for both main mode and quick mode - Selectors (filters) to the IPaddress, IP Subnet, and port IPSec - ESP with 56bitDES, null-ESP, MD5 and SHA1 - Transport and tunnel mode Implementations should also have IKE - AND proposal - SA delete payload - Lifetimes in both bytes and times - Group 2 DH with 3DES - 512bit DH or explicit p & g IPSec - Protocol and port filters - L2TP/IPSec integration - AH with MD5 and SHA1 - AH+ESP combination - ESP 3DES - ESP 40bitDES 2. IPSec Functionality Testing 1. Basic interop on combinations 2. Certificate Infrastructure - Cert Server certificates from: Entrust, Microsoft, Verisign, Netscape - Cert trust verification using hierarchy in PKI infrastructures - Using CRLs during cert validation ? - Timing of IKE successful/unsuccessful negotiation using certs, how transparent for end-to-end? 3. IKE retransmit behavior 4. Export <-> Export, Export <-> Domestic - Basic IKE and IPSec tests - Explicit p&g DH with 40bit DES 5. IKE commit bit 6. Throughput & number of simultaneous negotiations performance testing against different implementations 7. Reboot recovery (peer reboot losing it's security associations) 8. Scenarios - - End-to-End transport long lived security associations (over night, data transfer >1Gb) with frequent dynamic rekey - End-to-GW tunnel long lived security associations (over night, data transfer >1Gb) with frequent dynamic rekey - Policy change events while under SA load - End-to-End SA through IPSec tunnels, initiation both ways - Client End-to-End through client-to-GW tunnel SA, initiate from client for tunnel, then initiation both ways for end-to-end - Client-to-GW transport SA for secure management 9. Multiple auth method proposals and AND proposal 10. Discuss reliability requirements for SA establishment, maintenance under load, heavy fragmentation, packet corruption, packet loss 3. Schedule Monday evening Aug 31 - we may actually be able to setup on Sunday, not sure yet, which would make this a full testing day 12:00-17:00 - Room and Network Setup 15:00-17:00 - Shipping deliveries from MS Receiving to bldg. 27/Olympic Room 17:00-22:00 - Vendor equipment drop off/setup Tuesday Sept 1st 7:30 - Room Opens, Catered continental bkfast 8:30 - Welcome, Agenda, Network Layout, Logistics 9:00 - Testing 12:30 - SyncUp Discussion with catered lunch 13:00-13:30 Overview of MS PKI 17:00 - ReSync Discussion 22:00 - Room closes for night Wednesday Sept 2nd 7:30 - Room Opens, Catered continental bkfast 8:30 - Agenda, Q& A 12:30 - SyncUp Discussion 13:00-13:30 Overview of IPSec policy in NT5.0 Active Directory 17:00 - SyncUp Discussion 22:00 - Room closes for night Thursday Sept 3rd 7:30 - Room Opens, Catered continental bkfast 8:30 - Agenda, Q& A 12:30 - 13:30 - SyncUp Discussion 17:00 - Vendor Equip load Out 19:00 - Network pulled up 21:00 - Turnover to facilities management for next day Friday Sept 4th - Event notes typed up and released to IETF IPSec list & participants Wm William Dixon, 425-703-8729, wdixon@microsoft.com Program Manager, Internet Protocol Security PBS Windows Networking & Communications Microsoft Corporation From owner-ipsec Tue Aug 4 09:43:46 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA28421 for ipsec-outgoing; Tue, 4 Aug 1998 09:42:20 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199808041359.GAA03610@kc.livingston.com> Subject: Re: Comments on "Hybrid Auth. mode for IKE" To: kent@bbn.com (Stephen Kent) Date: Tue, 4 Aug 1998 06:59:37 -0700 (PDT) Cc: suresh@livingston.com, ipsec@tis.com In-Reply-To: from "Stephen Kent" at Aug 3, 98 03:05:52 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Suresh, > > I'm glad we have clarified a number of misunderstandings, though a few > still remain. > OK, Thanks. > >I see your clever rewording :-). > >In reality, users dont have certs and there is a strong demand to > >support existing auth. mechanisms to avail of the IPsec services. > > User's with passwords can be issued certs readily. User's have certs as > much as they have SecurID cards, S-Key software, etc. Any time we move > beyond what a user can do personally to authenticate himself, to require > computation, the line is blurred. Hardware tokens are certainly a good way > to personalize computatiionally intensive auth mechanisms, but they are not > the only game in town. > > The primary differences seem to be that your primary goal is to find a way > to make use of existing user auth mechanisms with IPsec, period. My goal > is to not degrade the minimum quality of security service offered by the > use of IPsec. Hopefully there may be a way to satosfy both goals, but I am > not prepared to backoff on mine in the name of "market demands, legacy > systems, etc." > > Steve > I agree with your characterization of the differences for the most part. We need to be open to market requirements, legacy or otherwise. By addressing these requirements in IETF, we can ensure interoperability. cheers, suresh From owner-ipsec Tue Aug 4 10:07:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA28586 for ipsec-outgoing; Tue, 4 Aug 1998 10:07:21 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199808041420.HAA03736@kc.livingston.com> Subject: Re: an inbound SPD-check question To: Stephen.Waters@digital.com (Stephen Waters) Date: Tue, 4 Aug 1998 07:20:35 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C01C6E673@wade.reo.dec.com> from "Stephen Waters" at Aug 3, 98 02:12:49 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > > Say I am processing an inbound packet that has IPSEC protection. I have > located the > right SA and I have decoded the original packet. > > I am then required to check the SPD to see that the require security was > applied for the > packet I now have. If the SPD check comes back with the answer "BYPASS" > (i.e. no > security required), do I dump the packet, or forward it? > > A bit of silly case (probably some mis-config somewhere), but it could > happen. If security > has been successfully applied, it seems a bit naff to bin the packet because > the inbound SPD > check says the IPSEC protection was not required. > > Cheers, Steve. > The problem you state could alternately be labelled "denial-of-service attack" on the receiver. The receiver is forced to decrypt packets (a compute intensive task), only to decide afterwards between (a) dropping or (b) sending ICMP reject. If accepted, the consequence would be even worse because traffic would be encrypted in one direction and clear in the opposite direction. A sure target from an atacker. IPsec is highly prone to denial-of-service attack when policy exchange is not synchronous between peers. This is why it is important that policies be exchanged properly at the time of IKE negotiation. cheers, suresh From owner-ipsec Tue Aug 4 11:08:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA29039 for ipsec-outgoing; Tue, 4 Aug 1998 11:03:29 -0400 (EDT) Message-ID: From: Greg Carter To: "'ipsec@tis.com'" , "'William Dixon'" Cc: "'ipsec@icsa.net'" Subject: RE: IPSec interop workshop Aug 31st - Sept 3 invitation Date: Tue, 4 Aug 1998 11:12:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk What about the previously announced IBM workshop in the fall? > ICSA in conjunction with IBM are planning the next IPsec workshop. > > The date we have been able to get is the week of Oct 26th. The host is > IBM's AS/400 Endicott group and they will be hosting it at Holiday Inn > Arena, Binghamton, New York. We are working out the site details. > > Why YAW? > > CA interoperablity. > > I am working on significant CA participation. Got a couple items in the > works that should be announced next month. > > IPPCP -- Remote clients, ya know? > > Remote client support. > > I hope we can set direction for remote client support and do at least some > engineering level work with whatever direction gets set. > > Complex architecture. > > Transport within tunnels. NAT traversal. Mobile gateways. Other > nasties. > > And of course new comers and others. > > Although non IPsec developers are welcome to come, They should develop a > test plan to help the developers. Time for this around Chicago time. > > > Anyway. That is the date and location. I will soon be announcing how to > get in touch for reservations and workshop planning. > > > > > Robert Moskowitz > ICSA > Security Interest EMail: rgm-sec@htt-consult.com > ---- Greg Carter, Entrust Technologies greg.carter@entrust.com > ---------- > From: William Dixon[SMTP:wdixon@microsoft.com] > Sent: Tuesday, August 04, 1998 5:17 AM > To: 'ipsec@tis.com' > Subject: IPSec interop workshop Aug 31st - Sept 3 invitation > > I am concerned that we are not having enough opportunities for > comprehensive > and/or sophisticated interoperability testing. So I'd like to offer one > during the week after the IETF (not great timing I know). I've got room > for > about 30 people plus equipment. So please "r" me if interested and give > me > a few days to respond. I'd like someone from ICSA to attend also. By the > end of the week I hope to have enough responses to determine if it will be > worthwhile. Thanks, -Wm > > > Announcement of IPSec Bakeoff Opportunity > Mon-Thurs, Aug 31st- Sept 3 > Microsoft Main Campus, Olympic Room in bldg. 27S > Redmond, WA > > Contents: > 1. Purpose - Criteria > 2. Proposed functionality testing > 3. Proposed daily agenda > > 1. Purpose > Provide IPSec vendor developers of the most complete IPSec implementations > a > small-scale, mixed vendor environment to further test IPSec > interoperability > for transport and tunneling, under load, across a variety of network > topologies, including dialup, 100Mbit Ethernet and across Internet WAN > links. To test attack resilience of IPSec implementations. To begin > testing L2TP/IPSec interop. No press releases, just interop work. Wider > interop shake out for base and extended families of ICSA v2.0 criteria. > Increase consensus among IPSec vendors for how to solve some common > deployment problems and prepare for IBM's full bakeoff in October. > > Due to the small facility, I'd like to prioritize for those who can > negotiate and perform ALL of the following functionality: > IKE - Negotiate and perform > - Multiple auth method proposals > - Certificate authentication and certificate request payloads > - Dynamic rekey with PFS for both main mode and quick mode > - Selectors (filters) to the IPaddress, IP Subnet, and port > IPSec > - ESP with 56bitDES, null-ESP, MD5 and SHA1 > - Transport and tunnel mode > > Implementations should also have > IKE > - AND proposal > - SA delete payload > - Lifetimes in both bytes and times > - Group 2 DH with 3DES > - 512bit DH or explicit p & g > > IPSec > - Protocol and port filters > - L2TP/IPSec integration > - AH with MD5 and SHA1 > - AH+ESP combination > - ESP 3DES > - ESP 40bitDES > > 2. IPSec Functionality Testing > 1. Basic interop on combinations > 2. Certificate Infrastructure > - Cert Server certificates from: Entrust, Microsoft, Verisign, > Netscape > - Cert trust verification using hierarchy in PKI infrastructures > - Using CRLs during cert validation ? > - Timing of IKE successful/unsuccessful negotiation using certs, how > transparent for end-to-end? > 3. IKE retransmit behavior > 4. Export <-> Export, Export <-> Domestic > - Basic IKE and IPSec tests > - Explicit p&g DH with 40bit DES > 5. IKE commit bit > 6. Throughput & number of simultaneous negotiations performance testing > against different implementations > 7. Reboot recovery (peer reboot losing it's security associations) > 8. Scenarios - > - End-to-End transport long lived security associations (over night, > data transfer >1Gb) with frequent dynamic rekey > - End-to-GW tunnel long lived security associations (over night, > data transfer >1Gb) with frequent dynamic rekey > - Policy change events while under SA load > - End-to-End SA through IPSec tunnels, initiation both ways > - Client End-to-End through client-to-GW tunnel SA, initiate from > client for tunnel, then initiation both ways for end-to-end > - Client-to-GW transport SA for secure management > 9. Multiple auth method proposals and AND proposal > 10. Discuss reliability requirements for SA establishment, maintenance > under > load, heavy fragmentation, packet corruption, packet loss > > 3. Schedule > Monday evening Aug 31 - we may actually be able to setup on Sunday, not > sure > yet, which would make this a full testing day > 12:00-17:00 - Room and Network Setup > 15:00-17:00 - Shipping deliveries from MS Receiving to bldg. 27/Olympic > Room > 17:00-22:00 - Vendor equipment drop off/setup > > Tuesday Sept 1st > 7:30 - Room Opens, Catered continental bkfast > 8:30 - Welcome, Agenda, Network Layout, Logistics > 9:00 - Testing > 12:30 - SyncUp Discussion with catered lunch > 13:00-13:30 Overview of MS PKI > 17:00 - ReSync Discussion > 22:00 - Room closes for night > > Wednesday Sept 2nd > 7:30 - Room Opens, Catered continental bkfast > 8:30 - Agenda, Q& A > 12:30 - SyncUp Discussion > 13:00-13:30 Overview of IPSec policy in NT5.0 Active Directory > 17:00 - SyncUp Discussion > 22:00 - Room closes for night > > Thursday Sept 3rd > 7:30 - Room Opens, Catered continental bkfast > 8:30 - Agenda, Q& A > 12:30 - 13:30 - SyncUp Discussion > 17:00 - Vendor Equip load Out > 19:00 - Network pulled up > 21:00 - Turnover to facilities management for next day > > Friday Sept 4th - Event notes typed up and released to IETF IPSec list & > participants > > > Wm > William Dixon, 425-703-8729, wdixon@microsoft.com > Program Manager, Internet Protocol Security > PBS Windows Networking & Communications > Microsoft Corporation > From owner-ipsec Tue Aug 4 13:19:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA29702 for ipsec-outgoing; Tue, 4 Aug 1998 13:18:29 -0400 (EDT) Message-ID: From: William Dixon To: "'ipsec@tis.com'" Subject: RE: IPSec interop workshop Aug 31st - Sept 3 invitation Date: Tue, 4 Aug 1998 10:34:48 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipsec@ex.tis.com Precedence: bulk My apologies to IBM and everyone for not making one point clear. I fully support the already announced IBM bakeoff in late October and we will attend. The invitation I sent is another opportunity, 6 weeks earlier, to help vendors work out interop issues. Particularly it will be hard for me to make changes in November/Dec and I'd like to ship something people won't have to many problems interoping with as they move forward in their implementations. -Wm -----Original Message----- From: William Dixon [mailto:wdixon@microsoft.com] Sent: Tuesday, August 04, 1998 2:17 AM To: 'ipsec@tis.com' Subject: IPSec interop workshop Aug 31st - Sept 3 invitation I am concerned that we are not having enough opportunities for comprehensive and/or sophisticated interoperability testing. So I'd like to offer one during the week after the IETF (not great timing I know). I've got room for about 30 people plus equipment. So please "r" me if interested and give me a few days to respond. I'd like someone from ICSA to attend also. By the end of the week I hope to have enough responses to determine if it will be worthwhile. Thanks, -Wm Announcement of IPSec Bakeoff Opportunity Mon-Thurs, Aug 31st- Sept 3 Microsoft Main Campus, Olympic Room in bldg. 27S Redmond, WA Contents: 1. Purpose - Criteria 2. Proposed functionality testing 3. Proposed daily agenda 1. Purpose Provide IPSec vendor developers of the most complete IPSec implementations a small-scale, mixed vendor environment to further test IPSec interoperability for transport and tunneling, under load, across a variety of network topologies, including dialup, 100Mbit Ethernet and across Internet WAN links. To test attack resilience of IPSec implementations. To begin testing L2TP/IPSec interop. No press releases, just interop work. Wider interop shake out for base and extended families of ICSA v2.0 criteria. Increase consensus among IPSec vendors for how to solve some common deployment problems and prepare for IBM's full bakeoff in October. Due to the small facility, I'd like to prioritize for those who can negotiate and perform ALL of the following functionality: IKE - Negotiate and perform - Multiple auth method proposals - Certificate authentication and certificate request payloads - Dynamic rekey with PFS for both main mode and quick mode - Selectors (filters) to the IPaddress, IP Subnet, and port IPSec - ESP with 56bitDES, null-ESP, MD5 and SHA1 - Transport and tunnel mode Implementations should also have IKE - AND proposal - SA delete payload - Lifetimes in both bytes and times - Group 2 DH with 3DES - 512bit DH or explicit p & g IPSec - Protocol and port filters - L2TP/IPSec integration - AH with MD5 and SHA1 - AH+ESP combination - ESP 3DES - ESP 40bitDES 2. IPSec Functionality Testing 1. Basic interop on combinations 2. Certificate Infrastructure - Cert Server certificates from: Entrust, Microsoft, Verisign, Netscape - Cert trust verification using hierarchy in PKI infrastructures - Using CRLs during cert validation ? - Timing of IKE successful/unsuccessful negotiation using certs, how transparent for end-to-end? 3. IKE retransmit behavior 4. Export <-> Export, Export <-> Domestic - Basic IKE and IPSec tests - Explicit p&g DH with 40bit DES 5. IKE commit bit 6. Throughput & number of simultaneous negotiations performance testing against different implementations 7. Reboot recovery (peer reboot losing it's security associations) 8. Scenarios - - End-to-End transport long lived security associations (over night, data transfer >1Gb) with frequent dynamic rekey - End-to-GW tunnel long lived security associations (over night, data transfer >1Gb) with frequent dynamic rekey - Policy change events while under SA load - End-to-End SA through IPSec tunnels, initiation both ways - Client End-to-End through client-to-GW tunnel SA, initiate from client for tunnel, then initiation both ways for end-to-end - Client-to-GW transport SA for secure management 9. Multiple auth method proposals and AND proposal 10. Discuss reliability requirements for SA establishment, maintenance under load, heavy fragmentation, packet corruption, packet loss 3. Schedule Monday evening Aug 31 - we may actually be able to setup on Sunday, not sure yet, which would make this a full testing day 12:00-17:00 - Room and Network Setup 15:00-17:00 - Shipping deliveries from MS Receiving to bldg. 27/Olympic Room 17:00-22:00 - Vendor equipment drop off/setup Tuesday Sept 1st 7:30 - Room Opens, Catered continental bkfast 8:30 - Welcome, Agenda, Network Layout, Logistics 9:00 - Testing 12:30 - SyncUp Discussion with catered lunch 13:00-13:30 Overview of MS PKI 17:00 - ReSync Discussion 22:00 - Room closes for night Wednesday Sept 2nd 7:30 - Room Opens, Catered continental bkfast 8:30 - Agenda, Q& A 12:30 - SyncUp Discussion 13:00-13:30 Overview of IPSec policy in NT5.0 Active Directory 17:00 - SyncUp Discussion 22:00 - Room closes for night Thursday Sept 3rd 7:30 - Room Opens, Catered continental bkfast 8:30 - Agenda, Q& A 12:30 - 13:30 - SyncUp Discussion 17:00 - Vendor Equip load Out 19:00 - Network pulled up 21:00 - Turnover to facilities management for next day Friday Sept 4th - Event notes typed up and released to IETF IPSec list & participants Wm William Dixon, 425-703-8729, wdixon@microsoft.com Program Manager, Internet Protocol Security PBS Windows Networking & Communications Microsoft Corporation From owner-ipsec Tue Aug 4 13:24:49 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA29741 for ipsec-outgoing; Tue, 4 Aug 1998 13:24:34 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Tue, 04 Aug 1998 11:40:58 -0600 From: "Umesh Muniyappa" To: Subject: IPSec and Filtering Question? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id NAA29738 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, If IPSec and Firewall (filtering) is on the same box (security gateway), what is the order of processing for both inbound and outbound packets? Should the filtering rules be applied first and then IPSec? If it has been discussed in the group, please let me know. thanks for any input. umesh From owner-ipsec Tue Aug 4 14:26:31 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA00283 for ipsec-outgoing; Tue, 4 Aug 1998 14:20:45 -0400 (EDT) Message-Id: <3.0.5.32.19980804143639.009bb8a0@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 04 Aug 1998 14:36:39 -0400 To: Greg Carter , "'ipsec@tis.com'" , "'William Dixon'" From: Robert Moskowitz Subject: RE: IPSec interop workshop Aug 31st - Sept 3 invitation Cc: "'ipsec@icsa.net'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 11:12 AM 8/4/98 -0400, Greg Carter wrote: Details for this (week of Oct 26th) will be coming out by the end of the week. I am working with IBM to finalize details. >What about the previously announced IBM workshop in the fall? > > >> ICSA in conjunction with IBM are planning the next IPsec workshop. >> >> The date we have been able to get is the week of Oct 26th. The host is >> IBM's AS/400 Endicott group and they will be hosting it at Holiday Inn >> Arena, Binghamton, New York. We are working out the site details. >> >> Why YAW? >> >> CA interoperablity. >> >> I am working on significant CA participation. Got a couple items in the >> works that should be announced next month. >> >> IPPCP -- Remote clients, ya know? >> >> Remote client support. >> >> I hope we can set direction for remote client support and do at least some >> engineering level work with whatever direction gets set. >> >> Complex architecture. >> >> Transport within tunnels. NAT traversal. Mobile gateways. Other >> nasties. >> >> And of course new comers and others. >> >> Although non IPsec developers are welcome to come, They should develop a >> test plan to help the developers. Time for this around Chicago time. >> >> >> Anyway. That is the date and location. I will soon be announcing how to >> get in touch for reservations and workshop planning. >> >> >> >> >> Robert Moskowitz >> ICSA >> Security Interest EMail: rgm-sec@htt-consult.com >> >---- >Greg Carter, Entrust Technologies >greg.carter@entrust.com > > >> ---------- >> From: William Dixon[SMTP:wdixon@microsoft.com] >> Sent: Tuesday, August 04, 1998 5:17 AM >> To: 'ipsec@tis.com' >> Subject: IPSec interop workshop Aug 31st - Sept 3 invitation >> >> I am concerned that we are not having enough opportunities for >> comprehensive >> and/or sophisticated interoperability testing. So I'd like to offer one >> during the week after the IETF (not great timing I know). I've got room >> for >> about 30 people plus equipment. So please "r" me if interested and give >> me >> a few days to respond. I'd like someone from ICSA to attend also. By the >> end of the week I hope to have enough responses to determine if it will be >> worthwhile. Thanks, -Wm >> >> >> Announcement of IPSec Bakeoff Opportunity >> Mon-Thurs, Aug 31st- Sept 3 >> Microsoft Main Campus, Olympic Room in bldg. 27S >> Redmond, WA >> >> Contents: >> 1. Purpose - Criteria >> 2. Proposed functionality testing >> 3. Proposed daily agenda >> >> 1. Purpose >> Provide IPSec vendor developers of the most complete IPSec implementations >> a >> small-scale, mixed vendor environment to further test IPSec >> interoperability >> for transport and tunneling, under load, across a variety of network >> topologies, including dialup, 100Mbit Ethernet and across Internet WAN >> links. To test attack resilience of IPSec implementations. To begin >> testing L2TP/IPSec interop. No press releases, just interop work. Wider >> interop shake out for base and extended families of ICSA v2.0 criteria. >> Increase consensus among IPSec vendors for how to solve some common >> deployment problems and prepare for IBM's full bakeoff in October. >> >> Due to the small facility, I'd like to prioritize for those who can >> negotiate and perform ALL of the following functionality: >> IKE - Negotiate and perform >> - Multiple auth method proposals >> - Certificate authentication and certificate request payloads >> - Dynamic rekey with PFS for both main mode and quick mode >> - Selectors (filters) to the IPaddress, IP Subnet, and port >> IPSec >> - ESP with 56bitDES, null-ESP, MD5 and SHA1 >> - Transport and tunnel mode >> >> Implementations should also have >> IKE >> - AND proposal >> - SA delete payload >> - Lifetimes in both bytes and times >> - Group 2 DH with 3DES >> - 512bit DH or explicit p & g >> >> IPSec >> - Protocol and port filters >> - L2TP/IPSec integration >> - AH with MD5 and SHA1 >> - AH+ESP combination >> - ESP 3DES >> - ESP 40bitDES >> >> 2. IPSec Functionality Testing >> 1. Basic interop on combinations >> 2. Certificate Infrastructure >> - Cert Server certificates from: Entrust, Microsoft, Verisign, >> Netscape >> - Cert trust verification using hierarchy in PKI infrastructures >> - Using CRLs during cert validation ? >> - Timing of IKE successful/unsuccessful negotiation using certs, how >> transparent for end-to-end? >> 3. IKE retransmit behavior >> 4. Export <-> Export, Export <-> Domestic >> - Basic IKE and IPSec tests >> - Explicit p&g DH with 40bit DES >> 5. IKE commit bit >> 6. Throughput & number of simultaneous negotiations performance testing >> against different implementations >> 7. Reboot recovery (peer reboot losing it's security associations) >> 8. Scenarios - >> - End-to-End transport long lived security associations (over night, >> data transfer >1Gb) with frequent dynamic rekey >> - End-to-GW tunnel long lived security associations (over night, >> data transfer >1Gb) with frequent dynamic rekey >> - Policy change events while under SA load >> - End-to-End SA through IPSec tunnels, initiation both ways >> - Client End-to-End through client-to-GW tunnel SA, initiate from >> client for tunnel, then initiation both ways for end-to-end >> - Client-to-GW transport SA for secure management >> 9. Multiple auth method proposals and AND proposal >> 10. Discuss reliability requirements for SA establishment, maintenance >> under >> load, heavy fragmentation, packet corruption, packet loss >> >> 3. Schedule >> Monday evening Aug 31 - we may actually be able to setup on Sunday, not >> sure >> yet, which would make this a full testing day >> 12:00-17:00 - Room and Network Setup >> 15:00-17:00 - Shipping deliveries from MS Receiving to bldg. 27/Olympic >> Room >> 17:00-22:00 - Vendor equipment drop off/setup >> >> Tuesday Sept 1st >> 7:30 - Room Opens, Catered continental bkfast >> 8:30 - Welcome, Agenda, Network Layout, Logistics >> 9:00 - Testing >> 12:30 - SyncUp Discussion with catered lunch > > > > >> 13:00-13:30 Overview of MS PKI >> 17:00 - ReSync Discussion >> 22:00 - Room closes for night >> >> Wednesday Sept 2nd >> 7:30 - Room Opens, Catered continental bkfast >> 8:30 - Agenda, Q& A >> 12:30 - SyncUp Discussion >> 13:00-13:30 Overview of IPSec policy in NT5.0 Active Directory >> 17:00 - SyncUp Discussion >> 22:00 - Room closes for night >> >> Thursday Sept 3rd >> 7:30 - Room Opens, Catered continental bkfast >> 8:30 - Agenda, Q& A >> 12:30 - 13:30 - SyncUp Discussion >> 17:00 - Vendor Equip load Out >> 19:00 - Network pulled up >> 21:00 - Turnover to facilities management for next day >> >> Friday Sept 4th - Event notes typed up and released to IETF IPSec list & >> participants >> >> >> Wm >> William Dixon, 425-703-8729, wdixon@microsoft.com >> Program Manager, Internet Protocol Security >> PBS Windows Networking & Communications >> Microsoft Corporation >> > Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Tue Aug 4 16:27:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA01181 for ipsec-outgoing; Tue, 4 Aug 1998 16:25:39 -0400 (EDT) From: avs@winner.lc.lucent.com Message-ID: <35C76C69.4ED33961@winner.lc.lucent.com> Date: Tue, 04 Aug 1998 16:17:45 -0400 Original-From: Sashidhar Annaluru Organization: Lucent Technologies X-Mailer: Mozilla 4.05 [en]C-EMS-1.4 (WinNT; U) MIME-Version: 1.0 To: ipsec@tis.com Subject: A question about the IKE phase2 proposals Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi All, I am reffering to the "The Internet Key Exchange" document. In section 5.5 Phase2 Quick mode it says: A single SA negotiation results in two security associations-- one inbound and one outbound. Different SPIs for each SA guarantee a different key for each direction. But this results having the same transforms in both the directions. Only the initiator sends the list of proposals and responder needs to choose one. If we want two different transforms for each direction what needs to be done? Can any body explain me about this? Thanks in advance Sashidhar V Annaluru (908)-580-8014 avs@winner.lc.lucent.com From owner-ipsec Tue Aug 4 16:35:12 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA01278 for ipsec-outgoing; Tue, 4 Aug 1998 16:34:45 -0400 (EDT) Date: Tue, 4 Aug 1998 16:50:17 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: IPSec and Filtering Question? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > If IPSec and Firewall (filtering) is on the same box (security > gateway), what is the order of processing for both inbound and outbound > packets? Should the filtering rules be applied first and then IPSec? Note that good firewalls do not have just one layer of filtering, so the right answer is probably "both". However, the IPSEC SPD might be deemed sufficiently powerful to make some of the filtering superfluous, e.g. an incoming encrypted packet from the insecure side will face stringent checking in IPSEC anyway. There is also rather limited benefit in filtering encrypted packets, since so little is known about them. If one wishes to filter in just one place in a security gateway, the secure side (where the packets are plaintext and their innards are visible) would seem the right place to do it. So packets bound for the insecure side get filtered before they enter IPSEC, and packets bound for the secure side get filtered after they emerge from IPSEC. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec Tue Aug 4 21:00:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA02879 for ipsec-outgoing; Tue, 4 Aug 1998 20:59:44 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199808050117.SAA09748@kc.livingston.com> Subject: Re: A question about the IKE phase2 proposals To: avs@winner.lc.lucent.com Date: Tue, 4 Aug 1998 18:17:11 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <35C76C69.4ED33961@winner.lc.lucent.com> from "avs@winner.lc.lucent.com" at Aug 4, 98 04:17:45 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Hi All, > I am reffering to the "The Internet Key Exchange" document. > > In section 5.5 Phase2 Quick mode it says: > > A single SA negotiation results in two security associations-- one inbound and > one outbound. Different SPIs for each SA guarantee a different key for each > direction. > > But this results having the same transforms in both the directions. Only the > initiator sends the list of proposals and responder needs to choose one. > > If we want two different transforms for each direction what needs to be done? > > Can any body explain me about this? > As far as I can tell, IKE protocol does not permit transforms to be different in either direction. They MUST be the same for both peers. I guess, This is not stated explicitly in the draft. > Thanks in advance > Sashidhar V Annaluru > (908)-580-8014 > avs@winner.lc.lucent.com > > cheers, suresh From owner-ipsec Tue Aug 4 21:00:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA02888 for ipsec-outgoing; Tue, 4 Aug 1998 21:00:44 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Tue, 04 Aug 1998 19:16:39 -0600 From: "Umesh Muniyappa" To: , Subject: Re: IPSec and Filtering Question? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id VAA02885 Sender: owner-ipsec@ex.tis.com Precedence: bulk >>If one wishes to filter in just one place in a security >>gateway, the secure side (where the packets are plaintext and their >>innards are visible) would seem the right place to do it. So packets >>bound for the insecure side get filtered before they enter IPSEC, and >>packets bound for the secure side get filtered after they emerge from >>IPSEC. If the filtering is applied before IPSEC on packets bound for insecure side, won't the filtering rules block the packets though there is an SA to that destination. For example, I want to block all FTP traffic from the secure side to insecure side (internet) and allow only the IPSEC packets to go to insecure side. Now I want the FTP traffic to go through the IPSec Tunnel to the other Secure Gateway. Here, if filtering is applied first and then IPSEC, then all the FTP traffic gets blocked. On the other hand, if IPSEC was applied first and then filtering, then only non-ipsec ftp packets gets dropped. Any suggestions on this issue. thanks umesh From owner-ipsec Wed Aug 5 10:52:42 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA06124 for ipsec-outgoing; Wed, 5 Aug 1998 10:49:58 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 5 Aug 1998 10:51:04 -0400 To: "Umesh Muniyappa" From: Stephen Kent Subject: Re: IPSec and Filtering Question? Cc: Sender: owner-ipsec@ex.tis.com Precedence: bulk Umesh, >If IPSec and Firewall (filtering) is on the same box (security gateway), >what is the order of processing for both inbound and outbound packets? >Should the filtering rules be applied first and then IPSec? IPsec does not require that a separate set of filters be applied to traffic if a unified implementation already provides the requisite features described for the SPD. So, a product which combines IPsec and a (more full featured) firewall would be compliant if it provided a superset of the features mandated by the SPD. The SPD is a performance requirement, not a design requirement. A product must perform in a fashion that is equivalent to what the SPD does but one does not have to implement an SPD per se. Steve From owner-ipsec Wed Aug 5 12:54:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA06639 for ipsec-outgoing; Wed, 5 Aug 1998 12:49:14 -0400 (EDT) Message-Id: <199808051705.KAA18860@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: commit bit processing MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18858.902336708.1@cisco.com> Date: Wed, 05 Aug 1998 10:05:08 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk More inconsistencies....sigh. The base ISAKMP draft contains some contradictory language concerning the use of the commit bit. In discussions with other vendors about how they interpreted the contradictions the following theme came out: if the commit bit is set in a phase 1 exchange send back INVALID_FLAGS and regardless of who set the bit (initiator or responder) the responder sends the CONNECTED message back as the final message. Yes, that's not 100% compliant with what the draft (RFC?) says but it is impossible to be 100% compliant. And since it doesn't make any sense to send a COMMIT in a phase 1 exchange it doesn't make any sense to support that. But! Another conflict has arisen. Two vendors interpreted the aforementioned contradictory text the same way but still do not interoperate. One vendor read the ISAKMP text where it says that the CONNECTED message is sent in an Informational Exchange with the message ID of the phase 2 (Quick Mode Exchange) to which it applies and then read IKE where it says all Informational Exchanges must have a unique message ID. Weighing these two issues and since the state that's waiting around for this message is part of the Quick Mode, this vendor implemented his IKE to expect the CONNECTED notify in a message whose exchange is Quick Mode. Another vendor read the same text and tried to be as faithful as possible to the ISAKMP draft and sends the CONNECTED notify in an Informational Exchange with the message ID of the Quick Mode, and has plumbing to clean up the right Quick Mode state with the Informational message. Can those of you who've implemented the COMMIT bit in your code announce how you've done it. The text in one or both of those drafts (RFCs?) has got to change and it really doesn't matter how, whether the first vendor or the second vendor ends up changing his code isn't important. It would just be nice to get a feeling on how the WG wants to go and how the drafts (RFCs?) will eventually get rewritten to be consistent so that one of these guys can change his code. So, which way is right? Informational or Quick Mode? Dan. From owner-ipsec Wed Aug 5 17:46:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA07423 for ipsec-outgoing; Wed, 5 Aug 1998 17:44:38 -0400 (EDT) From: "Catherine A. Meadows" Date: Wed, 5 Aug 1998 18:00:39 -0400 (EDT) Message-Id: <199808052200.SAA04178@liverwurst.itd.nrl.navy.mil> To: ipsec@tis.com Subject: Questions about use of AH and ESP in IKE Cc: meadows@itd.nrl.navy.mil X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk I've been working on a formal analysis of IKE. Some questions have come up about the way it uses the protocols (AH,ESP,etc.) that are specified in the SAs. In particular, I'd like to know 1. Is the set of protocols currently supported by ISAKMP open-ended, or is it limited to AH and ESP? 2. Suppose that I'm sending the last message in a main mode phase one exchange, or a message in a phase two exchange, and that I'm using AH or ESP as the protocol. Since I'm using a phase one SA, it's identified by a pair of cookies instead of by a SPI. What do I put in the SPI field of the AH or ESP header? Both cookies? One of the cookies? If so, which one? 3. In a phase two exchange, it is possible to either transmit identities explicitly, or not to transmit them and use the IP addresses as implicit identities. If I'm doing the latter, does it ever make sense to use AH or ESP in transport mode to encrypt the messages in the phase two exchange? Thanks in advance, Cathy Meadows Naval Research Laboratory From owner-ipsec Wed Aug 5 20:19:11 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA07838 for ipsec-outgoing; Wed, 5 Aug 1998 20:18:41 -0400 (EDT) Message-ID: <35C8F77E.D2AB6301@ire-ma.com> Date: Wed, 05 Aug 1998 20:23:27 -0400 From: Bronislav Kavsan X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: Daniel Harkins CC: ipsec@tis.com Subject: Re: commit bit processing References: <199808051705.KAA18860@dharkins-ss20.cisco.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 Dan, As you mentioned - both implementations have to violate existing darft-standards, which I am sure will change to accomodate this oversight. >From the ease of the implementation standpoint - I suggest to do it as a part of the QM exchange - it is also more logical to "connect" CONNECTED message to the QM exchange just concluded. Also, the current logic of IV calculation for Informational Exchanges - is simply to calculate a brand new IV for each Informational Exchange - because they have unique message IDs. I think it is easier to leave this rule and logic as is. Otherwise some Informational Exchanges have to be decrypted with running QM IVs and some with the newly calculated IVs. And by the way - this is our implementation :), even though at the moment we do not rely on receiving CONNECTED message. Slava IRE Daniel Harkins wrote: > More inconsistencies....sigh. > > The base ISAKMP draft contains some contradictory language concerning the > use of the commit bit. In discussions with other vendors about how they > interpreted the contradictions the following theme came out: if the commit > bit is set in a phase 1 exchange send back INVALID_FLAGS and regardless of > who set the bit (initiator or responder) the responder sends the CONNECTED > message back as the final message. Yes, that's not 100% compliant with what > the draft (RFC?) says but it is impossible to be 100% compliant. And since > it doesn't make any sense to send a COMMIT in a phase 1 exchange it doesn't > make any sense to support that. > > But! Another conflict has arisen. Two vendors interpreted the aforementioned > contradictory text the same way but still do not interoperate. One vendor > read the ISAKMP text where it says that the CONNECTED message is sent in an > Informational Exchange with the message ID of the phase 2 (Quick Mode > Exchange) to which it applies and then read IKE where it says all > Informational Exchanges must have a unique message ID. Weighing these two > issues and since the state that's waiting around for this message is part of > the Quick Mode, this vendor implemented his IKE to expect the CONNECTED > notify in a message whose exchange is Quick Mode. Another vendor read the > same text and tried to be as faithful as possible to the ISAKMP draft and > sends the CONNECTED notify in an Informational Exchange with the message ID > of the Quick Mode, and has plumbing to clean up the right Quick Mode state > with the Informational message. > > Can those of you who've implemented the COMMIT bit in your code announce > how you've done it. The text in one or both of those drafts (RFCs?) has got > to change and it really doesn't matter how, whether the first vendor or the > second vendor ends up changing his code isn't important. It would just be > nice to get a feeling on how the WG wants to go and how the drafts (RFCs?) > will eventually get rewritten to be consistent so that one of these guys > can change his code. So, which way is right? Informational or Quick Mode? > > Dan. From owner-ipsec Wed Aug 5 22:19:38 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA08036 for ipsec-outgoing; Wed, 5 Aug 1998 22:18:43 -0400 (EDT) Message-Id: <199808060235.TAA23868@gallium.network-alchemy.com> To: Bronislav Kavsan cc: Daniel Harkins , ipsec@tis.com Subject: Re: commit bit processing In-reply-to: Your message of "Wed, 05 Aug 1998 20:23:27 EDT." <35C8F77E.D2AB6301@ire-ma.com> Date: Wed, 05 Aug 1998 19:35:16 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk I agree that it's more logical under the QM exchange (since it's probably a QM state in your state machine and it uses the QM message ID). My implementation currently sends it under as an Informational, but I'm happy to change. Derrell From owner-ipsec Thu Aug 6 09:14:07 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA09889 for ipsec-outgoing; Thu, 6 Aug 1998 09:12:53 -0400 (EDT) Message-Id: <199808061329.JAA04928@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-arch-sec-07.txt Date: Thu, 06 Aug 1998 09:29:49 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart Note: This revision reflects comments received during the last call period. 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 Architecture for the Internet Protocol Author(s) : S. Kent, R. Atkinson Filename : draft-ietf-ipsec-arch-sec-07.txt Pages : 66 Date : 05-Aug-98 This memo specifies the base architecture for IPsec compliant systems. The goal of the architecture is to provide various security services for traffic at the IP layer, in both the IPv4 and IPv6 environments. This document describes the goals of such systems, their components and how they fit together with each other and into the IP environment. It also describes the security services offered by the IPsec protocols, and how these services can be employed in the IP environment. This document does not address all aspects of IPsec architecture. Subsequent documents will address additional architectural details of a more advanced nature, e.g., use of IPsec in NAT environments and more complete support for IP multicast. The following fundamental components of the IPsec security architecture are discussed in terms of their underlying, required functionality. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-arch-sec-07.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-arch-sec-07.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-arch-sec-07.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: <19980805165330.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-arch-sec-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-arch-sec-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980805165330.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Thu Aug 6 09:14:07 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA09880 for ipsec-outgoing; Thu, 6 Aug 1998 09:11:56 -0400 (EDT) Message-Id: <199808061327.JAA04620@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-gkmframework-00.txt Date: Thu, 06 Aug 1998 09:27:55 -0400 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 : A Framework for Group Key Management for Multicast Security Author(s) : N. Doraswamy, B. Cain, T. Hardjono Filename : draft-ietf-ipsec-gkmframework-00.txt Pages : 23 Date : 05-Aug-98 This document provides a framework for group key management for multicast security, motivated by three main considerations, namely the multicast application, scalability and trust-relationships among entities. It introduces two planes corresponding to the network entities and functions important to multicasting and to security. The key management plane consists of two hierarchy-levels in the form of a single 'trunk region' (inter-region) and one or more 'leaf regions' (intra-region). These regions are defined to have unique group keys and are open to differing (inter-region or intra-region) group key management protocols. The advantages of the framework among others are that it is scalable, it has reduced complexity and allows the independence in regions of group key management. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-gkmframework-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-gkmframework-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-gkmframework-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: <19980805133845.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-gkmframework-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-gkmframework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980805133845.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Thu Aug 6 15:58:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA11144 for ipsec-outgoing; Thu, 6 Aug 1998 15:52:19 -0400 (EDT) From: gmd@openroute.com (Gina DePlanche) Message-Id: <9808062009.AA28829@banacek.proteon.com> Subject: ESP payload type To: ipsec@tis.com Date: Thu, 6 Aug 1998 16:09:42 -0400 (EDT) Cc: mrk@openroute.com (Michael Kerrigan) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Please excuse me if this is a duplicate question. In RFC 1829, the payload format in section 2 calls for a one octet payload type. Will this field have the same value regardless of whether the original packet has been compressed? If so, how can one determine if the encrypted packet has been compressed. If not, what are the values for the payload type for compressed and uncompressed packets? Thanks in advance for the help! - Gina -- Gina M. DePlanche | OpenROUTE Networks, Inc. gmd@openroute.com | 9 Technology Drive, Westborough, MA (508) 898-2800 x2541 | 01581-1799 MailStop #23 Fax: (508) 836-5347 | http://www.openroute.com From owner-ipsec Thu Aug 6 17:13:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA11390 for ipsec-outgoing; Thu, 6 Aug 1998 17:09:18 -0400 (EDT) Message-ID: From: William Dixon To: "'ipsec@tis.com'" Cc: William Dixon Subject: RE: IPSec interop workshop Aug 31st - Sept 3 invitation Date: Thu, 6 Aug 1998 14:25:48 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks please get back to me by Friday if you haven't yet. I'd like to make a call this weekend if this is going to happen. I have about 6-7 vendors plus others already so it looks good. It can be just one developer if you're strapped with other events (SIGCOMM, AutoNet, life, etc.) Thanks, -Wm -----Original Message----- From: William Dixon [mailto:wdixon@microsoft.com] Sent: Tuesday, August 04, 1998 10:35 AM To: 'ipsec@tis.com' Subject: RE: IPSec interop workshop Aug 31st - Sept 3 invitation My apologies to IBM and everyone for not making one point clear. I fully support the already announced IBM bakeoff in late October and we will attend. The invitation I sent is another opportunity, 6 weeks earlier, to help vendors work out interop issues. Particularly it will be hard for me to make changes in November/Dec and I'd like to ship something people won't have to many problems interoping with as they move forward in their implementations. -Wm -----Original Message----- From: William Dixon [mailto:wdixon@microsoft.com] Sent: Tuesday, August 04, 1998 2:17 AM To: 'ipsec@tis.com' Subject: IPSec interop workshop Aug 31st - Sept 3 invitation I am concerned that we are not having enough opportunities for comprehensive and/or sophisticated interoperability testing. So I'd like to offer one during the week after the IETF (not great timing I know). I've got room for about 30 people plus equipment. So please "r" me if interested and give me a few days to respond. I'd like someone from ICSA to attend also. By the end of the week I hope to have enough responses to determine if it will be worthwhile. Thanks, -Wm Announcement of IPSec Bakeoff Opportunity Mon-Thurs, Aug 31st- Sept 3 Microsoft Main Campus, Olympic Room in bldg. 27S Redmond, WA Contents: 1. Purpose - Criteria 2. Proposed functionality testing 3. Proposed daily agenda 1. Purpose Provide IPSec vendor developers of the most complete IPSec implementations a small-scale, mixed vendor environment to further test IPSec interoperability for transport and tunneling, under load, across a variety of network topologies, including dialup, 100Mbit Ethernet and across Internet WAN links. To test attack resilience of IPSec implementations. To begin testing L2TP/IPSec interop. No press releases, just interop work. Wider interop shake out for base and extended families of ICSA v2.0 criteria. Increase consensus among IPSec vendors for how to solve some common deployment problems and prepare for IBM's full bakeoff in October. Due to the small facility, I'd like to prioritize for those who can negotiate and perform ALL of the following functionality: IKE - Negotiate and perform - Multiple auth method proposals - Certificate authentication and certificate request payloads - Dynamic rekey with PFS for both main mode and quick mode - Selectors (filters) to the IPaddress, IP Subnet, and port IPSec - ESP with 56bitDES, null-ESP, MD5 and SHA1 - Transport and tunnel mode Implementations should also have IKE - AND proposal - SA delete payload - Lifetimes in both bytes and times - Group 2 DH with 3DES - 512bit DH or explicit p & g IPSec - Protocol and port filters - L2TP/IPSec integration - AH with MD5 and SHA1 - AH+ESP combination - ESP 3DES - ESP 40bitDES 2. IPSec Functionality Testing 1. Basic interop on combinations 2. Certificate Infrastructure - Cert Server certificates from: Entrust, Microsoft, Verisign, Netscape - Cert trust verification using hierarchy in PKI infrastructures - Using CRLs during cert validation ? - Timing of IKE successful/unsuccessful negotiation using certs, how transparent for end-to-end? 3. IKE retransmit behavior 4. Export <-> Export, Export <-> Domestic - Basic IKE and IPSec tests - Explicit p&g DH with 40bit DES 5. IKE commit bit 6. Throughput & number of simultaneous negotiations performance testing against different implementations 7. Reboot recovery (peer reboot losing it's security associations) 8. Scenarios - - End-to-End transport long lived security associations (over night, data transfer >1Gb) with frequent dynamic rekey - End-to-GW tunnel long lived security associations (over night, data transfer >1Gb) with frequent dynamic rekey - Policy change events while under SA load - End-to-End SA through IPSec tunnels, initiation both ways - Client End-to-End through client-to-GW tunnel SA, initiate from client for tunnel, then initiation both ways for end-to-end - Client-to-GW transport SA for secure management 9. Multiple auth method proposals and AND proposal 10. Discuss reliability requirements for SA establishment, maintenance under load, heavy fragmentation, packet corruption, packet loss 3. Schedule Monday evening Aug 31 - we may actually be able to setup on Sunday, not sure yet, which would make this a full testing day 12:00-17:00 - Room and Network Setup 15:00-17:00 - Shipping deliveries from MS Receiving to bldg. 27/Olympic Room 17:00-22:00 - Vendor equipment drop off/setup Tuesday Sept 1st 7:30 - Room Opens, Catered continental bkfast 8:30 - Welcome, Agenda, Network Layout, Logistics 9:00 - Testing 12:30 - SyncUp Discussion with catered lunch 13:00-13:30 Overview of MS PKI 17:00 - ReSync Discussion 22:00 - Room closes for night Wednesday Sept 2nd 7:30 - Room Opens, Catered continental bkfast 8:30 - Agenda, Q& A 12:30 - SyncUp Discussion 13:00-13:30 Overview of IPSec policy in NT5.0 Active Directory 17:00 - SyncUp Discussion 22:00 - Room closes for night Thursday Sept 3rd 7:30 - Room Opens, Catered continental bkfast 8:30 - Agenda, Q& A 12:30 - 13:30 - SyncUp Discussion 17:00 - Vendor Equip load Out 19:00 - Network pulled up 21:00 - Turnover to facilities management for next day Friday Sept 4th - Event notes typed up and released to IETF IPSec list & participants Wm William Dixon, 425-703-8729, wdixon@microsoft.com Program Manager, Internet Protocol Security PBS Windows Networking & Communications Microsoft Corporation From owner-ipsec Fri Aug 7 07:26:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA13115 for ipsec-outgoing; Fri, 7 Aug 1998 07:23:29 -0400 (EDT) Message-ID: <35CAE7D5.D611727D@Certicom.com> Date: Fri, 07 Aug 1998 07:41:09 -0400 From: Yuri Poeluev Organization: Certicom Corp. X-Mailer: Mozilla 4.01 [en] (WinNT; U) MIME-Version: 1.0 To: Internet-Drafts@ietf.org CC: "IETF-Announce:;;;;;@tis.com"@tis.com;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;, ipsec@tis.com Subject: Re: I-D ACTION:draft-shima-ipsec-isakmp-cke-type-00.txt X-Priority: 3 (Normal) References: <199808031842.OAA23332@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, In the section 3.4, the second message description repeates the first message description. "Initiator" should be replaced by "responder", since the second message is sent by "responder" in the protocol. I think, the author simply copied that part from previous paragraph. Yuri Poeluev Certicom Corp. E-mail: ypoeluev@certicom.com Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : ISAKMP Certificate Key Exchange Type > Specification > Author(s) : S. Shima > Filename : draft-shima-ipsec-isakmp-cke-type-00.txt > Pages : 8 > Date : 31-Jul-98 > > This document defines a new key exchange type of ISAKMP that reduce > > the number of transmission and encrypt message contents from first > transmission. > > The Certificate Key Exchange is effective since it does not use > Diffie-Hellman key exchange algorithm but public key cryptography. > The Certificate Key Exchange use certificates as authentication > information. Please send comments on this document to the > ipsec@tis.com. > > Internet-Drafts are available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-shima-ipsec-isakmp-cke-type-00.txt". > A URL for the Internet-Draft is: > ftp://ftp.ietf.org/internet-draf > s/draft-shima-ipsec-isakmp-cke-type-00.txt > > Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ftp.ietf.org > > US West Coast: ftp.isi.edu > > Internet-Drafts are also available by mail. > > Send a message to: mailserv@ietf.org. In the body type: > "FILE > /internet-drafts/draft-shima-ipsec-isakmp-cke-type-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. > > > ------------------------------------------------------------------------------------------------------------- > > > > > > From owner-ipsec Fri Aug 7 09:15:23 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA13687 for ipsec-outgoing; Fri, 7 Aug 1998 09:13:26 -0400 (EDT) Message-Id: <199808061934.PAA19045@ietf.org> To: IETF-Announce:;;;;;;;@tis.com@tis.com;;;@tis.com;;;;;;@tis.com;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipsec@tis.com From: The IESG Subject: Protocol Action: Security Architecture for the Internet Protocol to Proposed Standard Date: Thu, 06 Aug 1998 15:34:34 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk The IESG has approved publication of the following Internet-Drafts as Proposed Standard: o Security Architecture for the Internet Protocol o IP Authentication Header o The Use of HMAC-MD5-96 within ESP and AH o The Use of HMAC-SHA-1-96 within ESP and AH o The ESP DES-CBC Cipher Algorithm With Explicit IV o IP Encapsulating Security Payload (ESP) o The Internet IP Security Domain of Interpretation for ISAKMP o Internet Security Association and Key Management Protocol (ISAKMP) o The Internet Key Exchange (IKE) o The NULL Encryption Algorithm and Its Use With IPsec In the same action, the IESG also approved publication of the following Internet-Drafts as Informational RFCs: o IP Security Protocol Working Group to consider IP Security Document Roadmap o The OAKLEY Key Determination Protocol These documents are the product of the IP Security Protocol Working Group. The IESG contact persons are Jeffrey Schiller and Marcus Leech. Technical Summary These documents define a protocol for providing security services at the IP (network) layer. Included are the basic packet formats, per packet processing logic and key agreement and exchange methodology. Working Group Summary The IPSEC working group came to rough consensus around this set of documents after numerous and often difficult debates. Consensus is clear, however on the following points: * We need to deploy IP security now. * The protocol described works and is believed to be secure. * There is a market and demand for security at the IP layer. Protocol Quality The chief criticism of the work defined here is its complexity. However complexity may not be avoidable in an attempt to provide general purpose IP layer security protocol suite that can be used in many situations, including those that scale to the size of the global Internet. Multiple interoperable implementations of the protocol(s) described here have been tested and some are in deployment. Summary of Last Call Comments and AD Response Two significant issues were raised during IETF Last Call. They are: * The Authentication Header (AH) protocol could have been designed differently so to make it easier to implement on some hardware platforms. Response: Like many solutions to an engineering challenge, there are often many approaches that may be chosen. Comparing options and selecting the best is often influenced to the details of a particular problem and the viewpoint of the engineer. The IPSEC working group selected a particular solution and working group participants have invested significant effort in defining it and in implementing it. The comments raised in last call do not point to an obvious protocol defect, but instead to a trade-off which the commenter would have made in a way different then the working group. This was discussed explicitly at the IPSEC working group meeting on April 3, 1998 and the consensus of the working group was that AH should remain unchanged for now. I concur with this reasoning. * IPSEC when used with encryption (ESP) makes it impossible for network monitoring tools to learn the TCP port numbers of Internet traffic so encrypted. Similarly performance enhancing schemes (such as ACK "spoofing") cannot be successful in the presence of IPSEC enhancements. Response: This is not a defect in the protocols. Making packet tampering and disclosure hard is exactly the goal of IPSEC! However there does exist the higher level architectural question of how the trade-off is made between security and the performance enhancements that may be achieved by the technologies rendered difficult by the presence of IPSEC. In situations where packet modification, such as ACK spoofing, may result in performance gains, end-users will have to decide whether they wish to sacrifice potential performance gains in favor of security. Ultimately techniques need to be developed that permit security while still providing appropriate performance. This work is beyond the scope of the IPSEC working group and should not hinder the progress of the work charted for the IPSEC working group. In summary, I have considered the various Last Call comments and have concluded that it is in the best interested of the Internet Community for these documents to progress of Proposed Standard Status. The IESG will look at the issue of acknowledgements and correct any errors of ommission before advancing these documents to Draft Status. -Jeff Schiller, Security co-AD Note to RFC Editor: The IESG requests the RFC Editor to make two changes in draft-ietf-ipsec-oakley-02.txt 1. The single occurance of MUST be lowercased. 2. Add the following to draft-ietf-ipsec-oakley-02.txt Security Considerations The focus of this document is security; hence security considerations permeate this memo. From owner-ipsec Fri Aug 7 10:13:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA14174 for ipsec-outgoing; Fri, 7 Aug 1998 10:12:33 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <9808062009.AA28829@banacek.proteon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 7 Aug 1998 10:27:14 -0400 To: gmd@openroute.com (Gina DePlanche) From: Stephen Kent Subject: Re: ESP payload type Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Gina, > In RFC 1829, the payload format in section 2 calls for a one >octet payload type. Will this field have the same value regardless of >whether the original packet has been compressed? If so, how can one >determine if the encrypted packet has been compressed. If not, what are >the values for the payload type for compressed and uncompressed packets? First, the newly approved IPsec documents are the relevant ones, not 1829. If compression has been negotiated and employed for an SA, then the appropriate protocol ID for IPCOMP will appear as the NEXT field in ESP, indicating that the next level of demuxing and processing is IPCOMP, vs. TCP, IP, etc. Steve P.S. The encrypted packet would not have been compressed; the plaintext would have been compressed and the result encrypted. From owner-ipsec Fri Aug 7 12:00:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA14632 for ipsec-outgoing; Fri, 7 Aug 1998 11:58:43 -0400 (EDT) Message-Id: <3.0.5.32.19980807121405.007e51d0@bl-mail2.corpeast.baynetworks.com> X-Sender: thardjon@bl-mail2.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Fri, 07 Aug 1998 12:14:05 -0400 To: ipsec@tis.com From: Internet-Drafts@ietf.org (by way of Thomas Hardjono ) Subject: I-D ACTION:draft-ietf-ipsec-gkmframework-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk 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 : A Framework for Group Key Management for Multicast Security Author(s) : T. Hardjono, B. Cain, N. Doraswamy Filename : draft-ietf-ipsec-gkmframework-00.txt Pages : 23 Date : 05-Aug-98 This document provides a framework for group key management for multicast security, motivated by three main considerations, namely the multicast application, scalability and trust-relationships among entities. It introduces two planes corresponding to the network entities and functions important to multicasting and to security. The key management plane consists of two hierarchy-levels in the form of a single 'trunk region' (inter-region) and one or more 'leaf regions' (intra-region). These regions are defined to have unique group keys and are open to differing (inter-region or intra-region) group key management protocols. The advantages of the framework among others are that it is scalable, it has reduced complexity and allows the independence in regions of group key management. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-gkmframework-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-gkmframework-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-gkmframework-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. Content-Type: text/plain Content-ID: <19980805133845.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-gkmframework-00.txt From owner-ipsec Fri Aug 7 12:10:06 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14702 for ipsec-outgoing; Fri, 7 Aug 1998 12:09:37 -0400 (EDT) Message-Id: <9808071630.AA17080@anuxc.mv.lucent.com> X-Sender: dac@anuxc.mv.lucent.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 07 Aug 1998 12:30:48 -0400 To: Yuri Poeluev From: Dave Clark Subject: Re: I-D ACTION:draft-shima-ipsec-isakmp-cke-type-00.txt Cc: ipsec@tis.com In-Reply-To: <35CAE7D5.D611727D@Certicom.com> References: <199808031842.OAA23332@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk In draft-shima-ipsec-isakmp-cke-type-00.txt, the author refers to a document which "defines processes for handling IPSEC certificates, including fulfillment, retrieval, validation, and management...." He says this document is draft-thayer-ipsec-pki-00.txt, "PKI Processing Requirements for IP Security." I'm unable to find this document at www.ietf.org or anywhere else. Do you know where I can get a copy, or do you know of any equivalent document which outlines IPSEC certificate processing? Thanks in advance. _________________________ Dave Clark Secure Technologies Lucent Technologies/Bell Labs dac@lucent.com PGP 5.5 Key ID: 0xE660D187 Fingerprint: 4F14 F76D 8E35 362C CECA 0BCD 21BC 007E E660 D187 From owner-ipsec Fri Aug 7 13:08:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA14940 for ipsec-outgoing; Fri, 7 Aug 1998 13:06:40 -0400 (EDT) Message-ID: <35CB3815.54CCC171@Certicom.com> Date: Fri, 07 Aug 1998 13:23:34 -0400 From: Yuri Poeluev Organization: Certicom Corp. X-Mailer: Mozilla 4.01 [en] (WinNT; U) MIME-Version: 1.0 To: Dave Clark CC: ipsec@tis.com Subject: Re: I-D ACTION:draft-shima-ipsec-isakmp-cke-type-00.txt X-Priority: 3 (Normal) References: <199808031842.OAA23332@ietf.org> <9808071630.AA17080@anuxc.mv.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, You can contact Rodney Thayer, who is an author of the mentioned document. His e-mail address: R. Thayer: rodney@sabletech.com I've seen links to other his documents, but only links. Those documents have been deleted from IETF site because of expiration. I suggest that you ask him about that document. Sorry, I don't have a copy. Yuri Poeluev Certicom Corp. ypoeluev@certicom.com Dave Clark wrote: > In draft-shima-ipsec-isakmp-cke-type-00.txt, the author refers to > a document which "defines processes for handling IPSEC certificates, > including fulfillment, retrieval, validation, and management...." He > says > this document is draft-thayer-ipsec-pki-00.txt, "PKI Processing > Requirements > for IP Security." > > I'm unable to find this document at www.ietf.org or anywhere else. Do > > you know where I can get a copy, or do you know of any equivalent > document which outlines IPSEC certificate processing? > > Thanks in advance. > > _________________________ > Dave Clark > Secure Technologies > Lucent Technologies/Bell Labs > dac@lucent.com > PGP 5.5 Key ID: 0xE660D187 > Fingerprint: 4F14 F76D 8E35 362C CECA 0BCD 21BC 007E E660 D187 From owner-ipsec Mon Aug 10 02:58:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA20304 for ipsec-outgoing; Mon, 10 Aug 1998 02:50:13 -0400 (EDT) Message-Id: <199808100704.QAA11688@splpe610.ccs.mt.nec.co.jp> To: ipsec@tis.com Subject: Re: I-D ACTION:draft-shima-ipsec-isakmp-cke-type-00.txt Date: Mon, 10 Aug 1998 16:04:12 +0900 From: Shigeyoshi SHIMA Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Thank you for reading draft-shima-ipsec-isakmp-cke-type-00.txt > I'm unable to find this document at www.ietf.org or anywhere else. Do > you know where I can get a copy, or do you know of any equivalent > document which outlines IPSEC certificate processing? Sorry, I described the reference which is difficult to find. A URL for "draft-thayer-ipsec-pki-00.txt" is : ftp://module-one.tillerman.nu/pub/draft-thayer-ipsec-pki-00.txt I got this URL at the 41st IETF Meeting, and I thought draft-thayer-ipsec-pki-00.txt was published as a Internet-Draft. But it may not be published. -------------------- Shigeyoshi Shima shima@ccs.mt.nec.co.jp From owner-ipsec Mon Aug 10 12:43:15 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA22642 for ipsec-outgoing; Mon, 10 Aug 1998 12:41:29 -0400 (EDT) Message-ID: <01BDC44A.EE7AEF60.jjing@gte.com> From: Jin Jing Reply-To: "jjing@gte.com" To: "'ipsec@ans.net'" Subject: 2nd IEEE Workshop on Mobile Computing Systems and Applications (WMCSA'99) Date: Mon, 10 Aug 1998 10:37:42 -0400 Organization: GTE Labs X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-ipsec@ex.tis.com Precedence: bulk Apologies if you receive this message multiple times! ....................................................................................................................... Call for Papers and Participation 2nd IEEE Workshop on Mobile Computing Systems and Applications (WMCSA'99) February 25-26, 1999 New Orleans, Louisiana, USA Sponsored by the IEEE Computer Society's Task Force on Internetworking (TFIW) and Technical Committee on Operating Systems (TCOS), in cooperation with the USENIX Association This past decade has seen the widespread adoption of both portable computing devices and wireless communication networks. However, the integration of these two technologies has yet to occur on a large scale. Achieving pervasive mobile computing will require advances in many areas such as + Network and operating system support for mobility + Application adaptation to changing conditions + Portable computing hardware with networking capability + Digital audio and video in mobile environments + Performance evaluation of wireless data networks + Mobile Internet and Web access + Security and privacy + Power management Following the example of the first WMCSA (see http://www.cs.odu.edu/~mukka/tcos/arch/spring95/spring95.html), the goal of this workshop is to foster the exchange of ideas in mobile computing among workers in the field. Attendance will be limited to about 60 participants, based on the position papers submitted. We seek papers that describe ongoing or completed research and development efforts. We are particularly interested in papers that propose new directions, advocate non-traditional approaches, or generate controversy and discussion. Submissions must not exceed 10 pages in length. We will publish a printed proceedings. A small number of graduate students will be granted a waiver of the registration fee. In return, these students will be asked to take notes at the workshop. Students who wish to be considered for the waiver must send in a brief description of their current research, and an explanation of how participation in the workshop is likely to help them. WMCSA '99 will take place immediately following and in the same location as the 3rd USENIX Symposium on Operating Systems Design and Implementation (OSDI '99). Please see http://www.usenix.org/events/osdi99 for more information on OSDI '99. ORGANIZERS General Chair Sumi Helal, U. of Florida Finance Chair Mukesh Singhal, Ohio State U. Publications Chair Joe Duran, Motorola Publicity Chair Jin Jing, GTE Labs Local Arrangements Chair Golden G. Richard, III, U. of New Orleans Program Chair Ramon Caceres, AT&T Labs Program Committee Mary Baker, Stanford B. Badrinath, Rutgers Nigel Davies, U. of Lancaster Dave Johnson, Carnegie Mellon U. Anthony Joseph, U.C. Berkeley Jay Kistler, FORE Systems Karin Petersen, Xerox PARC Steve Pink, Lulea U. Srini Seshan, IBM Research Cormac Sreenan, AT&T Labs Steering Committee Ramon Caceres, AT&T Labs Fred Douglis (Chair), AT&T Labs Sumi Helal, U. of Florida David Kotz, Dartmouth College Darrell Long, U.C. Santa Cruz SUBMISSION INSTRUCTIONS Send a PostScript or PDF copy of your position papers, at most 10 pages in length, to wmcsa99@research.att.com. Applications for student waivers should be sent to the same address. IMPORTANT DATES Submissions due October 16, 1998 Acceptance notification November 23, 1998 Camera-ready copy due December 18, 1998 ADDITIONAL INFORMATION For the latest information on WMCSA'99, please see http://www.research.att.com/conf/wmcsa99 From owner-ipsec Mon Aug 10 14:19:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA23191 for ipsec-outgoing; Mon, 10 Aug 1998 14:18:29 -0400 (EDT) Message-ID: <35CF3B79.94F2B1@ire-ma.com> Date: Mon, 10 Aug 1998 14:27:05 -0400 From: Bronislav Kavsan X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: ipsec@tis.com Subject: IETF/IPsec meetings in Chicago 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 The on-line agenda for IETF gathering in Chicago doesn't mention any IPsec WG meetings. Are any planned? -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-739-2384 http://www.ire.com From owner-ipsec Mon Aug 10 14:43:42 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA23264 for ipsec-outgoing; Mon, 10 Aug 1998 14:43:29 -0400 (EDT) Message-Id: <35CF4360.C63141DC@lucent.com> Date: Mon, 10 Aug 1998 14:00:48 -0500 From: "David W. Faucher" Organization: Lucent Technologies X-Mailer: Mozilla 4.03 [en] (WinNT; U) Mime-Version: 1.0 To: ipsec@tis.com Subject: Fragmentation, Inbound processing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Section 4.1 of draft-ietf-ipsec-arch-sec-07.txt states: [snip] The requirement for any (transit traffic) SA involving a security gateway to be a tunnel SA arises due to the need to avoid potential problems with regard to fragmentation and reassembly of IPsec packets, and in circumstances where multiple paths (e.g., via different security gateways) exist to the same destination behind the security gateways. Could someone elaborate on what exactly are the "potential problems" or point me to a document explaining them? Section 4.4.2 of draft-ietf-ipsec-arch-sec-07.txt states: [snip] If the packet has been fragmented, then the port information may not be available in the current fragment. If so, discard the fragment. An ICMP PMTU should be sent for the first fragment, which will have the port information. [MAY be supported] I am confused by the discard fragment action. If security gateways can apply IPsec to an IP packet whose payload may be an IP fragment then why would we discard the fragment? Section 5.2.1 of draft-ietf-ipsec-arch-sec-07.txt states: [snip] NOTE: The correct "matching" policy will not necessarily be the first inbound policy found. The SPD is an ordered list of entries. If the correct matching policy was not the first inbound policy found wouldn't that imply that the SPD is not really ordered? Or, am I missing something? thanks -- David W. Faucher Lucent Technologies - Bell Labs dfaucher@lucent.com From owner-ipsec Mon Aug 10 15:15:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA23363 for ipsec-outgoing; Mon, 10 Aug 1998 15:14:32 -0400 (EDT) Date: Mon, 10 Aug 1998 15:31:34 -0400 Message-Id: <199808101931.PAA29320@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Bronislav Kavsan Cc: ipsec@tis.com In-Reply-To: Bronislav Kavsan's message of Mon, 10 Aug 1998 14:27:05 -0400, <35CF3B79.94F2B1@ire-ma.com> Subject: Re: IETF/IPsec meetings in Chicago Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Mon, 10 Aug 1998 14:27:05 -0400 From: Bronislav Kavsan The on-line agenda for IETF gathering in Chicago doesn't mention any IPsec WG meetings. Are any planned? The on-line agenda shows that we have a one-hour slot on Tuesday starting at 2:15pm. Bob Moskowitz is organizing the agenda for the meeting; if you have things which you'd like to present, please let him know. - Ted From owner-ipsec Tue Aug 11 06:51:44 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA25787 for ipsec-outgoing; Tue, 11 Aug 1998 06:44:13 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01C6E68D@wade.reo.dec.com> From: Stephen Waters To: ipsec@tis.com Subject: IP Tunnel for LAN-to-LAN with IPSEC Date: Tue, 11 Aug 1998 12:00:16 +0100 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 If an IP-tunnel is appropriate for a LAN-to-LAN VPN link, then http://search.ietf.org/internet-drafts/draft-gupta-ipsec-remote-access-00.tx t suggests that GRE could be used (in preference to using L2TP/Layer-2 tunnels). Some form of abstraction is needed to allowing dynamic routing to multiple remote security gateways over a single WAN interface (for example). Can I get a poll on how folk intend to implement this support? Currently, we are looking to offer a GRE tunnel (RFC1701) and L2TP in support of dynamic routing over LAN-LAN VPN links. I am concerned that there should be a recommended standard way of doing this - perhaps championed by the IPSEC WG some how. That would make things easier at bake-offs anyway. Regards, Steve. From owner-ipsec Tue Aug 11 09:55:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA26757 for ipsec-outgoing; Tue, 11 Aug 1998 09:53:20 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 11 Aug 1998 10:10:39 -0400 To: "Grillo, John" From: Stephen Kent Subject: Re: Network Management with IP Sec Cc: "'ipsec@tis.com'" Sender: owner-ipsec@ex.tis.com Precedence: bulk John, Yes, this issue has been raised in the past. The answer is that visibility into the packet beyond the IP header, e.g., TCP and UPD headers, will be lost if one sniffs packets after ESP has been applied. This is considered essential in many instances and represents a clean layering approach to security. Application of AH does not prevent examination of those headers, but monitering equipment will have to be programmed to look past the AH header, just as it must be able to work its way through various other header combinations. With either security protocol, the original IP header is maintained in transport mode. In tunnel mode the original IP header also is concealed by ESP, but available (though burried) with AH. In many instances IPsec will be applied at a firewall, so net management sniffing behind the firewall will still permit full access to packets. Steve From owner-ipsec Tue Aug 11 13:55:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA27733 for ipsec-outgoing; Tue, 11 Aug 1998 13:52:34 -0400 (EDT) Message-Id: <3.0.2.32.19980811140335.0073ebd4@csmes.ncsl.nist.gov> X-Sender: frankel@csmes.ncsl.nist.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Tue, 11 Aug 1998 14:03:35 -0400 To: ipsec@tis.com From: Sheila Frankel Subject: NIST's IPsec-WIT Tester now has IKE!!! Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id NAA27730 Sender: owner-ipsec@ex.tis.com Precedence: bulk Announcing IPSEC-WIT (IKE): a WWW-based IPsec / IKE (Internet Key Exchange) Interoperability Test System http://ipsec-wit.antd.nist.gov NIST’s WWW-based IPSEC test system, IPsec-WIT, now supports use of IKE for negotiating Security Associations (SAs), in addition to manual SA establishment. New, additional, test suites are available for IKE based testing. IKE test cases allow users to configure underlying IKE parameters and then conduct interoperability tests, from key negotiation through IPsec data transfer. The test system provides output and diagnostics at various levels of detail (high level script traces to individual packet dumps), either directly through the WWW interface or out-of-band through email. For those interested in the IPSEC-WIT system, but not ready to conduct real tests, the system supports test cases that allow it to negotiate with itself. WIT contains an extensive Tutorial on the tester’s operations, as well as pointers to documentation for NIST’s IKE and IPSEC Reference implementations, PlutoPlus and Cerberus. Documentation for PlutoPlus and Cerberus is also available at: http://ipsec-wit.antd.nist.gov/newipsecdoc/pluto.html AND http://www.antd.nist.gov/cerberus PlutoPlus, our IKE reference implementation (which is based on the original Pluto by Angelos Keromytis), is in an early alpha state. Currently, it conducts only Phase 1 Main Mode/Phase 2 Quick Mode negotiations authenticated with a pre-shared key. (Complete details about PlutoPlus’s capabilities and shortcomings are available on the PlutoPlus Documentation Web Page.) Once PlutoPlus has undergone sufficient testing, the source code will be released to interested parties (in the U.S. and Canada only). For further information, please contact ipsec-wit-dev@antd.nist.gov. From owner-ipsec Tue Aug 11 14:56:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA27942 for ipsec-outgoing; Tue, 11 Aug 1998 14:54:31 -0400 (EDT) Message-ID: From: Bryan Gleeson To: Stephen Waters , ipsec@tis.com Subject: RE: IP Tunnel for LAN-to-LAN with IPSEC Date: Tue, 11 Aug 1998 12:11:06 -0700 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 Steve, > If an IP-tunnel is appropriate for a LAN-to-LAN VPN link, then > > http://search.ietf.org/internet-drafts/draft-gupta-ipsec-remot > e-access-00.tx > t > suggests that GRE could be used (in preference to using > L2TP/Layer-2 > tunnels). > > Some form of abstraction is needed to allowing dynamic > routing to > multiple > remote security gateways over a single WAN interface > (for example). > > Can I get a poll on how folk intend to implement this support? > Currently, we > are looking to offer a GRE tunnel (RFC1701) and L2TP in > support of > dynamic > routing over LAN-LAN VPN links. I am concerned that > there should be > a > recommended standard way of doing this - perhaps > championed by the > IPSEC > WG some how. That would make things easier at bake-offs anyway. I think this is an important point and would suggest that this is a suitable work item for ipsecond. I think that the current IPSEC model should be extended to include its use as a generic tunneling protocol, where the payload is opaque to the particular IP network over which the tunnel is used. There are a few examples - multiprotocol: an IPSEC tunnel is used to carry non-IP packets that are then routed at the tunnel end-point - opaque: an IPSEC tunnel is used to carry opaque packets that are then dropped onto another link or tunnel at the tunnel end-point - disjoint IP: an IPSEC tunnel is used to carry IP packets that are from a different address space to that of the IP backbone over which the tunnel is instantiated (e.g. private address space 10.0.0.0/8) Using GRE is one solution perhaps, but there is quite a lot of overhead as much of the GRE functionality is replicated in IPSEC itself. For example the following GRE fields have IPSEC equivalents. checksum: the authentication header checks for message integrity key: the authentication header checks for data origin seq num: there is already a sequence number in the IPSEC header used for anti-replay. Given that it is there, it could also be used for other purposes routing: source routing isn't really relevant with this use of GRE This leaves the "protocol type" as the only field that carries useful information. One option would be to encapsulate the frame using LLC/SNAP rather than GRE. Another would be to signal the protocol type in the Phase 2 ISAKMP exchange (e.g. VC-MUX in ATM terms) and this would avoid any extra overhead. We are currently working on a VPN framework draft, which will include such a use of IPSEC tunnels. In the meantime people might be interested in the draft which disaggregates the various components of one type of VPN, and discusses how the same VPN functionality can be implemented over MPLS, and also without MPLS by using a generic IP tunneling mechanism. An enhanced IPSEC would seem a prime candidate for such a mechanism, particularly given that the amount of work needed is not that great. If anyone else is interested in generalizing the use of IPSEC tunneling in this manner, either for use within a VPN context, or some other context, let me know. Bryan Gleeson Shasta Networks. From owner-ipsec Tue Aug 11 22:25:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA29123 for ipsec-outgoing; Tue, 11 Aug 1998 22:21:54 -0400 (EDT) Date: Tue, 11 Aug 1998 22:36:52 -0400 (EDT) From: Yuri Poeluev To: ipsec@tis.com Subject: IKE draft - Aggressive mode auth-ted with encryption Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, I'd like to bring your attention to aggressive mode authenticated with public key encryption described in section 5.2 in "draft-ietf-ipsec-isakmp-oakley-08.txt". > When using encryption for authentication, Main Mode is defined as > follows. > > Initiator Responder > ----------- ----------- > HDR, SA --> > <-- HDR, SA > HDR, KE, [ HASH(1), ] > PubKey_r, > PubKey_r --> > HDR, KE, PubKey_i, > <-- PubKey_i > HDR*, HASH_I --> > <-- HDR*, HASH_R > > Aggressive Mode authenticated with encryption is described as > follows: > > Initiator Responder > ----------- ----------- > HDR, SA, [ HASH(1),] KE, > Pubkey_r, > Pubkey_r --> > HDR, SA, KE, PubKey_i, > <-- PubKey_i, HASH_R > HDR, HASH_I --> > Aggressive mode reduces amount of messages in the protocol by combining two messages into a single message. It would be more reasonable, on my opinion, in aggressive mode to keep the same order of payloads as used in main mode. It would be easier to remember the payload order as well, if we know that the payloads order in the main mode is similar. I assume that there might not be the perfect rule for each mode of protocol, but we should make it so where it is possible. I propose that we change > HDR, SA, [ HASH(1),] KE, to > HDR, SA, KE, [ HASH(1),] I know that it is not very critical for the technical part of protocol. However, I think there is no point to leave it as it is. Thanks. Yuri Poeluev Certicom Corp. From owner-ipsec Wed Aug 12 08:17:44 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA00437 for ipsec-outgoing; Wed, 12 Aug 1998 08:09:54 -0400 (EDT) Message-Id: <3.0.32.19980812142135.0093e410@zap.celocom.se> X-Sender: valentin@zap.celocom.se X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 12 Aug 1998 14:21:35 +0100 To: ipsec@tis.com From: Valentin Oprean Subject: implementation of IPsec Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, I'm interested in IPsec issues and therefor looking for an implementation of IPsec that is available outside the US. (Window NT and Window 95) Regards, /.Valentin From owner-ipsec Wed Aug 12 10:33:22 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA01507 for ipsec-outgoing; Wed, 12 Aug 1998 10:29:09 -0400 (EDT) Message-Id: <199808121446.HAA02359@chip.cisco.com> To: Yuri Poeluev cc: ipsec@tis.com Subject: Re: IKE draft - Aggressive mode auth-ted with encryption In-reply-to: Your message of "Tue, 11 Aug 1998 22:36:52 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2355.902933166.1@cisco.com> Date: Wed, 12 Aug 1998 07:46:06 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk The draft (RFC?) specifically states that payloads can be in any order unless otherwise stated. For example, the SA payload has to be first but after that you can put the KE payload next or the hash next. What you propose is perfectly fine to do. No need to change anything, just don't make your implementation expect a certain ordering because doing it differently is perfectly legal. Dan. On Tue, 11 Aug 1998 22:36:52 EDT you wrote > Hi, > > I'd like to bring your attention to aggressive mode > authenticated with public key encryption described in section > 5.2 in "draft-ietf-ipsec-isakmp-oakley-08.txt". > > > When using encryption for authentication, Main Mode is defined as > > follows. > > > > Initiator Responder > > ----------- ----------- > > HDR, SA --> > > <-- HDR, SA > > HDR, KE, [ HASH(1), ] > > PubKey_r, > > PubKey_r --> > > HDR, KE, PubKey_i, > > <-- PubKey_i > > HDR*, HASH_I --> > > <-- HDR*, HASH_R > > > > Aggressive Mode authenticated with encryption is described as > > follows: > > > > Initiator Responder > > ----------- ----------- > > HDR, SA, [ HASH(1),] KE, > > Pubkey_r, > > Pubkey_r --> > > HDR, SA, KE, PubKey_i, > > <-- PubKey_i, HASH_R > > HDR, HASH_I --> > > > > Aggressive mode reduces amount of messages in the protocol > by combining two messages into a single message. > It would be more reasonable, on my opinion, in aggressive > mode to keep the same order of payloads as used in main mode. > It would be easier to remember the payload order as well, > if we know that the payloads order in the main mode is > similar. I assume that there might not be the perfect > rule for each mode of protocol, but we should make it > so where it is possible. > > I propose that we change > > > HDR, SA, [ HASH(1),] KE, > > to > > > HDR, SA, KE, [ HASH(1),] > > > I know that it is not very critical for the > technical part of protocol. However, I think > there is no point to leave it as it is. > > Thanks. > > Yuri Poeluev > Certicom Corp. > From owner-ipsec Wed Aug 12 11:40:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA01906 for ipsec-outgoing; Wed, 12 Aug 1998 11:38:14 -0400 (EDT) Message-ID: <35D1BAFC.A809855E@Certicom.com> Date: Wed, 12 Aug 1998 11:55:40 -0400 From: Yuri Poeluev Organization: Certicom Corp. X-Mailer: Mozilla 4.01 [en] (WinNT; U) MIME-Version: 1.0 To: Daniel Harkins CC: ipsec@tis.com, rwt@netopia.com Subject: Re: IKE draft - Aggressive mode auth-ted with encryption X-Priority: 3 (Normal) References: <199808121446.HAA02359@chip.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk That's right. It does not really matter in what order to process payloads, since the field "next payload" in each payload defines the next payload type, so the implementation will process all payloads eventually regardless of the order. The most important thing is to have all information needed for a current stage of protocol. I just compared other aggressive modes and noticed the difference. Yuri Certicom Corp. Daniel Harkins wrote: > The draft (RFC?) specifically states that payloads can be in any > order unless otherwise stated. For example, the SA payload has to be > first but after that you can put the KE payload next or the hash next. > > What you propose is perfectly fine to do. No need to change anything, > just don't make your implementation expect a certain ordering because > doing it differently is perfectly legal. > > Dan. > > On Tue, 11 Aug 1998 22:36:52 EDT you wrote > > Hi, > > > > I'd like to bring your attention to aggressive mode > > authenticated with public key encryption described in section > > 5.2 in "draft-ietf-ipsec-isakmp-oakley-08.txt". > > > > > When using encryption for authentication, Main Mode is defined > as > > > follows. > > > > > > Initiator Responder > > > ----------- ----------- > > > HDR, SA --> > > > <-- HDR, SA > > > HDR, KE, [ HASH(1), ] > > > PubKey_r, > > > PubKey_r --> > > > HDR, KE, PubKey_i, > > > > <-- PubKey_i > > > HDR*, HASH_I --> > > > <-- HDR*, HASH_R > > > > > > Aggressive Mode authenticated with encryption is described as > > > follows: > > > > > > Initiator Responder > > > ----------- ----------- > > > HDR, SA, [ HASH(1),] KE, > > > Pubkey_r, > > > Pubkey_r --> > > > HDR, SA, KE, > PubKey_i, > > > <-- PubKey_i, > HASH_R > > > HDR, HASH_I --> > > > > > > > Aggressive mode reduces amount of messages in the protocol > > by combining two messages into a single message. > > It would be more reasonable, on my opinion, in aggressive > > mode to keep the same order of payloads as used in main mode. > > It would be easier to remember the payload order as well, > > if we know that the payloads order in the main mode is > > similar. I assume that there might not be the perfect > > rule for each mode of protocol, but we should make it > > so where it is possible. > > > > I propose that we change > > > > > HDR, SA, [ HASH(1),] KE, > > > > to > > > > > HDR, SA, KE, [ HASH(1),] > > > > > > I know that it is not very critical for the > > technical part of protocol. However, I think > > there is no point to leave it as it is. > > > > Thanks. > > > > Yuri Poeluev > > Certicom Corp. > > From owner-ipsec Wed Aug 12 13:19:51 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA02420 for ipsec-outgoing; Wed, 12 Aug 1998 13:17:16 -0400 (EDT) X-Sender: cynthia@mail.surfnetusa.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: cynthia@usenix.org From: cynthia@usenix.org (Cynthia Deno) Subject: Call for Papers: USENIX Workshop on Intrusion Detection Date: Mon, 10 Aug 1998 16:01:30 -0700 Sender: owner-ipsec@ex.tis.com Precedence: bulk 1st USENIX Workshop on Intrusion Detection and Network Monitoring April 11-12, 1999 Santa Clara, California, USA Sponsored by USENIX, the Advanced Computing Systems Association ---------------------------------------------------------- Please find the Call for Submissions at http://www.usenix.org/events/detection99/ ---------------------------------------------------------- Important Due Dates for Refereed Paper Submissions Extended abstracts due: November 1, 1998 Notification to authors: November 23, 1998 Full papers for editorial review: December 12, 1998 Camera-ready full papers: February 20, 1999 Intrusion detection offers the promise of automatic detection and notification of break-ins or unauthorized use of computers. Better techniques for detecting abuse from within and without are becoming mandatory. The goal of this workshop is to bring together network managers, engineers and researchers interested in deploying and developing intrusion detection systems (IDS) and network monitoring technologies for security, traffic analysis, or forensics. The emphasis is on practical results, case studies, and real-world large-scale deployment. This will be a two-day workshop, consisting of refereed papers, invited talks, and work-in-progress reports. Opportunities to get together informally will include a Sunday evening hosted reception, a lunch on Monday with Marcus Ranum hosting, and Birds-of-a-Feather sessions on Sunday. The Program Committee, chaired by Marcus J. Ranum of Network Flight Recorder seeks original work concerning the design, implementation, and real-world application of intrusion detection and network monitoring technologies. Besides mature work, we encourage submissions describing exceptionally promising prototypes, or enlightening negative results. Case studies and experience papers are particularly of interest. Share your results, share your pain, share your ideas. Authors will, where appropriate, be able to demonstrate their applications during their presentation using systems that will be fed with packets captured at "live" sites, which contain various intrusion attempts. Topics of interest include, but are not limited to: Case studies of IDS in practice Statistical models for IDS Anomaly detection systems Misuse detection systems Host based approaches to IDS Network based approaches to IDS Application based approaches to IDS IDS in cryptographically protected networks Distributed IDS in large networks Correlation techniques Event thresholding Reducing false positives Alternative approaches Authors must submit an extended abstract by November 1, 1998. The full papers resulting from accepted abstracts will go through an editorial review cycle with a member of the program committee, and should end up about 10-12 pages long. ============================================================= USENIX is the not-for-profit Advanced Computing Systems Association with an international membership of technical professionals. USENIX's refereed conferences are recognized for bridging leading-edge research and the practical. From owner-ipsec Wed Aug 12 14:40:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA02835 for ipsec-outgoing; Wed, 12 Aug 1998 14:37:17 -0400 (EDT) Message-ID: From: William Dixon To: "'ipsec@tis.com'" Cc: William Dixon Subject: RE: IPSec interop workshop Aug 31st - Sept 3 invitation Date: Wed, 12 Aug 1998 11:54:00 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipsec@ex.tis.com Precedence: bulk FYI. The event is on, with 9 different implementations. Updated info to follow. -Wm -----Original Message----- From: William Dixon [mailto:wdixon@microsoft.com] Sent: Thursday, August 06, 1998 2:26 PM To: 'ipsec@tis.com' Cc: William Dixon Subject: RE: IPSec interop workshop Aug 31st - Sept 3 invitation Folks please get back to me by Friday if you haven't yet. I'd like to make a call this weekend if this is going to happen. I have about 6-7 vendors plus others already so it looks good. It can be just one developer if you're strapped with other events (SIGCOMM, AutoNet, life, etc.) Thanks, -Wm -----Original Message----- From: William Dixon [mailto:wdixon@microsoft.com] Sent: Tuesday, August 04, 1998 10:35 AM To: 'ipsec@tis.com' Subject: RE: IPSec interop workshop Aug 31st - Sept 3 invitation My apologies to IBM and everyone for not making one point clear. I fully support the already announced IBM bakeoff in late October and we will attend. The invitation I sent is another opportunity, 6 weeks earlier, to help vendors work out interop issues. Particularly it will be hard for me to make changes in November/Dec and I'd like to ship something people won't have to many problems interoping with as they move forward in their implementations. -Wm -----Original Message----- From: William Dixon [mailto:wdixon@microsoft.com] Sent: Tuesday, August 04, 1998 2:17 AM To: 'ipsec@tis.com' Subject: IPSec interop workshop Aug 31st - Sept 3 invitation I am concerned that we are not having enough opportunities for comprehensive and/or sophisticated interoperability testing. So I'd like to offer one during the week after the IETF (not great timing I know). I've got room for about 30 people plus equipment. So please "r" me if interested and give me a few days to respond. I'd like someone from ICSA to attend also. By the end of the week I hope to have enough responses to determine if it will be worthwhile. Thanks, -Wm Announcement of IPSec Bakeoff Opportunity Mon-Thurs, Aug 31st- Sept 3 Microsoft Main Campus, Olympic Room in bldg. 27S Redmond, WA Contents: 1. Purpose - Criteria 2. Proposed functionality testing 3. Proposed daily agenda 1. Purpose Provide IPSec vendor developers of the most complete IPSec implementations a small-scale, mixed vendor environment to further test IPSec interoperability for transport and tunneling, under load, across a variety of network topologies, including dialup, 100Mbit Ethernet and across Internet WAN links. To test attack resilience of IPSec implementations. To begin testing L2TP/IPSec interop. No press releases, just interop work. Wider interop shake out for base and extended families of ICSA v2.0 criteria. Increase consensus among IPSec vendors for how to solve some common deployment problems and prepare for IBM's full bakeoff in October. Due to the small facility, I'd like to prioritize for those who can negotiate and perform ALL of the following functionality: IKE - Negotiate and perform - Multiple auth method proposals - Certificate authentication and certificate request payloads - Dynamic rekey with PFS for both main mode and quick mode - Selectors (filters) to the IPaddress, IP Subnet, and port IPSec - ESP with 56bitDES, null-ESP, MD5 and SHA1 - Transport and tunnel mode Implementations should also have IKE - AND proposal - SA delete payload - Lifetimes in both bytes and times - Group 2 DH with 3DES - 512bit DH or explicit p & g IPSec - Protocol and port filters - L2TP/IPSec integration - AH with MD5 and SHA1 - AH+ESP combination - ESP 3DES - ESP 40bitDES 2. IPSec Functionality Testing 1. Basic interop on combinations 2. Certificate Infrastructure - Cert Server certificates from: Entrust, Microsoft, Verisign, Netscape - Cert trust verification using hierarchy in PKI infrastructures - Using CRLs during cert validation ? - Timing of IKE successful/unsuccessful negotiation using certs, how transparent for end-to-end? 3. IKE retransmit behavior 4. Export <-> Export, Export <-> Domestic - Basic IKE and IPSec tests - Explicit p&g DH with 40bit DES 5. IKE commit bit 6. Throughput & number of simultaneous negotiations performance testing against different implementations 7. Reboot recovery (peer reboot losing it's security associations) 8. Scenarios - - End-to-End transport long lived security associations (over night, data transfer >1Gb) with frequent dynamic rekey - End-to-GW tunnel long lived security associations (over night, data transfer >1Gb) with frequent dynamic rekey - Policy change events while under SA load - End-to-End SA through IPSec tunnels, initiation both ways - Client End-to-End through client-to-GW tunnel SA, initiate from client for tunnel, then initiation both ways for end-to-end - Client-to-GW transport SA for secure management 9. Multiple auth method proposals and AND proposal 10. Discuss reliability requirements for SA establishment, maintenance under load, heavy fragmentation, packet corruption, packet loss 3. Schedule Monday evening Aug 31 - we may actually be able to setup on Sunday, not sure yet, which would make this a full testing day 12:00-17:00 - Room and Network Setup 15:00-17:00 - Shipping deliveries from MS Receiving to bldg. 27/Olympic Room 17:00-22:00 - Vendor equipment drop off/setup Tuesday Sept 1st 7:30 - Room Opens, Catered continental bkfast 8:30 - Welcome, Agenda, Network Layout, Logistics 9:00 - Testing 12:30 - SyncUp Discussion with catered lunch 13:00-13:30 Overview of MS PKI 17:00 - ReSync Discussion 22:00 - Room closes for night Wednesday Sept 2nd 7:30 - Room Opens, Catered continental bkfast 8:30 - Agenda, Q& A 12:30 - SyncUp Discussion 13:00-13:30 Overview of IPSec policy in NT5.0 Active Directory 17:00 - SyncUp Discussion 22:00 - Room closes for night Thursday Sept 3rd 7:30 - Room Opens, Catered continental bkfast 8:30 - Agenda, Q& A 12:30 - 13:30 - SyncUp Discussion 17:00 - Vendor Equip load Out 19:00 - Network pulled up 21:00 - Turnover to facilities management for next day Friday Sept 4th - Event notes typed up and released to IETF IPSec list & participants Wm William Dixon, 425-703-8729, wdixon@microsoft.com Program Manager, Internet Protocol Security PBS Windows Networking & Communications Microsoft Corporation From owner-ipsec Wed Aug 12 20:49:42 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA03930 for ipsec-outgoing; Wed, 12 Aug 1998 20:46:34 -0400 (EDT) From: Dan McDonald Message-Id: <199808130102.SAA04565@kebe.eng.sun.com> Subject: Header file question To: ipsec@tis.com Date: Wed, 12 Aug 1998 18:02:40 -0700 (PDT) Cc: danmcd@kebe.eng.sun.com (Dan McDonald) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello! I've been talking over with some people here in Sun, and we came to the conclusion that it would be nice to at least define in UNIX (and other platforms?) header files a common include file for IPsec headers. This is just the headers, so programs that parse headers (tcpdump) can deal with them across platofrms. So this is really a question pointed at you OS vendors out there that include header files with your OS. For example, almost everybody's UNIX (AFAIK) has netinet/ip.h, which contains... struct ip { #ifdef _BIT_FIELDS_LTOH uchar_t ip_hl:4, /* header length */ ip_v:4; /* version */ #else uchar_t ip_v:4, /* version */ ip_hl:4; /* header length */ #endif uchar_t ip_tos; /* type of service */ short ip_len; /* total length */ ushort_t ip_id; /* identification */ short ip_off; /* fragment offset field */ #define IP_DF 0x4000 /* dont fragment flag */ #define IP_MF 0x2000 /* more fragments flag */ uchar_t ip_ttl; /* time to live */ uchar_t ip_p; /* protocol */ ushort_t ip_sum; /* checksum */ struct in_addr ip_src, ip_dst; /* source and dest address */ }; (Stolen from Solaris 2.x's netinet/ip.h.) I guess I'd like to propose: #include which contains the following minimal things: #include /* Include POSIX and/or X-Open types */ struct ah { uint8_t ah_nexthdr; uint8_t ah_length; /* (ah_length << 2) + 8 == AH length */ uint16_t ah_reserved; uint32_t ah_spi; uint32_t ah_replay; }; struct esph { uint32_t esph_spi; uint32_t esph_replay; }; If people feel I'm off my rocker, or are being to dictatorial, I'll just be quiet. But if you think this is a good idea for tools like tcpdump to have a same-source header file for parsing AH and ESP, let's hear it on the list. This is not anything that needs to be an I-D, or anything else, just a minimal agreement among implementors. Dan From owner-ipsec Thu Aug 13 09:22:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA06023 for ipsec-outgoing; Thu, 13 Aug 1998 08:59:15 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01C6E699@wade.reo.dec.com> From: Stephen Waters To: ipsec@tis.com Subject: 40-bit DES negotiation in IKE? Date: Thu, 13 Aug 1998 14:11:42 +0100 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 I've no doubt that this issue has been covered, but could some kind soul tell me how 40-bit DES is negotiated with IKE - or not. As far as I can see, you can't negotiate 40-bit, so 40-bit is restricted to manual-key SA. I realise folk see 40-bit DES as counter-security, but at the moment, 40-bit is all that can be exported to Joe Public (from the US). (When is the US export department going to notice that there is no point to this export stratagy - DES/3DES are well know and simple to build into hardware - anywhere. This policy is simply putting the US at a disadvanatge in the world market for security products). Cheers, Steve. From owner-ipsec Thu Aug 13 11:29:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA06731 for ipsec-outgoing; Thu, 13 Aug 1998 11:25:55 -0400 (EDT) To: ipsec@tis.com Subject: ECDL on Oakley Grp 3&4 Message-Id: From: Niels Provos Date: Thu, 13 Aug 1998 17:42:33 +0200 Sender: owner-ipsec@ex.tis.com Precedence: bulk FYI M. Wiener and R. Zuccherato will be presenting a paper with the title 'Faster attacks on Elliptic Curve Cryptosystems' at the SAC'98. The paper describes a speedup of the Pollard-\rho attack when an elliptic curve over GF(2**n), with n = ed, is defined over GF(2**e). The speedup is by a factor of \sqrt{2d}. Since both Oakley Group 3 and 4 are defined over GF(2**31) and GF(2**37) respectivly, the speedup of a parallel collison-search in both cases is by a factor of about \sqrt(2*5) ~ 3. Greetings Niels -- - PHYSnet Rechnerverbund PGP V2.6 Public key via finger or key server Niels Provos Universitaet Hamburg WWW: http://www.physnet.uni-hamburg.de/provos/ Jungiusstrasse 9 E-Mail: provos@wserver.physnet.uni-hamburg.de Germany 20355 Hamburg Tel.: +49 40 4123-2404 Fax: -6571 From owner-ipsec Thu Aug 13 11:42:24 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA06857 for ipsec-outgoing; Thu, 13 Aug 1998 11:40:56 -0400 (EDT) Message-Id: <199808131557.LAA14237@jekyll.piermont.com> To: Stephen Waters cc: ipsec@tis.com Subject: Re: 40-bit DES negotiation in IKE? In-reply-to: Your message of "Thu, 13 Aug 1998 14:11:42 BST." <250F9C8DEB9ED011A14D08002BE4F64C01C6E699@wade.reo.dec.com> 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 Date: Thu, 13 Aug 1998 11:57:00 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen Waters writes: > I realise folk see 40-bit DES as counter-security, but at the > moment, 40-bit is all that can be exported to Joe Public (from the US). If the government told doctors that the only treatment they could give their patients suffering from bacterial infections was to stick needles under their eyelids, do you think that the medical journals would be right in dignifying that with papers on proper needles-under-eyelids techniques for curing different kinds of infections? 56 bit DES is useless. 40 bit is less than useless. Why bother consuming the user's CPU for no gain? Perry From owner-ipsec Thu Aug 13 15:24:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA07672 for ipsec-outgoing; Thu, 13 Aug 1998 15:20:57 -0400 (EDT) Message-ID: <35D3405A.72390CBE@cs.umass.edu> Date: Thu, 13 Aug 1998 15:36:58 -0400 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: IPsec List Subject: Re: ECDL on Oakley Grp 3&4 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Niels Provos writes: > FYI M. Wiener and R. Zuccherato will be presenting a paper with the > title 'Faster attacks on Elliptic Curve Cryptosystems' at the SAC'98. > The paper describes a speedup of the Pollard-\rho attack when an > elliptic curve over GF(2**n), with n = ed, is defined over GF(2**e). > The speedup is by a factor of \sqrt{2d}. > > Since both Oakley Group 3 and 4 are defined over GF(2**31) and GF(2**37) > respectivly, the speedup of a parallel collison-search in both cases is by a > factor of about \sqrt(2*5) ~ 3. See http://grouper.ieee.org/groups/1363/contrib.html (about 2/3 down the page) for a version of this paper. -Lewis From owner-ipsec Thu Aug 13 17:46:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA08251 for ipsec-outgoing; Thu, 13 Aug 1998 17:43:57 -0400 (EDT) X-Lotus-FromDomain: CERTICOM From: "Yuri Poeluev" To: ipsec@tis.com cc: "Simon Blake-Wilson" Message-ID: <8525665F.0076D3EF.00@domino2.certicom.com> Date: Thu, 13 Aug 1998 17:47:31 -0400 Subject: Text to be sent to Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@ex.tis.com Precedence: bulk We've been trying to implement IPSec and have encountered some issues. These are related to the problem which Neils Provo observed in his email on 13.Aug.98 at 15:42 GMT. Specifically, the IKE specification currently only facilitates the use of elliptic curve groups over F2**m, m composite. The world's leading experts in elliptic curve cryptography have publicly questioned the security of these curves. These experts include: Prof Gerhard Frey, Essen University Prof Alfred Menezes, Waterloo University and Certicom Dr Volker Mueller, Darmstadt University Dr Sachar Paulus, Darmstadt University Prof Bart Preneel, Leuven University Prof Claus Schnorr, Frankfurt University and RSA Prof Scott Vanstone, Waterloo University and Certicom Mike Wiener, Entrust We will provide copies of these references. We therefore suggest that, due to the fact that they are suspect and appear to provide neither hardware nor software benefits versus F2**m, m prime, the specification should preclude the use of F2**m, m composite, curves, which should be replaced with elliptic curve groups over F2**m, m prime. At the minimum, we feel that the specification should facilitate use of some non-suspect F2**m, m prime. In addition, it may also be beneficial to consider facilitating use of some elliptic curve groups over Fp. We hope to discuss this in more detail at the meeting in Chicago and will bring in specific suggested text. In the meantime, please let us know if you have any questions or comments. Regards, Yuri Poeluev & Simon Blake-Wilson Certicom Corp. From owner-ipsec Thu Aug 13 19:57:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA08826 for ipsec-outgoing; Thu, 13 Aug 1998 19:54:57 -0400 (EDT) Message-ID: <35D380DF.1F7B4A62@Certicom.com> Date: Thu, 13 Aug 1998 20:12:16 -0400 From: Yuri Poeluev Organization: Certicom Corp. X-Mailer: Mozilla 4.01 [en] (WinNT; U) MIME-Version: 1.0 To: ipsec@tis.com CC: Simon Blake-Wilson Subject: EC groups over F2**m, m composite X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk We've been trying to implement IPSec and have encountered some issues. These are related to the problem which Neils Provo observed in his email on 13.Aug.98 at 15:42 GMT. Specifically, the IKE specification currently only facilitates the use of elliptic curve groups over F2**m, m composite. The world's leading experts in elliptic curve cryptography have publicly questioned the security of these curves. These experts include: Prof Gerhard Frey, Essen University Prof Alfred Menezes, Waterloo University and Certicom Dr Volker Mueller, Darmstadt University Dr Sachar Paulus, Darmstadt University Prof Bart Preneel, Leuven University Prof Claus Schnorr, Frankfurt University and RSA Prof Scott Vanstone, Waterloo University and Certicom Mike Wiener, Entrust We will provide copies of these references. We therefore suggest that, due to the fact that they are suspect and appear to provide neither hardware nor software benefits versus F2**m, m prime, the specification should preclude the use of F2**m, m composite, curves, which should be replaced with elliptic curve groups over F2**m, m prime. At the minimum, we feel that the specification should facilitate use of some non-suspect F2**m, m prime. In addition, it may also be beneficial to consider facilitating use of some elliptic curve groups over Fp. We hope to discuss this in more detail at the meeting in Chicago and will bring in specific suggested text. In the meantime, please let us know if you have any questions or comments. Regards, Yuri Poeluev & Simon Blake-Wilson Certicom Corp. From owner-ipsec Fri Aug 14 12:58:24 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA12367 for ipsec-outgoing; Fri, 14 Aug 1998 12:50:56 -0400 (EDT) Date: Fri, 14 Aug 1998 13:03:19 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199808141703.NAA09501@earth.hpc.org> To: ypoeluev@certicom.com Cc: ipsec@tis.com, sblakewi@certicom.com In-reply-to: Yourmessage <8525665F.0076D3EF.00@domino2.certicom.com> Subject: Re: Text to be sent to Sender: owner-ipsec@ex.tis.com Precedence: bulk The groups provide both hardware and software benefits. The issue of their security is something that will be discussed at SAC next week, and no motivation for a hasty change to the standard is indicated based on information provided to date. Hilarie From owner-ipsec Sat Aug 15 14:15:07 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA14746 for ipsec-outgoing; Sat, 15 Aug 1998 14:10:53 -0400 (EDT) Message-ID: From: William Dixon To: "'ipsec@tis.com'" Subject: Update: IPSec interop workshop Aug 31st - Sept 3 Date: Sat, 15 Aug 1998 11:27:24 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipsec@ex.tis.com Precedence: bulk Updated info below. IPSec Bakeoff in Redmond, WA Mon-Thurs, Aug 31st- Sept 3, setup on Sunday 12noon+. Official Start Time: 8:30am Monday, End Time: 16:00 Thursday Microsoft Main Campus, Olympic Room in bldg. 27N Redmond, WA I. Cost I. Participants II. Hotel Info I. Cost: No fees on our side yet. I'm still preparing the budget and seeking approval. Will know about Wed of next week. I don't expect any problems. I. Participants - we are at capacity with those who have sent me replies. IPSec Implementations - Axent/Raptor - Cisco reference & IOS - Checkpoint - GNU - Intel - Interlink - IRE - Microsoft NT - Netscreen - Redcreek - Shiva - SSH - Timestep - Worldcom/ANS Others (and those I wasn't sure if they had implementations) - HiFn - Verisign - Worldcom Advanced Networks - James Matheke - Digital Signature Trust Company - Microsoft PKI, Directory reps II. Hotel Info There are three hotels in one cluster where I hope everyone can stay. They are about 8 blocks from main campus and about 2 blocks from a bus line. Marriott Residence Inn, Also Marriott Fairfield and Marriott Courtyard 14455 NE 29th Place Bellevue WA 98007 206-882-1222, 800-331-3131 Otherwise: Bellevue Red Lion 300 112th SE Bellevue, WA 98004 206-455-1300, 800-547-8010 La Quinta Inn 10520 Northrup Way Kirkland WA 98004 206-828-6585, 800-531-5900 Hyatt Regency Bellevue NE 8th & Bellvue Way Bellevue, WA 206-462-1234, 800-228-9000 I caution against staying in Redmond or the Seattle side because of traffic. Any other hotel in Bellevue will work. III. Facility The current room may change if I can't get a security guard hired. But here is what I plan for the current room 27N/Olympic. It is a large multipurpose presentation room, flat floor, capacity 120 seats, but we'll have about 30-40 tables around the edge in two rows in the middle. MS will provide the network (suggestions on configurations welcome). MS can provide monitors & keyboards and a Pentium PC preloaded with Win9x or NT4 sp3 (send request if you haven't already). Presentation aids available: PC for Power point slides, hooked up to a BarCo overhead projection to large screen. Also will have a transparency overhead projector, paper flip chart and dry erase boards. Load in on Sunday 3pm-7pm, then Monday 7am+. Shipto address is TBD, but we would receive equipment and deliver on Monday morning to the room for you to unbox. At 4pm Thursday, I'll have a truck arrive to pick up your packed boxes for shipping back home. There is a meeting room in the lobby which can be schedule with receptionist. Photocopy is currently available by escort during the day. I'll try to move one copier out for our room. I'm trying to work on getting 24hr access. I'm also trying to work on a mailing list for info and discussion preceding. Wm William Dixon, 425-703-8729, wdixon@microsoft.com Program Manager, Internet Protocol Security PBS Windows Networking & Communications Microsoft Corporation From owner-ipsec Sun Aug 16 20:01:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA17020 for ipsec-outgoing; Sun, 16 Aug 1998 19:54:00 -0400 (EDT) Message-Id: <199808170010.JAA01036@1-kai.cec-ltd.co.jp> From: "Suu Smith" To: Subject: append Date: Mon, 17 Aug 1998 09:10:27 +0900 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk From owner-ipsec Mon Aug 17 01:01:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA17630 for ipsec-outgoing; Mon, 17 Aug 1998 01:01:00 -0400 (EDT) Message-Id: <3.0.3.32.19980816223016.00a6e960@netcom.com> X-Sender: andrade@netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Sun, 16 Aug 1998 22:30:16 -0700 To: Stephen Waters , ipsec@tis.com From: Alex Alten Subject: Re: 40-bit DES negotiation in IKE? In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C01C6E699@wade.reo.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 02:11 PM 8/13/98 +0100, Stephen Waters wrote: > >I realise folk see 40-bit DES as counter-security, but at the moment, 40-bit is >all that can be exported to Joe Public (from the US). > No, this is an incorrect statement. At the moment I'm aware of least two cryptographic systems which can be exported outside the US and Canada with unlimited key strength to any type of firm in any country except for a half dozen like Iraq, North Korea, etc. Both of these systems have key recovery, TIS via 3rd party escrow and TriStrata via self escrow. - Alex -- Alex Alten Andrade@Netcom.Com (home--old) Alten@Home.Com (home--new) Alten@TriStrata.Com (work) P.O. Box 11406 Pleasanton, CA 94588 USA (510) 417-0159 From owner-ipsec Mon Aug 17 11:08:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA19129 for ipsec-outgoing; Mon, 17 Aug 1998 11:06:25 -0400 (EDT) Message-ID: <35D84B27.42C99ADA@Certicom.com> Date: Mon, 17 Aug 1998 11:24:23 -0400 From: Yuri Poeluev Organization: Certicom Corp. X-Mailer: Mozilla 4.01 [en] (WinNT; U) MIME-Version: 1.0 To: Hilarie Orman CC: ipsec@tis.com, sblakewi@certicom.com Subject: EC over F2**m, m composite X-Priority: 3 (Normal) References: <199808141703.NAA09501@earth.hpc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Hilarie, > The groups provide both hardware and software benefits. I think efficiency is a secondary issue in this debate since obviously efficiency is no good without security. But it seems like the added efficiency offered by curves over F2m, m composite, is questionable. We spent years trying to find significant benefits and eventually gave up. Which software programs or hardware devices implementing m composite do you have in mind? I'd like to compare them with our implementations in software toolkits and smart cards. > The issue of their security is something that will be discussed > at SAC next week, and no motivation for a hasty change to the > standard is indicated based on information provided to date. It seems to me like enough people have expressed strong fears about these curves to warrant removing them. The ATM forum recently reached the same conclusion and removed these curves. At the very least surely we shouldn't facilitate only the use of suspect curves? We are ready to propose alternative curves over F2**163 and F2**191 as well as Fp for 160 and 192-bit prime. I'm forwarding a note I received from Simon Blake-Wilson, one of our math junkies, which goes into more details on the problem. Best regards, Yuri ___________________forwarded note_______________________ We don't supply curves over F2m, m composite, because all the theory experts we speak to seem very concerned about these curves. Many have made concrete statements in the literature to this effect: Gerhard Frey - THE big man of this stuff - mentioned the issue in his invited talk at EuroCrypt 97. He strongly recommended avoiding the curves because he believes there is a subexponential time algorithm for the ECDLP over F2m m composite. In particular he stated his belief that the following approach would prove successful: exploit the Weil descent to embed the curves in a high genus hyperelliptic curve over the subfield, then use the Adleman-Huang algorithm to solve the log problem on this curve. (He's talking about Weil descent again at the Waterloo workshop in September.) These fears were also expressed by Claus Schnorr in his rump session talk at Crypto 97. He exploited analogous subfield structures to break the Chor-Rivest knapsack and conjectured that these structures could well give rise to similar weaknesses in the ECDLP over F2m m composite. Other experts who have publicly expressed their concerns include: Volker Mueller and Sachar Paulus in their paper "On the generation of cryptographically strong elliptic curves" available from http://www.informatik.th-darmstadt.de/TI/Mitarbeiter/vmueller.html Erik De Win, Serge Mister, Bart Preneel, and Mike Weiner in their paper at ANTS 98 "On the performance of signature schemes based on elliptic curves". Although none of these references actually break the ECDLP on curves over F2m m composite, it seems like we'd be pretty stupid to ignore the advice of all these clever people! (The only concrete results on these curves so far are minor improvements due to Gallant/Lambert/Vanstone and Wiener/Zuccherato. These results were presented at EuroCrypt 98 and will be presented again this week at SAC. They're elegant results but in no way fatal to security.) From owner-ipsec Mon Aug 17 17:24:31 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA20597 for ipsec-outgoing; Mon, 17 Aug 1998 17:21:39 -0400 (EDT) Message-ID: <35D8A30F.519A8A34@Certicom.com> Date: Mon, 17 Aug 1998 17:39:28 -0400 From: Yuri Poeluev Organization: Certicom Corp. X-Mailer: Mozilla 4.01 [en] (WinNT; U) MIME-Version: 1.0 To: ipsec@tis.com Subject: Encryption in aggressive mode (IKE draft) X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, I was reading ISAKMP & IKE documents, and I have found that aggressive mode in IKE draft is a bit different from one in ISAKMP draft. > AGGRESSIVE EXCHANGE > >_#_____Initiator___Direction______Responder________________________NOTE____________________ >(1) HDR; SA; KE; => Begin ISAKMP-SA or Proxy negotiation > NONCE; IDii and Key Exchange > >(2) <= HDR; SA; KE; > NONCE; IDir; AUTH > Initiator Identity Verified by Responder > Key Generated > Basic SA agreed upon >(3) HDR*; AUTH => > Responder Identity Verified by Initiator > SA established Note that the last message is encrypted here, except the header of course. Now, let's take a look at what we have in IKE draft. Section 5.1: > Aggressive mode with signatures in conjunction with ISAKMP is > described as follows: > > Initiator Responder > ----------- ----------- > HDR, SA, KE, Ni, IDii --> > <-- HDR, SA, KE, Nr, IDir, > [ CERT, ] SIG_R > HDR, [ CERT, ] SIG_I --> Section 5.2: > Aggressive Mode authenticated with encryption is described as > follows: > > Initiator Responder > ----------- ----------- > HDR, SA, [ HASH(1),] KE, > Pubkey_r, > Pubkey_r --> > HDR, SA, KE, PubKey_i, > <-- PubKey_i, HASH_R > HDR, HASH_I --> Section 5.3: > Aggressive Mode authenticated with the revised encryption method is > described as follows: > > Initiator Responder > ----------- ----------- > HDR, SA, [ HASH(1),] > Pubkey_r, > Ke_i, Ke_i > [, Ke_i ] --> > HDR, SA, PubKey_i, > Ke_r, Ke_r, > <-- HASH_R > HDR, HASH_I --> Section 5.4: > Aggressive mode with a pre-shared key is described as follows: > > Initiator Responder > ----------- ----------- > HDR, SA, KE, Ni, IDii --> > <-- HDR, SA, KE, Nr, IDir, HASH_R > HDR, HASH_I --> In all above cases, the last message is not encrypted, which contradicts aggressive mode in ISAKMP draft. For instance, instead > HDR, HASH_I --> we would expect > HDR*, HASH_I --> I propose that all payloads following the header in the last message must be encrypted and IKE draft must be changed accordingly. I assume, there might be a reason for what we have in IKE draft now. But since initiator and responder have finished KE exchange, we should be able to encrypt any following message. There is no reason for waiting. Thanks, Yuri Poeluev Certicom Corp. From owner-ipsec Mon Aug 17 17:28:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA20656 for ipsec-outgoing; Mon, 17 Aug 1998 17:28:39 -0400 (EDT) Message-ID: From: Biao Wang To: "'ipsec@tis.com'" Subject: more on Message ID of Informational Exchanges, Please comment! Date: Mon, 17 Aug 1998 14:44:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: multipart/alternative; boundary="---- =_NextPart_001_01BDCA28.40DBA710" 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_001_01BDCA28.40DBA710 Content-Type: text/plain > Hi all, I have been reading many comments over the inconsistency of > Message ID > of Informational Exchanges of this list, but looks like there is no > consenses > on this issue. And here is my suggestions -- > > 1) All Informatioanl Exchange should have unique message ID *EXCEPT* > o Notification which occurs during, or is concerned with, a Phase 2 > negotiation > o CONNECTED Notify message > 2) For those Informational Exchange that has the same message ID as an > on-going > negotiation, they MUST be encrypt/decrypt using the running IV of that > negotiation. > > and I believe it is clear and also easy to implement. > > Thanks, > Biao Wang > RouterWare Inc. > > > From ISAKMP draft 10 > -------------------- > "The only exception to this is when > the Commit Bit of the ISAKMP Header is set. When the Commit Bit is set, > the Message ID field of the Informational Exchange MUST contain the Mes- > sage ID of the original ISAKMP Phase 2 SA negotiation, rather than a new > Message ID (MID). This is done to ensure that the Informational Exchange > with the CONNECTED Notify Message can be associated with the correct Phase > 2 SA." > > "Notification which occurs during, or is concerned with, a Phase 2 nego- > tiation is identified by the Initiator and Responder cookie pair in the > ISAKMP Header and the Message ID and SPI associated with the current nego- > tiation." > > From IKE draft 8 > -------------------- > "After the ISAKMP SA has been authenticated all Informational > Exchanges are encrypted using SKEYID_e. The initiaization vector for > these exchanges is derived in exactly the same fashion as that for a > Quick Mode-- i.e. it is derived from a hash of a concatenation of the > last phase 1 CBC output block and the message id from the ISAKMP > header of the Informational Exchange (not the message id from the > message that may have prompted the Informational Exchange)." ------ =_NextPart_001_01BDCA28.40DBA710 Content-Type: text/html Content-Transfer-Encoding: quoted-printable more on Message ID of Informational Exchanges, Please = comment!

Hi all, I have been = reading many comments over the inconsistency of Message ID
of Informational = Exchanges of this list, but looks like there is no consenses
on this issue. And = here is my suggestions --

1) All Informatioanl = Exchange should have unique message ID *EXCEPT*
        o Notification which occurs during, or = is concerned with, a Phase 2 negotiation

        o CONNECTED Notify message
2) For those = Informational Exchange that has the same message ID as an = on-going
   = negotiation, they MUST be encrypt/decrypt using the running IV of that = negotiation.

and I believe it is = clear and also easy to implement.

Thanks,
Biao Wang
RouterWare = Inc.  


From ISAKMP draft = 10
--------------------
"The only = exception to this is when
the Commit Bit of = the ISAKMP Header is set.  When the Commit Bit is set,
the Message ID field = of the Informational Exchange MUST contain the Mes-
sage ID of the = original ISAKMP Phase 2 SA negotiation, rather than a new
Message ID (MID). = This is done to ensure that the Informational Exchange
with the CONNECTED = Notify Message can be associated with the correct Phase
2 SA."

"Notification = which occurs during, or is concerned with, a Phase 2 nego-
tiation is = identified by the Initiator and Responder cookie pair in the
ISAKMP Header and = the Message ID and SPI associated with the current nego-
tiation."

From IKE draft = 8
--------------------
"After the = ISAKMP SA has been authenticated all Informational
Exchanges are = encrypted using SKEYID_e. The initiaization vector for
these exchanges is = derived in exactly the same fashion as that for a
Quick Mode-- i.e. it = is derived from a hash of a concatenation of the
last phase 1 CBC = output block and the message id from the ISAKMP
header of the = Informational Exchange (not the message id from the
message that may = have prompted the Informational Exchange)."

------ =_NextPart_001_01BDCA28.40DBA710-- From owner-ipsec Tue Aug 18 05:06:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA22462 for ipsec-outgoing; Tue, 18 Aug 1998 05:00:51 -0400 (EDT) Date: Tue, 18 Aug 1998 12:15:41 +0300 (IDT) From: Hugo Krawczyk To: Yuri Poeluev cc: ipsec@tis.com Subject: Re: Encryption in aggressive mode (IKE draft) In-Reply-To: <35D8A30F.519A8A34@Certicom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Here there are some clarifications regarding the question in the attached note (about encrypting/not encrypting the third message in aggressive mode) There is no cryptographic functionality to the encryption of the third message in aggressive mode. Furthermore, under the encryption modes, there is some performance advantage if you do not encrypt that message. A short explanation: Case I: signature mode. In the case of signature mode the encryption of that message in the non-agressive version serves to hide the signatures and identities as required for providing anonymity of the end points from eavesddroppers. However in aggressive mode of the signature mode anonymity is not provided anyway (identities are sent in the clear in the first message) so the encryption of that message can be safely avoided. Case II: encryption mode. In encryption mode anonymity (or identity protection) is provided ALSO in aggressive mode. However, the third message does not need to be encrypted for this purpose since it does not carry any identity information. The advantage of NOT encrypting the third message is that it allows the parties to carry the computation of the DH key (g^xy) after the exchange is over. Indeed, the DH key is needed only to derive the SKEYID_* keys but those are not used during the phase I exchange. Hugo On Mon, 17 Aug 1998, Yuri Poeluev wrote: > Hello, > > I was reading ISAKMP & IKE documents, > and I have found that aggressive mode in IKE draft > is a bit different from one in ISAKMP draft. > > > > AGGRESSIVE EXCHANGE > > > >_#_____Initiator___Direction______Responder________________________NOTE____________________ > > >(1) HDR; SA; KE; => Begin ISAKMP-SA or > Proxy negotiation > > NONCE; IDii and Key Exchange > > > >(2) <= HDR; SA; KE; > > NONCE; IDir; AUTH > > Initiator Identity > Verified by Responder > > Key Generated > > Basic SA agreed upon > >(3) HDR*; AUTH => > > Responder Identity > Verified by Initiator > > SA established > > Note that the last message is encrypted here, except the header of > course. > Now, let's take a look at what we have in IKE draft. > > Section 5.1: > > > Aggressive mode with signatures in conjunction with ISAKMP is > > described as follows: > > > > Initiator Responder > > ----------- ----------- > > HDR, SA, KE, Ni, IDii --> > > <-- HDR, SA, KE, Nr, IDir, > > [ CERT, ] SIG_R > > HDR, [ CERT, ] SIG_I --> > > > Section 5.2: > > > Aggressive Mode authenticated with encryption is described as > > follows: > > > > Initiator Responder > > ----------- ----------- > > HDR, SA, [ HASH(1),] KE, > > Pubkey_r, > > Pubkey_r --> > > HDR, SA, KE, PubKey_i, > > > <-- PubKey_i, HASH_R > > HDR, HASH_I --> > > Section 5.3: > > > Aggressive Mode authenticated with the revised encryption method is > > described as follows: > > > > Initiator Responder > > ----------- ----------- > > HDR, SA, [ HASH(1),] > > Pubkey_r, > > Ke_i, Ke_i > > [, Ke_i ] --> > > HDR, SA, PubKey_i, > > Ke_r, Ke_r, > > > <-- HASH_R > > HDR, HASH_I --> > > Section 5.4: > > > Aggressive mode with a pre-shared key is described as follows: > > > > Initiator Responder > > ----------- ----------- > > HDR, SA, KE, Ni, IDii --> > > <-- HDR, SA, KE, Nr, IDir, HASH_R > > HDR, HASH_I --> > > In all above cases, the last message is not encrypted, which contradicts > > aggressive mode in ISAKMP draft. > > For instance, instead > > > HDR, HASH_I --> > > we would expect > > > HDR*, HASH_I --> > > > I propose that all payloads following the header > in the last message must be encrypted and IKE draft > must be changed accordingly. > > I assume, there might be a reason for what > we have in IKE draft now. But since initiator > and responder have finished KE exchange, > we should be able to encrypt any following > message. There is no reason for waiting. > > Thanks, > Yuri Poeluev > Certicom Corp. > From owner-ipsec Tue Aug 18 07:35:51 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA23004 for ipsec-outgoing; Tue, 18 Aug 1998 07:35:04 -0400 (EDT) From: dbastien@galea.com X-Lotus-FromDomain: GALEA To: Yuri Poeluev , ipsec@tis.com Message-ID: <85256664.003E9CEC.00@gotlib.galea.com> Date: Tue, 18 Aug 1998 07:45:34 -0400 Subject: Re: Encryption in aggressive mode (IKE draft) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@ex.tis.com Precedence: bulk Two points highligth the need to not do the encryption in the last message: 1. from section 5 (draft-ipsec-isakmp-oakley-08) > Security Association negotiation is limited with Aggressive Mode. Due > to message construction requirements the group in which the Diffie- > Hellman exchange is performed cannot be negotiated. 2. from section 5.1 (draft-ipsec-isakmp-10) >1. Set a timer and initialize a retry counter. > > NOTE: Implementations MUST NOT use a fixed timer. Instead, > transmission timer values should be adjusted dynamically based on > measured round trip times. In addition, successive retransmissions > of the same packet should be separated by increasingly longer time > intervals (e.g., exponential backoff). > >2. If the timer expires, the ISAKMP message is resent and the retry > counter is decremented. > >3. If the retry counter reaches zero (0), the event, RETRY LIMIT > REACHED, MAY be logged in the appropriate system audit file. If you want to respect the note in the isakmp draft for the round-trip you need a system fast enough to compute g^xy within 4 round trip times. Otherwise the responder delete the SA because a RETRY LIMIT REACHED occur. Dominque Bastien dbastien@galea.com From owner-ipsec Tue Aug 18 09:39:48 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA23731 for ipsec-outgoing; Tue, 18 Aug 1998 09:38:55 -0400 (EDT) Message-ID: <35D9881B.437717C7@Certicom.com> Date: Tue, 18 Aug 1998 09:56:43 -0400 From: Yuri Poeluev Organization: Certicom Corp. X-Mailer: Mozilla 4.01 [en] (WinNT; U) MIME-Version: 1.0 To: Hugo Krawczyk CC: ipsec@tis.com Subject: Re: Encryption in aggressive mode (IKE draft) X-Priority: 3 (Normal) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Hugo, Thanks for clarifications on this matter. I agree with the reasons you wrote about. However, this mode is not exactly the mode described in "draft-ietf-ipsec-isakmp-10". Those reasons would be successfully applied to "draft-ietf-ipsec-isakmp-10" draft, don't you agree? Should it not be a new aggressive mode ("revised" ) in "draft-ietf-ipsec-isakmp-oakley-08" draft? If not, I suggest, aggressive mode in "draft-ietf-ipsec-isakmp-10" must have no encryption as well as "his brother" :-) in "draft-ietf-ipsec-isakmp-oakley-08". Thanks, Yuri Hugo Krawczyk wrote: > Here there are some clarifications regarding the question in the > attached note (about encrypting/not encrypting the third message > in aggressive mode) > > There is no cryptographic functionality to the encryption of the third > > message in aggressive mode. Furthermore, under the encryption modes, > there is some performance advantage if you do not encrypt that > message. > A short explanation: > > Case I: signature mode. > In the case of signature mode the encryption of that message > in the non-agressive version serves to hide the signatures > and identities as required for providing anonymity of the end points > from eavesddroppers. However in aggressive mode of the signature > mode anonymity is not provided anyway (identities are sent in the > clear > in the first message) so the encryption of that message can be safely > avoided. > > Case II: encryption mode. > In encryption mode anonymity (or identity protection) is provided ALSO > in > aggressive mode. However, the third message does not need to be > encrypted for this purpose since it does not carry any identity > information. > The advantage of NOT encrypting the third message is that it allows > the parties to carry the computation of the DH key (g^xy) after > the exchange is over. Indeed, the DH key is needed only to derive the > SKEYID_* keys but those are not used during the phase I exchange. > > Hugo > > On Mon, 17 Aug 1998, Yuri Poeluev wrote: > > > Hello, > > > > I was reading ISAKMP & IKE documents, > > and I have found that aggressive mode in IKE draft > > is a bit different from one in ISAKMP draft. > > > > > > > AGGRESSIVE EXCHANGE > > > > > > >_#_____Initiator___Direction______Responder________________________NOTE____________________ > > > > > >(1) HDR; SA; KE; => Begin ISAKMP-SA or > > > Proxy negotiation > > > NONCE; IDii and Key Exchange > > > > > >(2) <= HDR; SA; KE; > > > NONCE; IDir; AUTH > > > Initiator Identity > > > Verified by Responder > > > Key Generated > > > Basic SA agreed > upon > > >(3) HDR*; AUTH => > > > Responder Identity > > > Verified by Initiator > > > SA established > > > > Note that the last message is encrypted here, except the header of > > course. > > Now, let's take a look at what we have in IKE draft. > > > > Section 5.1: > > > > > Aggressive mode with signatures in conjunction with ISAKMP is > > > described as follows: > > > > > > Initiator Responder > > > ----------- ----------- > > > HDR, SA, KE, Ni, IDii --> > > > <-- HDR, SA, KE, Nr, IDir, > > > [ CERT, ] SIG_R > > > HDR, [ CERT, ] SIG_I --> > > > > > > Section 5.2: > > > > > Aggressive Mode authenticated with encryption is described as > > > follows: > > > > > > Initiator Responder > > > ----------- ----------- > > > HDR, SA, [ HASH(1),] KE, > > > Pubkey_r, > > > Pubkey_r --> > > > HDR, SA, KE, > PubKey_i, > > > > > <-- PubKey_i, > HASH_R > > > HDR, HASH_I --> > > > > Section 5.3: > > > > > Aggressive Mode authenticated with the revised encryption method > is > > > described as follows: > > > > > > Initiator Responder > > > ----------- ----------- > > > HDR, SA, [ HASH(1),] > > > Pubkey_r, > > > Ke_i, Ke_i > > > [, Ke_i ] --> > > > HDR, SA, PubKey_i, > > > Ke_r, > Ke_r, > > > > > <-- HASH_R > > > HDR, HASH_I --> > > > > Section 5.4: > > > > > Aggressive mode with a pre-shared key is described as follows: > > > > > > Initiator Responder > > > ----------- ----------- > > > HDR, SA, KE, Ni, IDii --> > > > <-- HDR, SA, KE, Nr, IDir, > HASH_R > > > HDR, HASH_I --> > > > > In all above cases, the last message is not encrypted, which > contradicts > > > > aggressive mode in ISAKMP draft. > > > > For instance, instead > > > > > HDR, HASH_I --> > > > > we would expect > > > > > HDR*, HASH_I --> > > > > > > I propose that all payloads following the header > > in the last message must be encrypted and IKE draft > > must be changed accordingly. > > > > I assume, there might be a reason for what > > we have in IKE draft now. But since initiator > > and responder have finished KE exchange, > > we should be able to encrypt any following > > message. There is no reason for waiting. > > > > Thanks, > > Yuri Poeluev > > Certicom Corp. > > From owner-ipsec Tue Aug 18 10:50:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA23929 for ipsec-outgoing; Tue, 18 Aug 1998 10:49:04 -0400 (EDT) Message-Id: <199808181504.IAA27230@chip.cisco.com> To: Yuri Poeluev cc: Hugo Krawczyk , ipsec@tis.com Subject: Re: Encryption in aggressive mode (IKE draft) In-reply-to: Your message of "Tue, 18 Aug 1998 09:56:43 EDT." <35D9881B.437717C7@Certicom.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27226.903452695.1@cisco.com> Date: Tue, 18 Aug 1998 08:04:56 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk IKE is using ISAKMP as a framework and a language in which to define exchanges. Some things are not exactly identical between the two. Aggressive mode is one of those things. The Informational Exchange is another. Look closer and you might find others. This is not a problem. By the way, suggestions to change either draft-ietf-ipsec-isakmp-oakley-08.txt or draft-ietf-ipsec-isakmp-10.txt are about 6 months late. Dan. On Tue, 18 Aug 1998 09:56:43 EDT you wrote > Hi Hugo, > > Thanks for clarifications on this matter. > I agree with the reasons you wrote about. > However, this mode is not exactly the mode > described in "draft-ietf-ipsec-isakmp-10". > Those reasons would be successfully applied to > "draft-ietf-ipsec-isakmp-10" draft, don't you agree? > Should it not be a new aggressive mode ("revised" ) > in "draft-ietf-ipsec-isakmp-oakley-08" draft? > If not, I suggest, aggressive mode in "draft-ietf-ipsec-isakmp-10" > must have no encryption as well as "his brother" :-) > in "draft-ietf-ipsec-isakmp-oakley-08". > > Thanks, > Yuri > > > Hugo Krawczyk wrote: > > > Here there are some clarifications regarding the question in the > > attached note (about encrypting/not encrypting the third message > > in aggressive mode) > > > > There is no cryptographic functionality to the encryption of the third > > > > message in aggressive mode. Furthermore, under the encryption modes, > > there is some performance advantage if you do not encrypt that > > message. > > A short explanation: > > > > Case I: signature mode. > > In the case of signature mode the encryption of that message > > in the non-agressive version serves to hide the signatures > > and identities as required for providing anonymity of the end points > > from eavesddroppers. However in aggressive mode of the signature > > mode anonymity is not provided anyway (identities are sent in the > > clear > > in the first message) so the encryption of that message can be safely > > avoided. > > > > Case II: encryption mode. > > In encryption mode anonymity (or identity protection) is provided ALSO > > in > > aggressive mode. However, the third message does not need to be > > encrypted for this purpose since it does not carry any identity > > information. > > The advantage of NOT encrypting the third message is that it allows > > the parties to carry the computation of the DH key (g^xy) after > > the exchange is over. Indeed, the DH key is needed only to derive the > > SKEYID_* keys but those are not used during the phase I exchange. > > > > Hugo > > > > On Mon, 17 Aug 1998, Yuri Poeluev wrote: > > > > > Hello, > > > > > > I was reading ISAKMP & IKE documents, > > > and I have found that aggressive mode in IKE draft > > > is a bit different from one in ISAKMP draft. > > > > > > > > > > AGGRESSIVE EXCHANGE > > > > > > > > > >_#_____Initiator___Direction______Responder________________________NOTE___ >_________________ > > > > > > > > >(1) HDR; SA; KE; => Begin ISAKMP-SA or > > > > > Proxy negotiation > > > > NONCE; IDii and Key Exchange > > > > > > > >(2) <= HDR; SA; KE; > > > > NONCE; IDir; AUTH > > > > Initiator Identity > > > > > Verified by Responder > > > > Key Generated > > > > Basic SA agreed > > upon > > > >(3) HDR*; AUTH => > > > > Responder Identity > > > > > Verified by Initiator > > > > SA established > > > > > > Note that the last message is encrypted here, except the header of > > > course. > > > Now, let's take a look at what we have in IKE draft. > > > > > > Section 5.1: > > > > > > > Aggressive mode with signatures in conjunction with ISAKMP is > > > > described as follows: > > > > > > > > Initiator Responder > > > > ----------- ----------- > > > > HDR, SA, KE, Ni, IDii --> > > > > <-- HDR, SA, KE, Nr, IDir, > > > > [ CERT, ] SIG_R > > > > HDR, [ CERT, ] SIG_I --> > > > > > > > > > Section 5.2: > > > > > > > Aggressive Mode authenticated with encryption is described as > > > > follows: > > > > > > > > Initiator Responder > > > > ----------- ----------- > > > > HDR, SA, [ HASH(1),] KE, > > > > Pubkey_r, > > > > Pubkey_r --> > > > > HDR, SA, KE, > > PubKey_i, > > > > > > > <-- PubKey_i, > > HASH_R > > > > HDR, HASH_I --> > > > > > > Section 5.3: > > > > > > > Aggressive Mode authenticated with the revised encryption method > > is > > > > described as follows: > > > > > > > > Initiator Responder > > > > ----------- ----------- > > > > HDR, SA, [ HASH(1),] > > > > Pubkey_r, > > > > Ke_i, Ke_i > > > > [, Ke_i ] --> > > > > HDR, SA, PubKey_i, > > > > Ke_r, > > Ke_r, > > > > > > > <-- HASH_R > > > > HDR, HASH_I --> > > > > > > Section 5.4: > > > > > > > Aggressive mode with a pre-shared key is described as follows: > > > > > > > > Initiator Responder > > > > ----------- ----------- > > > > HDR, SA, KE, Ni, IDii --> > > > > <-- HDR, SA, KE, Nr, IDir, > > HASH_R > > > > HDR, HASH_I --> > > > > > > In all above cases, the last message is not encrypted, which > > contradicts > > > > > > aggressive mode in ISAKMP draft. > > > > > > For instance, instead > > > > > > > HDR, HASH_I --> > > > > > > we would expect > > > > > > > HDR*, HASH_I --> > > > > > > > > > I propose that all payloads following the header > > > in the last message must be encrypted and IKE draft > > > must be changed accordingly. > > > > > > I assume, there might be a reason for what > > > we have in IKE draft now. But since initiator > > > and responder have finished KE exchange, > > > we should be able to encrypt any following > > > message. There is no reason for waiting. > > > > > > Thanks, > > > Yuri Poeluev > > > Certicom Corp. > > > > > > From owner-ipsec Tue Aug 18 10:56:12 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA23976 for ipsec-outgoing; Tue, 18 Aug 1998 10:56:04 -0400 (EDT) Date: Tue, 18 Aug 1998 18:10:57 +0300 (IDT) From: Hugo Krawczyk To: Yuri Poeluev cc: ipsec@tis.com Subject: Re: Encryption in aggressive mode (IKE draft) In-Reply-To: <35D9881B.437717C7@Certicom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Now that isakmp and ike are moved to proposed standards I would suggest that any inconsistencies between those are generally resolved in favor of IKE. The latter is responsible for defining the details of the key exchange protocol. The former is a protocol framework. Hugo On Tue, 18 Aug 1998, Yuri Poeluev wrote: > Hi Hugo, > > Thanks for clarifications on this matter. > I agree with the reasons you wrote about. > However, this mode is not exactly the mode > described in "draft-ietf-ipsec-isakmp-10". > Those reasons would be successfully applied to > "draft-ietf-ipsec-isakmp-10" draft, don't you agree? > Should it not be a new aggressive mode ("revised" ) > in "draft-ietf-ipsec-isakmp-oakley-08" draft? > If not, I suggest, aggressive mode in "draft-ietf-ipsec-isakmp-10" > must have no encryption as well as "his brother" :-) > in "draft-ietf-ipsec-isakmp-oakley-08". > > Thanks, > Yuri > > > Hugo Krawczyk wrote: > > > Here there are some clarifications regarding the question in the > > attached note (about encrypting/not encrypting the third message > > in aggressive mode) > > > > There is no cryptographic functionality to the encryption of the third > > > > message in aggressive mode. Furthermore, under the encryption modes, > > there is some performance advantage if you do not encrypt that > > message. > > A short explanation: > > > > Case I: signature mode. > > In the case of signature mode the encryption of that message > > in the non-agressive version serves to hide the signatures > > and identities as required for providing anonymity of the end points > > from eavesddroppers. However in aggressive mode of the signature > > mode anonymity is not provided anyway (identities are sent in the > > clear > > in the first message) so the encryption of that message can be safely > > avoided. > > > > Case II: encryption mode. > > In encryption mode anonymity (or identity protection) is provided ALSO > > in > > aggressive mode. However, the third message does not need to be > > encrypted for this purpose since it does not carry any identity > > information. > > The advantage of NOT encrypting the third message is that it allows > > the parties to carry the computation of the DH key (g^xy) after > > the exchange is over. Indeed, the DH key is needed only to derive the > > SKEYID_* keys but those are not used during the phase I exchange. > > > > Hugo > > > > On Mon, 17 Aug 1998, Yuri Poeluev wrote: > > > > > Hello, > > > > > > I was reading ISAKMP & IKE documents, > > > and I have found that aggressive mode in IKE draft > > > is a bit different from one in ISAKMP draft. > > > > > > > > > > AGGRESSIVE EXCHANGE > > > > > > > > > >_#_____Initiator___Direction______Responder________________________NOTE____________________ > > > > > > > > >(1) HDR; SA; KE; => Begin ISAKMP-SA or > > > > > Proxy negotiation > > > > NONCE; IDii and Key Exchange > > > > > > > >(2) <= HDR; SA; KE; > > > > NONCE; IDir; AUTH > > > > Initiator Identity > > > > > Verified by Responder > > > > Key Generated > > > > Basic SA agreed > > upon > > > >(3) HDR*; AUTH => > > > > Responder Identity > > > > > Verified by Initiator > > > > SA established > > > > > > Note that the last message is encrypted here, except the header of > > > course. > > > Now, let's take a look at what we have in IKE draft. > > > > > > Section 5.1: > > > > > > > Aggressive mode with signatures in conjunction with ISAKMP is > > > > described as follows: > > > > > > > > Initiator Responder > > > > ----------- ----------- > > > > HDR, SA, KE, Ni, IDii --> > > > > <-- HDR, SA, KE, Nr, IDir, > > > > [ CERT, ] SIG_R > > > > HDR, [ CERT, ] SIG_I --> > > > > > > > > > Section 5.2: > > > > > > > Aggressive Mode authenticated with encryption is described as > > > > follows: > > > > > > > > Initiator Responder > > > > ----------- ----------- > > > > HDR, SA, [ HASH(1),] KE, > > > > Pubkey_r, > > > > Pubkey_r --> > > > > HDR, SA, KE, > > PubKey_i, > > > > > > > <-- PubKey_i, > > HASH_R > > > > HDR, HASH_I --> > > > > > > Section 5.3: > > > > > > > Aggressive Mode authenticated with the revised encryption method > > is > > > > described as follows: > > > > > > > > Initiator Responder > > > > ----------- ----------- > > > > HDR, SA, [ HASH(1),] > > > > Pubkey_r, > > > > Ke_i, Ke_i > > > > [, Ke_i ] --> > > > > HDR, SA, PubKey_i, > > > > Ke_r, > > Ke_r, > > > > > > > <-- HASH_R > > > > HDR, HASH_I --> > > > > > > Section 5.4: > > > > > > > Aggressive mode with a pre-shared key is described as follows: > > > > > > > > Initiator Responder > > > > ----------- ----------- > > > > HDR, SA, KE, Ni, IDii --> > > > > <-- HDR, SA, KE, Nr, IDir, > > HASH_R > > > > HDR, HASH_I --> > > > > > > In all above cases, the last message is not encrypted, which > > contradicts > > > > > > aggressive mode in ISAKMP draft. > > > > > > For instance, instead > > > > > > > HDR, HASH_I --> > > > > > > we would expect > > > > > > > HDR*, HASH_I --> > > > > > > > > > I propose that all payloads following the header > > > in the last message must be encrypted and IKE draft > > > must be changed accordingly. > > > > > > I assume, there might be a reason for what > > > we have in IKE draft now. But since initiator > > > and responder have finished KE exchange, > > > we should be able to encrypt any following > > > message. There is no reason for waiting. > > > > > > Thanks, > > > Yuri Poeluev > > > Certicom Corp. > > > > > > From owner-ipsec Tue Aug 18 11:15:48 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA24035 for ipsec-outgoing; Tue, 18 Aug 1998 11:15:13 -0400 (EDT) Date: Tue, 18 Aug 1998 18:30:58 +0300 (IDT) From: Hugo Krawczyk Reply-To: Hugo Krawczyk To: ipsec@tis.com Subject: encryption mode and CCA attacks Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Now that I am into IKE stuff: There is one issue that I wanted to raise for long time for those implementing the encryption mode(s). If you read our internet-draft draft-ietf-ipsec-dhless-enc-mode-00.txt you'll see the following pargraph in the security considerations: The public key encryption modes of authentication in IKE require strong public key encryption. In particular, resistance to strong attacks generally known as "chosen ciphertext attacks" (CCA) is necessary. This is a practical need as well as the basis for a sound analysis of these protocols [BeCaKr]. Recently, an explicit chosen ciphertext attack on the PKCS #1 encryption standard was demonstrated [Ble]. RSA Labs., the authors of PKCS#1, are preparing a new release of PKCS #1 that will include the OAEP format of RSA encryption [RSAlabs]. It is strongly recommended that IKE specifications and implementations move to that format which was designed to resist CCA and other attacks. This recommendation should be followed by the implementers of the current IKE encryption modes that use PKCS RSA encryption (and not only by those interested in a DH-less mode as proposed in the mentioned draft). Hugo From owner-ipsec Tue Aug 18 11:23:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA24080 for ipsec-outgoing; Tue, 18 Aug 1998 11:23:15 -0400 (EDT) Date: Tue, 18 Aug 1998 18:39:10 +0300 (IDT) From: Hugo Krawczyk Reply-To: Hugo Krawczyk To: ipsec@tis.com Subject: password-based authentication Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk And one more: if you are among those that care about doing IKE using human passwords, you may want to take a look at the paper: "Public-key Cryptography and Password Protocols" by Halevi and Krawczyk. The paper will appear in the upcoming ACM Security conference. Hugo From owner-ipsec Tue Aug 18 12:41:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA24286 for ipsec-outgoing; Tue, 18 Aug 1998 12:39:32 -0400 (EDT) Date: Tue, 18 Aug 1998 19:54:59 +0300 (IDT) From: Hugo Krawczyk Reply-To: Hugo Krawczyk To: ipsec@tis.com Subject: Re: password-based authentication In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk I am sorry. In the attached message I forgot to add the following "essential" piece of information :( The paper can be retrieved via http://www.research.ibm.com/security/pub-passw.ps Hugo > > And one more: > if you are among those that care about doing IKE > using human passwords, you may want to take a look at > the paper: > "Public-key Cryptography and Password Protocols" > by Halevi and Krawczyk. > The paper will appear in the upcoming ACM Security conference. > > Hugo > > From owner-ipsec Wed Aug 19 13:23:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA01132 for ipsec-outgoing; Wed, 19 Aug 1998 13:15:48 -0400 (EDT) Date: Wed, 19 Aug 1998 13:30:00 -0700 X-Priority: 3 From: "Goss, Chad" Subject: Certificates, CRLs and Security Associations To: ipsec@tis.com Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8Bit Content-Disposition: inline Sender: owner-ipsec@ex.tis.com Precedence: bulk I have been reviewing ISAKMP and IKE particularly with respect to use of certificates, and certificate path validation during signature validation and have a couple of questions: 1. In ISAKMP section 5.10 and in IKE section 5.1, no mention of CRLs is made in the description of signature validation. Should a CRL be consulted to determine the signing certificates status?, should either of the standards reference possibly the PKIX or ANSI work defining certificate path validation? 2. If it makes sense to introduce CRL checks for certificate status, should an effort be made to allow ISAKMP SA content invalidation for that which was established using a revoked certificate? In other words if a CRL is received can we identify and terminate active SAs that were created using revoked certificates? if so how would an application identify the SA to terminate based on the entry in the CRL which is merely a serial number, revocation date and issuer DN? If anyone could point me to the draft that details this it would be a big help regards -chad ***************************************************************************** Chad Goss 978-287-6288 Senior Software Engineer chad.goss@tccmail.fabrik.com Technical Communications Corporation 100 Domino Drive, Concord Ma. 01742 ***************************************************************************** From owner-ipsec Wed Aug 19 15:47:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA01698 for ipsec-outgoing; Wed, 19 Aug 1998 15:45:09 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF32A36F@exchange.timestep.com> From: Tim Jenkins To: ipsec@tis.com Subject: IPCOMP and Tunnel Mode Date: Wed, 19 Aug 1998 16:03:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BDCBAC.62514C20" 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_001_01BDCBAC.62514C20 Content-Type: text/plain; charset="iso-8859-1" I have some concerns about one of the requirements of the IPCOMP draft. It states that if no compression is actually done, no IPCOMP header should be added. While this may be fine in transport mode, it leads to the appearance of an IP-in-IP packet in tunnel mode. This concerns me, since it seems that the only way to be sure that the inbound IPCOMP SA should handle packet is to perform an SA lookup to see if it should have been compressed. (Issues of policy verification on inbound packets are intentionally left out of this discussion.) This leads to inconsistent processing of inbound SAs. As an alternative, I implemented using one of the flag bits to indicate that there was no compression and left the IPCOMP header in. This allowed a consistent lookup on inbound processing for an SA based on SPI (or the IPCOMP equivalent). I have also implemented the policy lookup method, and the full-time use of the IPCOMP header was much cleaner... Comments encouraged (although I doubt most of you need that...) :-) --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 ------_=_NextPart_001_01BDCBAC.62514C20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPCOMP and Tunnel Mode

I have some concerns about one of the = requirements of the IPCOMP draft. It states that if no compression is = actually done, no IPCOMP header should be added. While this may be fine = in transport mode, it leads to the appearance of an IP-in-IP packet in = tunnel mode.

This concerns me, since it seems that = the only way to be sure that the inbound IPCOMP SA should handle packet = is to perform an SA lookup to see if it should have been compressed. = (Issues of policy verification on inbound packets are intentionally = left out of this discussion.) This leads to inconsistent processing of = inbound SAs.

As an alternative, I implemented using = one of the flag bits to indicate that there was no compression and left = the IPCOMP header in. This allowed a consistent lookup on inbound = processing for an SA based on SPI (or the IPCOMP equivalent). I have = also implemented the policy lookup method, and the full-time use of the = IPCOMP header was much cleaner...

Comments encouraged (although I doubt = most of you need that...) :-)

---
Tim = Jenkins           = ;            = TimeStep Corporation
tjenkins@timestep.com       &nbs= p;  http://www.timestep.com
(613) 599-3610 = x4304           &= nbsp;   Fax: (613) 599-3617

------_=_NextPart_001_01BDCBAC.62514C20-- From owner-ipsec Wed Aug 19 22:17:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA02888 for ipsec-outgoing; Wed, 19 Aug 1998 22:16:19 -0400 (EDT) Message-Id: <3.0.2.32.19980819193220.006c5024@airedale.cisco.com> X-Sender: shacham@airedale.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Wed, 19 Aug 1998 19:32:20 -0700 To: Tim Jenkins From: Avram Shacham Subject: Re: IPCOMP and Tunnel Mode Cc: ipsec@tis.com, ippcp@external.cisco.com In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDF32A36F@exchange.timestep.c om> Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Tim, At 04:03 PM 8/19/98 -0400, Tim Jenkins wrote: >>>> ArialI have some concerns about one of the requirements of the IPCOMP draft. It states that if no compression is actually done, no IPCOMP header should be added. While this may be fine in transport mode, it leads to the appearance of an IP-in-IP packet in tunnel mode. ArialThis concerns me, since it seems that the only way to be sure that the inbound IPCOMP SA should handle packet is to perform an SA lookup to see if it should have been compressed. (Issues of policy verification on inbound packets are intentionally left out of this discussion.) This leads to inconsistent processing of inbound SAs. ArialAs an alternative, I implemented using one of the flag bits to indicate that there was no compression and left the IPCOMP header in. This allowed a consistent lookup on inbound processing for an SA based on SPI (or the IPCOMP equivalent). I have also implemented the policy lookup method, and the full-time use of the IPCOMP header was much cleaner... ArialComments encouraged (although I doubt most of you need that...) :-) The draft (rfc?) (sorry Dan, I could not avoid following your style :), while defining the non-expansion policy, explains the reason for not adding the IPCOMP header in that scenario (see the marked lines): 2.2. Non-Expansion Policy If the total size of a compressed ULP payload and the IPComp header, as defined in section 3, is not smaller than the size of the original ULP payload, the IP datagram MUST be sent in the original non-compressed form. To clarify: If an IP datagram is sent non-compressed, no IPComp header is added to the datagram. This | policy ensures saving the decompression processing cycles and | avoiding incurring IP datagram fragmentation when the expanded | datagram is larger than MTU. In other words, when the size of a non-compressible packet is MTU, your suggestion to add the IPCOMP header will cause packet fragmentation. The wg debated having always an IPCOMP header, even when the packet in sent without compression. As such policy is actually equivalent to lowering the MTU by four octets, the wg decided to reject this proposal. In addition, your implementation does not comply with the requirement to set the flags field to zero: 3.3. IPComp Header Structure [snip] Flags 8-bit field. Reserved for future use. MUST be set to zero. MUST be ignored by the receiving node. As for the implementation issues that you raised, there were several interoperable stacks with IPComp in the bake-off last March, so working draft-compliant solutions do exist. Regards, avram From owner-ipsec Thu Aug 20 07:56:42 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA04252 for ipsec-outgoing; Thu, 20 Aug 1998 07:54:28 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF32A41B@exchange.timestep.com> From: Tim Jenkins To: Avram Shacham Cc: ipsec@tis.com, ippcp@external.cisco.com Subject: RE: IPCOMP and Tunnel Mode Date: Thu, 20 Aug 1998 08:08:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BDCC33.41AA0CC0" 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_001_01BDCC33.41AA0CC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The attempt to avoid possible fragmentation is a good one (your wording "will" is too strong), however: 1) No compression occurs for small packet sizes (below the threshold of = the particular algorithm) 2) We're talking IPSec tunnel mode, which has to add another IP header, = so the packet's going to grow anyway 3) The IPComp header is 4 bytes. =A0 Thus, the net increase is 24 bytes. If we assume that the smallest MTU = in the network is 576 bytes, that means that packets that don't get = compressed that are 552 bytes to 556 bytes in size will cause fragmentation under = these conditions. What is the probability that there will be no compression = of packets of that size? =A0 Does someone have any statistics on the probability of larger packets expanding during compression, thus not being compressed, so that this = can be used as part of this discussion? =A0 On the issue of the flags: The bits are there. If they can be made to provide some useful purpose, they should. I note that this document (draft-ietf-ippcp-protocol-06.txt) was *not* one of those advanced to Proposed Standard. The document also states that the flag bits are = reserved for future use. Perhaps this could be a future use. =A0 This discussion is based on the trade-offs between performance at the network level (possible fragmentation) and performance at the = computational level (inconsistent implementation). Given equal probability of = impacting both, I would design in favour of the network. However, in this case, I don't know that the probabilities favour the network. ---=20 Tim = Jenkins=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= TimeStep Corporation=20 tjenkins@timestep.com=A0=A0=A0=A0=A0=A0=A0=A0=A0 = http://www.timestep.com =20 (613) 599-3610 x4304=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Fax: = (613) 599-3617=20 =A0 -----Original Message----- From: Avram Shacham [mailto:shacham@cisco.com] Sent: Wednesday, August 19, 1998 10:32 PM To: Tim Jenkins Cc: ipsec@tis.com; ippcp@external.cisco.com Subject: Re: IPCOMP and Tunnel Mode Tim,=20 At 04:03 PM 8/19/98 -0400, Tim Jenkins wrote:=20 >>>>=20 I have some concerns about one of the requirements of the IPCOMP draft. = It states that if no compression is actually done, no IPCOMP header should = be added. While this may be fine in transport mode, it leads to the = appearance of an IP-in-IP packet in tunnel mode.=20 This concerns me, since it seems that the only way to be sure that the inbound IPCOMP SA should handle packet is to perform an SA lookup to = see if it should have been compressed. (Issues of policy verification on = inbound packets are intentionally left out of this discussion.) This leads to inconsistent processing of inbound SAs.=20 As an alternative, I implemented using one of the flag bits to indicate = that there was no compression and left the IPCOMP header in. This allowed a consistent lookup on inbound processing for an SA based on SPI (or the IPCOMP equivalent). I have also implemented the policy lookup method, = and the full-time use of the IPCOMP header was much cleaner...=20 Comments encouraged (although I doubt most of you need that...) :-)=20 The draft (rfc?) (sorry Dan, I could not avoid following your style :), while defining the non-expansion policy, explains the reason for not = adding the IPCOMP header in that scenario (see the marked lines):=20 2.2. Non-Expansion Policy=20 If the total size of a compressed ULP payload and the IPComp header,=20 as defined in section 3, is not smaller than the size of the original=20 ULP payload, the IP datagram MUST be sent in the original=20 non-compressed form. To clarify: If an IP datagram is sent=20 non-compressed, no IPComp header is added to the datagram. This=20 | policy ensures saving the decompression processing cycles and=20 | avoiding incurring IP datagram fragmentation when the expanded=20 | datagram is larger than MTU.=20 In other words, when the size of a non-compressible packet is MTU, your suggestion to add the IPCOMP header will cause packet fragmentation.=20 The wg debated having always an IPCOMP header, even when the packet in = sent without compression. As such policy is actually equivalent to lowering = the MTU by four octets, the wg decided to reject this proposal.=20 In addition, your implementation does not comply with the requirement = to set the flags field to zero:=20 3.3. IPComp Header Structure=20 [snip]=20 Flags=20 8-bit field. Reserved for future use. MUST be set to zero.=20 MUST be ignored by the receiving node.=20 As for the implementation issues that you raised, there were several interoperable stacks with IPComp in the bake-off last March, so working draft-compliant solutions do exist.=20 Regards,=20 avram=20 ------_=_NextPart_001_01BDCC33.41AA0CC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The=20 attempt to avoid possible fragmentation is a good one (your wording=20 "will" is too strong), however:
1) No compression occurs for small packet sizes = (below the=20 threshold of the particular algorithm)
2) We're talking IPSec tunnel mode, which has to = add another=20 IP header, so the packet's going to grow anyway
3) The IPComp header is 4 = bytes.
 
Thus,=20 the net increase is 24 bytes. If we assume that the smallest MTU in the = network=20 is 576 bytes, that means that packets that don't get compressed that = are 552=20 bytes to 556 bytes in size will cause fragmentation under these = conditions. What=20 is the probability that there will be no compression of packets of that = size?
 
Does=20 someone have any statistics on the probability of larger packets = expanding=20 during compression, thus not being compressed, so that this can be used = as part=20 of this discussion?
 
On the=20 issue of the flags: The bits are there. If they can be made to provide = some=20 useful purpose, they should. I note that this document=20 (draft-ietf-ippcp-protocol-06.txt) was *not* one of those advanced to = Proposed=20 Standard. The document also states that the flag bits are reserved for = future=20 use. Perhaps this could be a future use.
 
This=20 discussion is based on the trade-offs between performance at the = network level=20 (possible fragmentation) and performance at the computational level=20 (inconsistent implementation). Given equal probability of impacting = both, I=20 would design in favour of the network. However, in this case, I don't = know that=20 the probabilities favour the network.

---
Tim=20 Jenkins           = ;           =20 TimeStep Corporation
tjenkins@timestep.com       =   =20 http://www.timestep.com
(613) 599-3610=20 x4304           &= nbsp;  =20 Fax: (613) 599-3617

 
-----Original Message-----
From: Avram Shacham=20 [mailto:shacham@cisco.com]
Sent: Wednesday, August 19, = 1998 10:32=20 PM
To: Tim Jenkins
Cc: ipsec@tis.com;=20 ippcp@external.cisco.com
Subject: Re: IPCOMP and Tunnel=20 Mode

Tim,


At 04:03 PM 8/19/98 -0400, Tim Jenkins wrote:

>>>>


I have some concerns about one of = the=20 requirements of the IPCOMP draft. It states that if no compression = is=20 actually done, no IPCOMP header should be added. While this may be = fine in=20 transport mode, it leads to the appearance of an IP-in-IP packet in = tunnel=20 mode.


This concerns me, since it seems = that the only=20 way to be sure that the inbound IPCOMP SA should handle packet is = to perform=20 an SA lookup to see if it should have been compressed. (Issues of = policy=20 verification on inbound packets are intentionally left out of this=20 discussion.) This leads to inconsistent processing of inbound SAs.=20


As an alternative, I implemented = using one of the=20 flag bits to indicate that there was no compression and left the = IPCOMP=20 header in. This allowed a consistent lookup on inbound processing = for an SA=20 based on SPI (or the IPCOMP equivalent). I have also implemented = the policy=20 lookup method, and the full-time use of the IPCOMP header was much=20 cleaner...


Comments encouraged (although I = doubt most of you=20 need that...) :-)


The draft (rfc?) (sorry Dan, I could not avoid following your = style :),=20 while defining the non-expansion policy, explains the reason for = not adding=20 the IPCOMP header in that scenario (see the marked lines):


2.2. Non-Expansion Policy


If the total size of a compressed ULP payload and the IPComp = header,

as defined in section 3, is not smaller than the size of the = original=20

ULP payload, the IP datagram MUST be sent in the original

non-compressed form. To clarify: If an IP datagram is sent

non-compressed, no IPComp header is added to the datagram. This =

| policy ensures saving the decompression processing cycles and =

| avoiding incurring IP datagram fragmentation when the expanded =

| datagram is larger than MTU.


In other words, when the size of a non-compressible packet is = MTU, your=20 suggestion to add the IPCOMP header will cause packet = fragmentation.=20


The wg debated having always an IPCOMP header, even when the = packet in=20 sent without compression. As such policy is actually equivalent to = lowering=20 the MTU by four octets, the wg decided to reject this proposal. =


In addition, your implementation does not comply with the = requirement to=20 set the flags field to zero:


3.3. IPComp Header Structure


[snip]


Flags


8-bit field. Reserved for future use. MUST be set to zero.

MUST be ignored by the receiving node.


As for the implementation issues that you raised, there were = several=20 interoperable stacks with IPComp in the bake-off last March, so = working=20 draft-compliant solutions do exist.


Regards,

avram






------_=_NextPart_001_01BDCC33.41AA0CC0-- From owner-ipsec Thu Aug 20 09:05:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA04675 for ipsec-outgoing; Thu, 20 Aug 1998 09:04:28 -0400 (EDT) Message-Id: <3.0.5.32.19980820091759.007e0100@world.std.com> X-Sender: dpj@world.std.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 20 Aug 1998 09:17:59 -0400 To: Hugo Krawczyk , shaih@watson.ibm.com From: David Jablon Subject: Re: password-based authentication 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 Some comments to Hugo Krawczyk and Shai Halevi on their recent paper follow, plus a suggested enhancement. At 06:39 PM 8/18/98 +0300, Hugo Krawczyk wrote: >if you are among those that care about doing IKE >using human passwords, you may want to take a look at >the paper: >"Public-key Cryptography and Password Protocols" >by Halevi and Krawczyk. >The paper will appear in the upcoming ACM Security conference. Hugo and Shai, Thanks for making your paper available to the IPSEC mailing list. I was fascinated by your proof that public-key crypto is necessary for optimal password verification, as many have suspected. But in your focus on proving resistance to eavesdropper attack, I think you've overlooked other equally important characteristics of "zero-knowledge" methods. You've cited several methods, such as EKE, which can prove knowledge of a password without revealing it to anyone. But, beyond stating that these methods rely on heuristic assumptions, the paper doesn't analyze or compare these techniques with alternatives, and the protocol shown (proposed as suitable for IPSEC) does not provide their full benefit. This seems inconsistent with your struggle towards optimal security, and your inclusion of other enhancements that rely on a "merely-heuristic" basis for security. Fortunately, I think there are natural ways to apply EKE-style techniques to strengthen your method. I'll show some reasons for doing this, and one specific enhancement. Consider your "Mutual Authentication and DH Key Exchange" method, using notation adapted from the paper: ----------------------------------------------------------------- spwd the shared password (perhaps small) pk_s server's public key (perhaps uncertified) f a challenge/response-style hash function g a Diffie-Hellman generator r,x random numbers chosen by server (S) k,y random numbers chosen by user (U) k' negotiated Diffie-Hellman key Protocol: S->U: r, g^x, pk_s U: t = f(spwd; r, g^x, g^y, k, U, S) c = ENC_pk_s(k, t) U->S: g^y, c S->U: z = PRF_k(c) U,S: k' = PRF_k(g^(x y)) ----------------------------------------------------------------- The weakness here is in using an ordinary challenge/response function for t: Whenever pk_s is not properly verified, an attacker masquerading as S can perform an off-line attack on t to determine the password. This can happen in several ways: (1) U thoughtlessly hits "Enter" or "OK" when asked if the key is valid. This one motivated your suggestion to display a list of "public passwords" (a.k.a. "fingerprints" for PGP fans) from which the user would select the correct one. (2) U finds the displayed public password in the list ("moss mont ton half vary pit"), glances at the card from his pocket to confirm it, but doesn't notice that it isn't a perfect match (The real key is "moss mont ton rear rage fun"). (3) U notices that the keys don't match, but thinks they're "close enough". (Hey, I said "U", not me! :-) (4) Instead of using a card, U blindly trusts a simplistic verification system, where anyone with $10 and an email address gets a "certified" key. (5) U's system makes key verification optional, and U neglects to use it. (6) U confirms that the key corresponds to a named provider, but doesn't notice that the name isn't quite right. One might argue that a well-designed system with well informed and well behaved users won't permit such mistakes, but we all know that kind of stuff happens. All these attacks are blocked when the password is mutually verified using a zero-knowledge trick, if U shares the password only with the intended party. This automatically prevents others from cracking the password, and gives assurance that U is really talking to S. The assurance is independent of whether pk_s is chosen by S or an attacker, and occurs without any extra action or special attention by the user. Since you've proven that some kind of public-key trick is needed to do optimal password-verification, and you've gone to the expense of using one, why not go all the way? Prove to U that S knows spwd too. Here's one proposal: ------------------------------------------------------- Let S and U use g = PRG(spwd), which converts the password into a pseudo-random group generator. Replace spwd in the hash function f with a value derived from k', which is now a password-authenticated key. Finally, make S prove knowledge of k' to U. Enhanced protocol, slightly rearranged: S->U: r, g^x, pk_s U: k' = PRF_k(g^(x y)) t = f(PRF_k(k'); r, g^x, g^y, k, U, S) c = ENC_pk_s(k, t) U->S: g^y, c S->U: z = PRF_k(c) S: k' = PRF_k(g^(x y)) and finally S->U: PRF_k'(c) (I presume that added constraints prevent small-subgroup confinement, as needed in original method too.) ------------------------------------------------------- This kind of enhancement adds negligible computation, and it cleanly prevents attacks using an invalid pk_s, as shown above, or even someone breaking ENC_pk_s. The benefits of zero-knowledge tricks go far beyond just preventing eavesdropper brute-force attack and providing forward secrecy. They eliminate more reasons to blame the user for protocol failure. Best regards, David ---------------------------- David P. Jablon dpj@world.std.com From owner-ipsec Thu Aug 20 09:39:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA04826 for ipsec-outgoing; Thu, 20 Aug 1998 09:39:42 -0400 (EDT) Message-ID: <6297CD447F92D11199F5006097BA9D1E18632F@tbu1.hifn.com> From: Bob Monsour To: Tim Jenkins , Avram Shacham Cc: ipsec@tis.com, ippcp@external.cisco.com Subject: RE: IPCOMP and Tunnel Mode Date: Thu, 20 Aug 1998 07:00:56 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk Tim, see the data we published in http://www.ietf.org/internet-drafts/draft-ietf-ippcp-lzs-04.txt. Using the Calgary corpus, combining all of the files and treating the total as a series of packets, for 512 byte packets the average compression ratio was 1.58:1. All sorts of arguments can and will be made about what's the right set of data. People throw up web traffic as one example, others choose different data, but my view is that over time, in a vpn environment, you'll see more data that looks like LAN traffic as companies connect their distant LANs over the internet or other managed IP service. Also, the -06 draft was indeed advanced to Proposed Standard on 8/5. -Bob -----Original Message----- From: Tim Jenkins [mailto:tjenkins@TimeStep.com] Sent: Thursday, August 20, 1998 5:09 AM To: Avram Shacham Cc: ipsec@tis.com; ippcp@external.cisco.com Subject: RE: IPCOMP and Tunnel Mode The attempt to avoid possible fragmentation is a good one (your wording will is too strong), however: 1) No compression occurs for small packet sizes (below the threshold of the particular algorithm) 2) We're talking IPSec tunnel mode, which has to add another IP header, so the packet's going to grow anyway 3) The IPComp header is 4 bytes. Thus, the net increase is 24 bytes. If we assume that the smallest MTU in the network is 576 bytes, that means that packets that don't get compressed that are 552 bytes to 556 bytes in size will cause fragmentation under these conditions. What is the probability that there will be no compression of packets of that size? Does someone have any statistics on the probability of larger packets expanding during compression, thus not being compressed, so that this can be used as part of this discussion? On the issue of the flags: The bits are there. If they can be made to provide some useful purpose, they should. I note that this document (draft-ietf-ippcp-protocol-06.txt) was *not* one of those advanced to Proposed Standard. The document also states that the flag bits are reserved for future use. Perhaps this could be a future use. This discussion is based on the trade-offs between performance at the network level (possible fragmentation) and performance at the computational level (inconsistent implementation). Given equal probability of impacting both, I would design in favour of the network. However, in this case, I don't know that the probabilities favour the network. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 -----Original Message----- From: Avram Shacham [mailto:shacham@cisco.com] Sent: Wednesday, August 19, 1998 10:32 PM To: Tim Jenkins Cc: ipsec@tis.com; ippcp@external.cisco.com Subject: Re: IPCOMP and Tunnel Mode Tim, At 04:03 PM 8/19/98 -0400, Tim Jenkins wrote: I have some concerns about one of the requirements of the IPCOMP draft. It states that if no compression is actually done, no IPCOMP header should be added. While this may be fine in transport mode, it leads to the appearance of an IP-in-IP packet in tunnel mode. This concerns me, since it seems that the only way to be sure that the inbound IPCOMP SA should handle packet is to perform an SA lookup to see if it should have been compressed. (Issues of policy verification on inbound packets are intentionally left out of this discussion.) This leads to inconsistent processing of inbound SAs. As an alternative, I implemented using one of the flag bits to indicate that there was no compression and left the IPCOMP header in. This allowed a consistent lookup on inbound processing for an SA based on SPI (or the IPCOMP equivalent). I have also implemented the policy lookup method, and the full-time use of the IPCOMP header was much cleaner... Comments encouraged (although I doubt most of you need that...) :-) The draft (rfc?) (sorry Dan, I could not avoid following your style :), while defining the non-expansion policy, explains the reason for not adding the IPCOMP header in that scenario (see the marked lines): 2.2. Non-Expansion Policy If the total size of a compressed ULP payload and the IPComp header, as defined in section 3, is not smaller than the size of the original ULP payload, the IP datagram MUST be sent in the original non-compressed form. To clarify: If an IP datagram is sent non-compressed, no IPComp header is added to the datagram. This | policy ensures saving the decompression processing cycles and | avoiding incurring IP datagram fragmentation when the expanded | datagram is larger than MTU. In other words, when the size of a non-compressible packet is MTU, your suggestion to add the IPCOMP header will cause packet fragmentation. The wg debated having always an IPCOMP header, even when the packet in sent without compression. As such policy is actually equivalent to lowering the MTU by four octets, the wg decided to reject this proposal. In addition, your implementation does not comply with the requirement to set the flags field to zero: 3.3. IPComp Header Structure [snip] Flags 8-bit field. Reserved for future use. MUST be set to zero. MUST be ignored by the receiving node. As for the implementation issues that you raised, there were several interoperable stacks with IPComp in the bake-off last March, so working draft-compliant solutions do exist. Regards, avram From owner-ipsec Thu Aug 20 09:45:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA04884 for ipsec-outgoing; Thu, 20 Aug 1998 09:45:45 -0400 (EDT) Message-ID: <4EBBD2E2440BD21199E40000F8CB35CA3FE9@zuoexc1.zuo.dec.com> From: Jean Conti To: "'ipsec@tis.com'" Subject: Commercially available secure units Date: Thu, 20 Aug 1998 14:58:10 +0100 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 I am looking for commercially secure units to be installed between existing routers and LAN with the following main characteristics: * Should be integrated in a WAN (router based) of 50 sites * Interfaces: 2 (fast) Ethernet * Redundancy units should be possible * Encryption algorithm: triple-DES, IDEA.... * Key management without disturbing communication * Central Secure Management System I would very much appreciate receiving some pointers to possible manufacturers other than CYLINK Thanks in advance for your support Best regards Jean Conti DIGITAL - COMPAQ Services Headquarters Switzerland Network & Systems Integration Services Ueberlandstrasse 1 CH-8600 Duebendorf - Zuerich (Switzerland) Tel: +41 1 801 2355 Fax: +41 1 801 2640 Mobile: +41 79 236 1208 Email: jean.conti@digital.com From owner-ipsec Thu Aug 20 09:45:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA04883 for ipsec-outgoing; Thu, 20 Aug 1998 09:45:44 -0400 (EDT) Date: Thu, 20 Aug 1998 17:01:27 +0300 (IDT) From: Hugo Krawczyk To: David Jablon cc: shaih@watson.ibm.com, ipsec@tis.com Subject: Re: password-based authentication In-Reply-To: <3.0.5.32.19980820091759.007e0100@world.std.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk David, I think that a technical discussion of the nature you are initiating here does not belong to the ipsec list so I propose we move it off-line. One remark that I feel is necessary here is that when you write to such a broad (and busy!) audience you should be careful about the way you present these things. Anyone taking a glance at your message could easily conclude that the long list of problems you mention makes our scheme unusable or practically insecure. That's very much not true. All your points talk about a specific aspect of the proposal (orthogonal to the main cryptographic schemes), namely, the use of public passwords. You also fail to note that these possible attacks (under a particularly negligent implementation and user) require an active attack, that such attackers must work hard to succeed in finding a pair of public and private keys that hash to the given "slightly modified" public password, that even if all this effort by the active attacker succeeds it still needs to mount a dictionary attack, and so on and so forth. As for your proposal, I am willing to check it but not at the expense of adding noise to this busy mailing list. One preliminary comment. There are some important properties of our scheme that are at danger with your approach: provability and protection against server compromise. But let's take this off-line. I will be travelling in the next 10 days, I will be back to this after that (if you come to Crypto we may discuss this there) Hugo On Thu, 20 Aug 1998, David Jablon wrote: > Some comments to Hugo Krawczyk and Shai Halevi on their > recent paper follow, plus a suggested enhancement. > > At 06:39 PM 8/18/98 +0300, Hugo Krawczyk wrote: > >if you are among those that care about doing IKE > >using human passwords, you may want to take a look at > >the paper: > >"Public-key Cryptography and Password Protocols" > >by Halevi and Krawczyk. > >The paper will appear in the upcoming ACM Security conference. > > > > Hugo and Shai, > > Thanks for making your paper available to the IPSEC mailing list. > I was fascinated by your proof that public-key crypto is > necessary for optimal password verification, as many have > suspected. But in your focus on proving resistance to > eavesdropper attack, I think you've overlooked other > equally important characteristics of "zero-knowledge" > methods. > > You've cited several methods, such as EKE, which > can prove knowledge of a password without revealing it > to anyone. But, beyond stating that these methods rely > on heuristic assumptions, the paper doesn't analyze or > compare these techniques with alternatives, and the > protocol shown (proposed as suitable for IPSEC) does not > provide their full benefit. This seems inconsistent with > your struggle towards optimal security, and your inclusion > of other enhancements that rely on a "merely-heuristic" basis > for security. > > Fortunately, I think there are natural ways to apply EKE-style > techniques to strengthen your method. I'll show some > reasons for doing this, and one specific enhancement. > > Consider your "Mutual Authentication and DH Key Exchange" > method, using notation adapted from the paper: > ----------------------------------------------------------------- > spwd the shared password (perhaps small) > pk_s server's public key (perhaps uncertified) > f a challenge/response-style hash function > g a Diffie-Hellman generator > r,x random numbers chosen by server (S) > k,y random numbers chosen by user (U) > k' negotiated Diffie-Hellman key > > Protocol: > S->U: r, g^x, pk_s > U: t = f(spwd; r, g^x, g^y, k, U, S) > c = ENC_pk_s(k, t) > U->S: g^y, c > S->U: z = PRF_k(c) > U,S: k' = PRF_k(g^(x y)) > ----------------------------------------------------------------- > > The weakness here is in using an ordinary challenge/response > function for t: Whenever pk_s is not properly verified, > an attacker masquerading as S can perform an off-line > attack on t to determine the password. > This can happen in several ways: > > (1) U thoughtlessly hits "Enter" or "OK" when asked > if the key is valid. This one motivated your > suggestion to display a list of "public passwords" > (a.k.a. "fingerprints" for PGP fans) from which the > user would select the correct one. > > (2) U finds the displayed public password in the list > ("moss mont ton half vary pit"), glances at the card > from his pocket to confirm it, but doesn't notice > that it isn't a perfect match (The real key is > "moss mont ton rear rage fun"). > > (3) U notices that the keys don't match, but thinks > they're "close enough". (Hey, I said "U", not me! :-) > > (4) Instead of using a card, U blindly trusts a > simplistic verification system, where anyone with > $10 and an email address gets a "certified" key. > > (5) U's system makes key verification optional, > and U neglects to use it. > > (6) U confirms that the key corresponds to a named provider, > but doesn't notice that the name isn't quite right. > > One might argue that a well-designed system with well > informed and well behaved users won't permit such mistakes, > but we all know that kind of stuff happens. > > All these attacks are blocked when the password is > mutually verified using a zero-knowledge trick, > if U shares the password only with the intended party. > This automatically prevents others from cracking > the password, and gives assurance that U is really > talking to S. The assurance is independent of whether > pk_s is chosen by S or an attacker, and occurs without > any extra action or special attention by the user. > > Since you've proven that some kind of public-key > trick is needed to do optimal password-verification, and > you've gone to the expense of using one, why not go > all the way? Prove to U that S knows spwd too. > > Here's one proposal: > ------------------------------------------------------- > Let S and U use g = PRG(spwd), which converts > the password into a pseudo-random group generator. > Replace spwd in the hash function f with a value derived > from k', which is now a password-authenticated key. > Finally, make S prove knowledge of k' to U. > > Enhanced protocol, slightly rearranged: > S->U: r, g^x, pk_s > U: k' = PRF_k(g^(x y)) > t = f(PRF_k(k'); r, g^x, g^y, k, U, S) > c = ENC_pk_s(k, t) > U->S: g^y, c > S->U: z = PRF_k(c) > S: k' = PRF_k(g^(x y)) > and finally > S->U: PRF_k'(c) > > (I presume that added constraints prevent small-subgroup > confinement, as needed in original method too.) > ------------------------------------------------------- > > This kind of enhancement adds negligible computation, > and it cleanly prevents attacks using an invalid pk_s, > as shown above, or even someone breaking ENC_pk_s. > > The benefits of zero-knowledge tricks go far beyond just > preventing eavesdropper brute-force attack and providing > forward secrecy. They eliminate more reasons to blame > the user for protocol failure. > > Best regards, > > David > > ---------------------------- > David P. Jablon > dpj@world.std.com > > From owner-ipsec Thu Aug 20 14:27:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA06328 for ipsec-outgoing; Thu, 20 Aug 1998 14:22:55 -0400 (EDT) Message-ID: <35DC6DE4.D4B32F35@Certicom.com> Date: Thu, 20 Aug 1998 14:41:40 -0400 From: Yuri Poeluev Organization: Certicom Corp. X-Mailer: Mozilla 4.01 [en] (WinNT; U) MIME-Version: 1.0 To: ipsec@tis.com Subject: Authentication with ECDSA signatures X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, When you read the current IKE draft, you may notice that it only supports RSA-based and discrete log-based public-key signatures. But the IKE specification should allow other options that may be more efficient. Since we define EC groups (EC2N and ECP) for DH key exchange in the document, the logical consequence of the EC groups inclusion would be ECDSA definition as well. This is strange that it is not in the list of algorithms for authentication. Our implementations show that use of ECDSA can improve performance over DSA by as much as eight times. Most likely that one, who is going to use EC groups for DH and has software with EC implementation, will want to use ECDSA rather than RSA signature for authentication since it is inside of that software and provides greater performance. The current IKE draft proposes to use EC groups for DH key exchange, but for authentication we are proposed to use either RSA or DSA signatures only. So, I would like to propose that ECDSA support is added to IKE. Support for ECDSA certificates in PKIX is currently being proposed to assist this. Regards, Yuri Poeluev Certicom Corp. From owner-ipsec Thu Aug 20 23:22:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA07908 for ipsec-outgoing; Thu, 20 Aug 1998 23:21:03 -0400 (EDT) Message-Id: <3.0.5.32.19980820233715.007e6bb0@world.std.com> X-Sender: dpj@world.std.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 20 Aug 1998 23:37:15 -0400 To: Hugo Krawczyk From: David Jablon Subject: Re: password-based authentication Cc: shaih@watson.ibm.com, ipsec@tis.com In-Reply-To: References: <3.0.5.32.19980820091759.007e0100@world.std.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hugo, Regarding my comments on your paper "Public-key Crypto and Password Protocols", you wrote: > I think that a technical discussion of the nature you are > initiating here does not belong to the ipsec list so > I propose we move it off-line. [...] Ok. I'm sensitive to your concern that my comments were not mainstream IPSEC-list material, and could have been taken of context. I'd like to pursue the technical discussion, in a more appropriate open forum of your choice, after Crypto. In no way did I intend to minimize or downplay your work. I merely meant to show how a blend of specific pragmatic and theoretical improvements can extend and complement what you've done. My attacks were not specifically directed at your method, but rather at typical systems that use (or mis-use) similar methods. The criticism was indeed orthogonal to the main body of your paper. This is why I chose to refine and build upon, rather than replace, your key agreement scheme. But you've recast my concerns far too narrowly, and you seem to downplay what I believe are real, and solvable problems. My concern (beyond promoting my own stuff) is not merely with the "public password" technique, but with how to verify an uncertified public key. Or, alternately, how to safely and conveniently "get things started" without initially relying on a PKI. Your paper is one of a few to seriously touch on these issues, and I think the problem merits attention. I'm curious about the level of interest in password-based protocols for IPSEC. Email responses of any kind are welcome. -- David At 05:01 PM 8/20/98 +0300, Hugo Krawczyk wrote: >David, > >I think that a technical discussion of the nature you are >initiating here does not belong to the ipsec list so >I propose we move it off-line. > >One remark that I feel is necessary here is that >when you write to such a broad (and busy!) audience you should be >careful about the way you present these things. >Anyone taking a glance at your message could easily >conclude that the long list of problems you mention >makes our scheme unusable or practically insecure. > >That's very much not true. >All your points talk about a specific aspect of the proposal >(orthogonal to the main cryptographic schemes), namely, the >use of public passwords. > >You also fail to note that these possible attacks (under a particularly >negligent implementation and user) require an active attack, >that such attackers must work hard to succeed in finding a pair of public >and private keys that hash to the given "slightly modified" public >password, that even if all this effort by the active attacker succeeds >it still needs to mount a dictionary attack, and so on and so forth. > >As for your proposal, I am willing to check it >but not at the expense of adding noise to this busy mailing list. >One preliminary comment. There are some important properties of our scheme >that are at danger with your approach: provability and protection >against server compromise. But let's take this off-line. Yes. Addressing these points in detail might be tiresome for our readers. But, it's funny ... I too thought there were some important properties of my schemes that were in danger of being lost with your approach. >I will be travelling in the next 10 days, I will be back to this >after that (if you come to Crypto we may discuss this there) > >Hugo ---------------------------- David P. Jablon dpj@world.std.com From owner-ipsec Fri Aug 21 05:29:51 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA08588 for ipsec-outgoing; Fri, 21 Aug 1998 05:29:04 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01C6E6BB@wade.reo.dec.com> From: Stephen Waters To: ipsec@tis.com Subject: FW: IPSEC Interop Date: Fri, 21 Aug 1998 10:45:49 +0100 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 Does anyone else have an IPSEC test system reachable on the internet or via ISDN? Cheers, Steve. > ---------- > From: Daniel Harkins[SMTP:dharkins@cisco.com] > Sent: Thursday, August 20, 1998 4:12 PM > To: Stephen Waters > Subject: Re: IPSEC Interop > > Hi Steve, > > We don't support 40bit DES for IPSec. There are IPSec images for the > 2600 available. Ask whoever sold you the routers. Also if you have a > CCO account you can obtain them from www.cisco.com. > > But for interoperability you can just test against the router we have > available for just that purpose. The IP address is 192.31.7.219. If you > tell me your IP address I'll set up a pre-shared key ("mekmitasdigoat") > for you and you can test at your leisure. > > Let me know, > > Dan. > > On Thu, 20 Aug 1998 09:54:11 BST you wrote > > > > Hi Daniel, > > > > Just a shot in the dark, but we are looking to start interop testing > > IPSEC and would > > like to start with a CISCO device. We have recently received two > > 2600s, but we are > > having difficulty getting an IPSEC image to run on it - 40-bit is > > fine, we just want to get > > the IKE/ESP/AH interop tested for now. > > > > Is there any chance you could help with this - a Beta perhaps? > > Would you be > > interested in working through some interop tests with us? If needs > > be, we could > > even connect with ISDN transatlantic? I did some Triggered RIP > > testing with > > Xylan like that some years ago. > > > > We've exchanged mail before on IKE matters - so I thought I'd ask. > > Thanks, Steve. > > > > > From owner-ipsec Fri Aug 21 07:00:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA08786 for ipsec-outgoing; Fri, 21 Aug 1998 06:57:04 -0400 (EDT) Message-Id: <3.0.32.19980821131329.0091ad20@zap.celocom.se> X-Sender: valentin@zap.celocom.se X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 21 Aug 1998 13:13:29 +0100 To: ipsec@tis.com From: Valentin Oprean Subject: IPv6 Key Management Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi! I wonder if the Internet community has yet agreed on an IPv6 Key Management protocol and if yes which RFC is it? Thx! /.Valentin From owner-ipsec Fri Aug 21 08:35:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA09084 for ipsec-outgoing; Fri, 21 Aug 1998 08:34:12 -0400 (EDT) Date: Fri, 21 Aug 1998 07:10:27 -0500 From: Bezalel Gavish Subject: 7th International Conference on Telecommunication Systems - CFP X-Sender: gavishb@ctrvax.vanderbilt.edu To: (Recipient list suppressed) Message-id: MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Content-type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk C A L L for P A P E R S 7th International Conference on Telecommunication Systems Modeling and Analysis March 18-21, 1999 Nashville, Tennessee, USA Sponsored by: American Telecommunications Systems Management Association BellSouth Telecommunications, Inc. IFIP Working Group 7.3 "Computer system modeling and performance evaluation" INFORMS Technical Section on Telecommunications INFORMS College of Information Systems Vanderbilt Institute of Public Policy Studies The 7th International Conference on Telecommunication Systems - Modeling and Analysis will be held in Nashville on March 18-21, 1999. The conference will build on the tradition of the earlier conferences. The general idea is to limit the number of partici- pants, concentrate on a few topics, and to present new problems and problem areas, to encourage informal interaction and exchanges of ideas. The objective is to advance the state of the modeling and analysis in telecommunications by stimulating research activity on new and important problems. The conference will be divided into segments with each segment devoted to a specific topic. This will allow for little conflict between segments. All papers will be screened by the Program Committee to ensure the quality of presentations. A decentralized paper handling process will be used. Abstracts and papers should be submitted directly to a Program Committee member who will handle its review. It is expected that this will expedite the paper review process. Social and cultural activities will be included in the 1999 agenda. The conference will be held at two sites, Thursday and Friday meetings will take place at the Tennessee Economic Development Center at the BellSouth Tower in downtown Nashville. The Saturday and Sunday meeting will be held at the Club House Inn hotel (see description at the end of the message). Listed below are some of the potential segments: -- Configuration of ATM networks -- DSL based systems -- Internet and its Impact on Commerce -- Internet and Intranet -- Mobility and Nomadicity -- Pricing and economic analysis of Internet and E-commerce -- Topological Design and Network Configuration Problems -- Design and Analysis of Local Access Networks and Outside Plant Problems -- Low Earth Orbit Satellite Communication Systems -- Cellular Systems and PCS Modeling and Configuration -- Time Dependent Expansion of Telecommunication Systems -- Network Reliability, Availability and Survivability -- Network Design Problems in Gigabit and Terabit Networks -- LAN, WAN Global Network Interconnection -- Artificial Intelligence/Heuristics in Telecommunication Systems -- Quantitative Methods in Network Management -- Pricing and Economic Analysis of Telecommunications -- Impact of Telecommunications on Industrial Organization -- Performance Evaluation of Telecommunication Systems -- Distributed Computing and Distributed Data Bases -- Security and Privacy Issues in Telecommunications -- Virtual Reality, Multimedia and their Impact -- Standards The Program Committee is open to any ideas you might have regarding additional topics or format of the conference. The intention is, whenever possible, to limit the number of parallel sessions to three. The conference is scheduled over a weekend so as to reduce teaching conflicts for academic participants, and to enable participants to take advantage of weekend hotel and airfare rates and of the many events that take place in the downtown area. Members of the Program Committee include: Prof. Bezalel Gavish (Chairman) Owen Graduate School of Management Vanderbilt University Tel: 615-322-3659 401 21st Avenue South FAX: 615-343-7177 Nashville, TN 37203 E-mail: gavishb@ctrvax.vanderbilt.edu Prof. Abdullah Al-Dhelaan College of Computer & Information Sciences King Saud University, Riyadh, Saudi Arabia Phone : (0966)-1-467-7777 Fax : (0966)-1-468-1221 E-mail : dhelaan@usa.net Prof. Kemal Altinkemer Krannert Graduate School of Management Purdue University 1310 Krannert Building West Lafayette, IN 47907-1310 Phone : 765-494-9009 Fax : 765-494-1526 E-mail : kemal@mgmt.purdue.edu Prof. Ran Giladi Department of Communication Systems Engineering Faculty of Engineering Sciences Ben Gurion University of the Negev POB 653 Beer Sheva, 84105 Israel Phone : (972)-7-6472591 FAX : (972)-7-6472883 E-Mail : Ran@bgumail.bgu.ac.il Prof. Luis Gouveia D.E.I.O. - C.I.O. Faculdade de Ciencias da Universidade de Lisboa Edificio C2 -Campo Grande Cidade Universitaria 1700 Lisboa Portugal Phone : +351-1-7573141, ext 1584 E-mail : lgouveia@fc.ul.pt Dr. Sidney L. Hantler Manager, Stochastic Analysis Systems and Software Department IBM TJ Watson Research Center Yorktown Heights, NY 10598 Phone : 914-784-7218 E-Mail : hantler@watson.ibm.com Prof. Richard Harris Department of Communication and Electronic Engineering Royal Melbourne Institute of Technology GPO Box 2476V Mlebourne, Victoria Australia, 3001 Phone : 61 3 9925 2457 (RMIT) Fax : 61 3 9660 1060 (RMIT) E-Mail : richard@catt.rmit.edu.au Prof. Joakim Kalvenes School of Management The University of Texas at Dallas P.O. Box 830688, J044 Richardson, TX 75083-0688 Phone : 972-883-2152 Fax : 972-883-2089 E-mail : kalvenes@utdallas.edu Dr. Johan M. Karlsson Department of Communication Systems Lund Institute of Technology P.O. Box 118 S-221 00 Lund Sweden E-Mail : johan@tts.lth.se Dr. Konosuke Kawashima Traffic Research Center NTT Advanced Technology Corp. 2-4-15 Naka-cho, Musashino-shi Tokyo, 180-0006 JAPAN Phone : +81 422 370536 Fax : +81 422 604806 E-mail : shima@mitaka.ntt-at.co.jp Prof. Hans Kruse McClure School of Communication Systems Management Ohio University 9 S. College Street Athens, OH 45701 Phone : 614-593-4891 Fax : 614-593-4889 E-mail : hkruse1@ohiou.edu Prof. Armin R. Mikler Department of Computer Sciences University of North Texas P.O. Box 311366 Denton, TX 76203-1366 Phone : 940-565-4279 Fax : 940-565-2799 E-mail : mikler@cs.unt.edu Prof. June S. Park Department of Management Sciences The University of Iowa 108 Pappajohn Business Administration Bldg. Iowa City, IA 52242-1000 USA Phone : 319-335-2087 Fax : 319-335-1956 E-Mail : june-park@uiowa.edu Prof. Guy Pujolle Laboratoire PRiSM Universite de Versailles - Saint Quentin 45 avenue des Etats-Unis 78 035 Versailles Cedex FRANCE Phone : +33 (1) 39 25 40 61 Fax : +33 (1) 39 25 40 57 E-Mail : guy.pujolle@prism.uvsq.fr Dr. Ernesto Santibanez-Gonzalez Escuela de Ingenieria Industrial Universidad Catolica, Valparaiso Av. Brasil 2147 Valparaiso Chile Phone : 56 32 257331 Fax : 56 2 214823 E-Mail : esantiba@aix1.ucv.cl Prof. Andrew P. Snow Department of Computer Information Systems Georgia State University P.O. Box 4015 Atlanta, GA 30302-4015 Phone : 404-651-0879 E-mail : asnow@gsu.edu Prof. Yutaka Takahashi Nara Institute of Science and Technology Takayama-cho 8916-5, Ikoma-shi Nara, 630-01 JAPAN Phone : 81 74 372 5350 Fax : 81 74 372 5359 E-Mail : ytanaka@mn.waseda.ac.jp Prof. Lars C. Wolf Industrial Process & Sys. Comm. Department of Electr. Eng. & Information Technology Darmstadt University of Technology Merckstr. 25 64283 Darmstadt Germany Tel. : +49-6151-16-6155 (Fax -6152) E-mail : Lars.Wolf@kom.tu-darmstadt.de Prof. Stefan Voss University of Braunschweig Abt-Jerusalem Strasse 7 D-38106 Braunschweig Germany Phone : 49 531 391-3210 E-Mail : Stefan.Voss@tu-bs.de Due to the limit on the number of participants, early conference and hotel registration is recommended. The ClubHouse Inn & Conference Center is the official hotel of the conference. To ensure your participation, please use the following steps: 1. Send to a Program Committee member by October 1, 1998, a paper (preferable), or titles and extended abstracts for potential presentations to be considered for the conference. Sending more than one extended abstract is encouraged, enabling the Program Committee to have a wider choice in terms of assigning talks to segments. Use E-mail to expedite the submission of titles and abstracts and papers. 2. Use the forms at the end of this message to preregister for the conference and the hotel. Let us also know if you would like to have a formal duty during the conference such as: Session Chair, or Discussant. 3. You will be notified by December 15, 1998, which abstract(s)/ paper(s) have been selected for the conference. Detailed instructions on how to prepare camera ready copies will be sent to authors of accepted presentations. February 10, 1999, is the deadline for sending a final version of the paper. Participants will receive copies of the collection of papers to be presented. 4. All papers submitted to the conference will be considered for publication in the "Telecommunication Systems" Journal. If you do not wish for your paper to be submitted for publication consideration in the "Telecommunication Systems" Journal, please specify it in the cover letter of your submission. The Program Committee looks forward to receiving your feedback/ideas. Feel free to volunteer any help you can offer. If you have suggestions for Segment Leaders (i.e., individuals who will have a longer time to give an overview/state of the art talk on their segment subject) please E-mail them to Prof Gavish. Also, if there are individuals whose participation you view as important, please send their names and E-mail addresses to the Program Committee Chairman, or forward to them a copy of this message. I look forward to a very successful conference. Sincerely yours, Bezalel Gavish ---------------------------------------------------------------------------- -------------- Bezalel Gavish Owen Graduate School of Management Vanderbilt University Nashville, TN 37220 USA Tel: Office (615) 322-3659 FAX (615) 343-7177 Home (615) 370-0813 Email: Gavishb@ctral1.vanderbilt.edu From owner-ipsec Fri Aug 21 08:58:31 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA09147 for ipsec-outgoing; Fri, 21 Aug 1998 08:58:16 -0400 (EDT) Date: Fri, 21 Aug 1998 09:14:31 -0400 Message-Id: <199808211314.JAA16760@ghostwheel.ncsl.nist.gov> Mime-Version: 1.0 X-Newsreader: knews 1.0b.0 References: <250F9C8DEB9ED011A14D08002BE4F64C01C6E6BB@wade.reo.dec.com> In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C01C6E6BB@wade.reo.dec.com> From: Rob.Glenn@nist.gov (Robert Glenn) Subject: Re: FW: IPSEC Interop X-Original-Newsgroups: ietf.ipsec To: Stephen Waters Cc: ipsec-wit-dev@antd.nist.gov, ipsec@tis.com Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, NIST has a "test anywhere, anytime" WWW-based IPsec & IKE test system (IPsec-WIT). See http://ipsec-wit.antd.nist.gov for more information. Best Regards, Rob G. rob.glenn@nist.gov In article <250F9C8DEB9ED011A14D08002BE4F64C01C6E6BB@wade.reo.dec.com>, Stephen Waters writes: > > Does anyone else have an IPSEC test system reachable on > the internet or via ISDN? > > Cheers, Steve. > > >> ---------- >> From: Daniel Harkins[SMTP:dharkins@cisco.com] >> Sent: Thursday, August 20, 1998 4:12 PM >> To: Stephen Waters >> Subject: Re: IPSEC Interop >> >> Hi Steve, >> >> We don't support 40bit DES for IPSec. There are IPSec images for the >> 2600 available. Ask whoever sold you the routers. Also if you have a >> CCO account you can obtain them from www.cisco.com. >> >> But for interoperability you can just test against the router we have >> available for just that purpose. The IP address is 192.31.7.219. If you >> tell me your IP address I'll set up a pre-shared key ("mekmitasdigoat") >> for you and you can test at your leisure. >> >> Let me know, >> >> Dan. >> >> On Thu, 20 Aug 1998 09:54:11 BST you wrote >> > >> > Hi Daniel, >> > >> > Just a shot in the dark, but we are looking to start interop testing >> > IPSEC and would >> > like to start with a CISCO device. We have recently received two >> > 2600s, but we are >> > having difficulty getting an IPSEC image to run on it - 40-bit is >> > fine, we just want to get >> > the IKE/ESP/AH interop tested for now. >> > >> > Is there any chance you could help with this - a Beta perhaps? >> > Would you be >> > interested in working through some interop tests with us? If needs >> > be, we could >> > even connect with ISDN transatlantic? I did some Triggered RIP >> > testing with >> > Xylan like that some years ago. >> > >> > We've exchanged mail before on IKE matters - so I thought I'd ask. >> > Thanks, Steve. >> > >> > >> -- rob.glenn@nist.gov From owner-ipsec Fri Aug 21 10:33:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA09756 for ipsec-outgoing; Fri, 21 Aug 1998 10:31:39 -0400 (EDT) Message-Id: <199808211448.HAA19767@chip.cisco.com> To: Valentin Oprean cc: ipsec@tis.com Subject: Re: IPv6 Key Management In-reply-to: Your message of "Fri, 21 Aug 1998 13:13:29 BST." <3.0.32.19980821131329.0091ad20@zap.celocom.se> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19765.903710899.1@cisco.com> Date: Fri, 21 Aug 1998 07:48:19 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk It's IKE. I wish I knew the RFC number :-( Any day now, I guess we should all know. On Fri, 21 Aug 1998 13:13:29 BST you wrote > Hi! > > I wonder if the Internet community has yet agreed on an IPv6 Key Management > protocol and if yes which RFC is it? > > Thx! > /.Valentin From owner-ipsec Fri Aug 21 10:42:52 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA09791 for ipsec-outgoing; Fri, 21 Aug 1998 10:42:43 -0400 (EDT) Date: Fri, 21 Aug 1998 10:58:39 -0400 Message-Id: <199808211458.KAA18166@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: shacham@cisco.com, ipsec@tis.com, ippcp@external.cisco.com Subject: RE: IPCOMP and Tunnel Mode References: <319A1C5F94C8D11192DE00805FBBADDF32A41B@exchange.timestep.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk Tim, I might conceivably agree that your proposal is better than what's in the spec if it had come in a year ago. But given the state of the spec, and the fact that numerous people have already implemented what's specified with no trouble, I see no sense at all in pursuing what, at best, might be a very minor optimization for some implementations and a minor pessimization for others. paul From owner-ipsec Fri Aug 21 11:25:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA09891 for ipsec-outgoing; Fri, 21 Aug 1998 11:24:47 -0400 (EDT) Message-Id: <3.0.5.32.19980821114210.009c0100@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 21 Aug 1998 11:42:10 -0400 To: ipsec@tis.com From: Robert Moskowitz Subject: IBM IPsec workshop Oct 26 - 30 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk OK. Here is the offical announcement and we can talk to this more on tuesday. The California ISDN Users' Group (CIUG) and ICSA, Inc. invites you to participate in the VPN Interoperability Workshop hosted by IBM AS/400 Endicott at the Holiday Inn Binghamton Arena in Binghamton, New York. CIUG is supplying most of the networking and administrative support, IBM the location and overall coordination, and ICSA the IPsec and IKE testing. Since some feel that L2TP development is common to IPsec for some vendors (plus L2TP secured with IPsec), L2TP testing will be supported by CIUG and IBM, and is included in the overall test plan. IBM is not getting the testing room (which will have 90 tables, so we should have room for lots of testers this time) until monday 1pm. So they are not anticipating room availablity until tuesday morning, but testing will be available until friday afternoon and all nights. This is not a large metropolitan area with lots of eating facilities. IBM has arranged food and get together time to keep you all in the hotel, as such there is a $300/person charge. This covers food and the cost for CUIG to bring all of their equipment (which includes analog and ISDN testing facilites besides the standard ethernet). (And yes, I expect to be paying the $300 even though I cannot eat any of the food). I am working on getting the full workshop document up on the ICSA web site today. With the mail problems we are having (final switchover from NCSA.COM to ICSA.NET), resources in the home office are limited... Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Fri Aug 21 11:28:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA09904 for ipsec-outgoing; Fri, 21 Aug 1998 11:28:47 -0400 (EDT) Message-Id: <3.0.5.32.19980821114522.009bfeb0@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) X-Priority: 1 (Highest) Date: Fri, 21 Aug 1998 11:45:22 -0400 To: ipsec@tis.com From: Robert Moskowitz Subject: Attempt at an agenda Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I have worked a lot on an agenda with a number of people. Here is how it stands. I will accept any comments you may have... We have one hour. The meeting size is too large for effective progress at the meeting, so we are only highlighting thigs at work. Then I am going to wrok with task teams during the week to actually get some real progress on a number of issues. FInally on thrusday evening, I am suppose to have the Missouri room for food and further discussions and drafting. So that we will hit the list the following week with real progress and direction. AGENDA 5 min Workgroup status 5 min Workshop announcement 10 min Charter revision 5 min Discovered problems with Ipsec/IKE based on current implementation experience 10 min Lifetime discussion 10 min ICMP messages, standardized error codes, and MIBs Call for a work team 15 min Policy/tunnel endpoint discovery Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Fri Aug 21 13:59:16 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA10672 for ipsec-outgoing; Fri, 21 Aug 1998 13:57:46 -0400 (EDT) Message-ID: From: Rudolph Balaz To: ipsec@tis.com Subject: RE: IPSec interop workshop Aug 31st - Sept 3 Date: Fri, 21 Aug 1998 11:08:29 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipsec@ex.tis.com Precedence: bulk For those vendors participating in this event at Microsoft, I have a few request below that would help me streamline my part of this workshop. Please reply to me since I'm not on this list. I will be providing a Microsoft Certificate Server for interop testing at this workshop. I'd appreciate if the participants could provide me with the following before they arrive: 1) Provide a sample certificate request. (PKCS#10). Please specify the encoding, Binary, Base64, Der. 2) Provide a sample certificate. 3) Do you have any special requirements for a certificate chain? PKCS#7, max number of CAs, etc. 4) How do you intend to request a certificate? offline via floppy, Http, other? A brief explanation would allow me to prepare more effectively. 5) How do you install new root certificates? again if there is anything special that you need? If there is anything else please email me. Thank you. Rudolph Balaz, 425-936-3772, Rudolphb@microsoft.com Program Manager, Microsoft Certificate Server Windows NT Distributed Security Microsoft Corporation From owner-ipsec Fri Aug 21 16:20:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA11028 for ipsec-outgoing; Fri, 21 Aug 1998 16:16:49 -0400 (EDT) Message-ID: <35DDD9AF.D63758CC@shiva.com> Date: Fri, 21 Aug 1998 16:33:51 -0400 From: Jesse Walker Organization: Shiva Corporation X-Mailer: Mozilla 4.04 [en] (X11; U; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: ipsec@tis.com Subject: [Fwd: IPSec error monitoring] Content-Type: multipart/mixed; boundary="------------3221697E5DD9CB2D5CB009DF" Sender: owner-ipsec@ex.tis.com Precedence: bulk This is a multi-part message in MIME format. --------------3221697E5DD9CB2D5CB009DF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------3221697E5DD9CB2D5CB009DF Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <35DDC5DA.893A434@shiva.com> Date: Fri, 21 Aug 1998 15:09:14 -0400 From: Jesse Walker Organization: Shiva Corporation X-Mailer: Mozilla 4.04 [en] (X11; U; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: ipsec@ns.ncsa.com Subject: IPSec error monitoring Content-Type: multipart/mixed; boundary="------------E00C1CB35929A8A780E25B7B" This is a multi-part message in MIME format. --------------E00C1CB35929A8A780E25B7B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The attached note discusses a topic that seems relevant to IPSecond. I'd like to know whether people thinks this is worth persuing further. Jesse Walker Shiva Corporation 28 Crosby Drive Bedford, MA 01730-1437 voice: 781-687-1719 fax: 781-687-1828 internet: jwalker@shiva.com --------------E00C1CB35929A8A780E25B7B Content-Type: text/plain; charset=us-ascii; name="ipsec-pqm.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ipsec-pqm.txt" 1. Motivation IPSec provides no mechanism to expeditiously release resources when the media carrying its security associations fails, or when one end of a set of security association abruptly drops out of the dialog without notifying the peer. This problem is particularly common when one end of a security association is a remote access client, under the control of an unsophisticated user, who will as often as not switch off a laptop computer rather than follow "proper procedure" to diconnect. The discussion from a few months ago regarding what to do when one endpoint of a set of security associations crashes and then reboots provides another illustration of problems encountered due to this lack. Another basic problem is that, to date, IPSec implementations have provided rather weak diagnostics, and the security features of the protocol suite magnify the difficulty in applying traditional network trouble-shooting mechanisms. When IPSec security associations experience problems, it is often very difficult to isolate and correct the root cause. IPSec diagnostics is still something of a black art. To address problems like these, it might be useful to try to measure the quality of a path between two security association endpoints. One way we might implement these measurements is to mimic aspects of the PPP LQM protocol (RFC 1989). "LQM" packets could be sent over the "link" between the SA endpoints to establish the loss characteristics of the path between them. The reported statistics (or their lack) could then be used for a number of purposes, such as providing a basis for some classes of quality of service decisions (when to shift some traffic from one tunnel to another), diagnostics (traffic works in only one direction), security alerts (the number of errors on one SA suddenly skyrockets), or keepalives (we failed to receive too many consecutive messages). For want of better terminology, we will call the set of security associations between two endpoints a "path". Given this terminology, we will call the protocol the Path Quality Monitoring protocol, or PQM. The point of using "path" rather than the ancestoral term "link" is to emphasize that we have to address the differences from the PPP the environment. In the IPSec environment generally packets can be reordered, and the bandwidth available can be much more dynamic, as routers inside the cloud between the path endpoints shift load and topology. However, like LQM, to effect flexible future policies, the PQM protocol should measure data loss in units of packets and octets. It should measure each security association separately, and communicate all measurements to both IKE peers, so that each end can implement its own policies governing inadequate quality. Each PQM implementation should maintain a set of counters of packets and kilobytes transmitted and successfully received, and convey this information to its peer in a PQM message at regular intervals. By comparing the values reported in successive PQM messages, a receiver should be able to form a fairly accurate picture of a path's quality. The intent of the counters is to provide an indication of the dynamics of the information passing over the path between the PQM peers, not to measure the total bandwidth used. One possible PQM design would encapsulate PQM messages directly under IPSec security associations. Indeed, it seems almost self evident that monitoring packets should be exposed to exactly the same environment as the "real" packets. This seems to imply that monitoring packets should be sent via the same security association as the "real" ones. At least three apparent problems exist with this approach, however. First, the messages would not in general comply with the SPD for the security associations, because they must circulate between the security association end-points. When a security gateway is involved, datagrams addressed to or from the IP address of one of the path endpoints (the security gateway) usually will not be authorized to traverse any of the security associations used to transport "real" traffic. This implies that PQM may often require its own security association. We could construct a new pair of IPSec security associations just to accomodate this function. However, it is worth noting that an IKE security association typically already exists between the path endpoints. It might be better to exploit this one rather than negotiating yet one more. Second, providing the "same" environment for PQM as for the operational packets is more problematic in the general IPSec environment, because of the lack of a physical link. It is in principle impossible to guarantee the same environment for even two successive packets sent via the same security association, as they may be routed differently and hence ultimately subjected to different filtering or fragmentation. This suggests that the inherited wisdom of using the "link" itself as the transport vehicle for a quality monitoring protocol is of less importance here than in the PPP case. A final problem is that multiple pairs of security associations can exist between two IKE peers instead of a single half-duplex pair. A PQM protocol based directly on the IPSec security associations would entail either running PQM messages through each of the pairs, thereby wasting bandwidth, or relying on the selection of an arbitrary security association to convey the information, or depending upon configuration, etc. Having to make any choice at all again suggests it is not the right design choice. If you buy this reasoning, something like PQM seems like a good addition to IPSec, and an IKE extension leaps out as a reasonable mechanism for supporting PQM. The remainder of this note is a speculative first attempt to define such an extension. It is not intended as the last word on the subject and without a doubt can be improved significantly by others. Its single greatest merit is concreteness, affording us an opportunity to pick over its bones until an acceptable protocol emerges from it. 2. Protocol data units The PQM protocol will use IKE as its transport vehicle. PQM messages will constitute a new Informational Exchange type, which means they are half-duplex. To this end, we introduce a new IKE attribute, used to negotiate PQM as an IKE SA characteristic, and three new payloads, to convey the necessary statistics. This section describes these new facilities. 2.1. PQM attribute This is a new attribute of an IKE SA, so can be proposed during negotiations for the IKE SA. It offers a maximum PQM reporting period in seconds. When accepted, this is the base reporting period for PQM over the path. When not accepted or not present, PQM is not used. The PQM attribute is identified by IKE attribute id TBD. Its value is a nonnegative number 16-bit number, with a default value of TBD seconds. The PQM atrribute value MUST be configurable. The value 0 is not meaningful in the protocol. 2.2. PQM Payload The PQM Payload is used to convey PQM statistics to the IKE security association peer. Figure 1 shows the format of the PQM Payload. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload | RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number SPIs | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reporting Period | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PQMs Sent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PQMs Received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer PQMs Sent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer PQMs Received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. PQM Payload The PQM Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. This field MUST NOT contain the values for the Send Statistics or Receive Statistics Payloads, as they are considered part of the PQM information reported by the payload. o RESERVED (1 octet) - Unused, set to 0 o Payload Length (2 octets) - The length of the entire PQM payload, including Send Statistics and Receive Statistics payloads, in octets. o Number SPIs (1 octet) - The combined number of Send Statistics and Receive Statistics payloads conveyed by this PQM payload. This MUST be an even number, as a PQM payload MUST always include reports for each of the paired security associations negotiated by a single Quick Mode proposal. o RESERVED (3 octets) - Unused, set to 0 o Sequence Number (4 octets) - the number of PQM messages sent thus far. This is a monotonically increasing number counting from zero. This allows the receiver to detect out-of-order PQM messages. o Reporting Period (4 octets) - the maximum number of seconds before the local system expects to generate another PQM message. The local system MAY generate another PQM message sooner than this, but it MUST NOT generate the next PQM message later than what the Reporting Period field advertises. o PQMs Sent (4 octets) - The number of PQM payloads the local system has sent so far over this path. Since the path consists of the current IKE SA as well as all the IPSec SAs between the path endpoints, this definition is general enough to accomodate roll- over, when one SA replaces another. o PQMs Received (4 octets) - The number of PQM payloads the local system has received over this path. o Peer PQMs Sent (4 octets) - The number of PQM payloads the path peer has reported to have sent thus far. This information allows the local implementation to monitor the efficacy of its own PQMs. o Peer PQMs Received (4 octets) - The number of PQM payloads the path peer has reported to have received thus far thus far. This information also allows the local implementation to determine the efficacy of its own PQMs. The payload type for the PQM payload is TBD. 2.3. Send Statistics Payload The Send Statistics Payload is used to convey PQM statistics to the path peer. These statistics indicate the level of traffic generated by the local system to the peer over a particular security association, as well as pertinent performance information the peer has reported for that security association. This information allows the peer to gauge the loss characteristics of the security association. Figure 2 shows the format of the Send Statistics payload: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload | RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packets Sent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kilobytes Sent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Last Peer Received Packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Last Peer Received Kilobytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Last Peer Packet Errors | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Last Peer Packet Drops | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. Send Statistics Payload The Send Statistics Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. This MUST only be 0, indicating the end of the PQM payload, TBD, indicating the next Send Statistics Payload, or TBD, indicating the next Receive Statistics payload. o RESERVED (1 octet) - Unused, set to 0 o Payload Length (2 octets) - The length of the Send Statistics payload in octets. This always has the value 32. o SPI (4 octets) - The IPSec SPI of the security association used to transmit packets to the peer. The IP address of the PQM receiver and the SPI uniquely identify the security association. All the counters in the payload refer to this security association. Remark: Obviously the local implementation knows the IP address of the peer, since it negotiated a security association with it. Therefore we don't include it in the Send Statistics. This usage means that several paths can exist between multi-homed hosts, and that we will monitor each separately. This is an intended consequence of the usage. o Packets Sent (4 octets) - The number of packets the local system has transmitted over the indicated security association. o Kilobytes Sent (4 octets) - The number of kilobytes of data the local system has transmitted over the the indicated security association. This value is computed prior to encapsulation. Issue: we are trying to avoid 64 bit counters. Clearly we have not accomplished this, because most media deployed today use packets of at least 1.5 K bytes and the counters allow up to 2^32 packets. Does it really matter if the counters wrap and so give only relative measurements? o Last Peer Received Packets (4 octets) - The last value the peer has reported for the number of received packets for the indiciated security association. o Last Peer Received Kilobytes (4 octets) - The last value the peer has reported for the number of kilobytes successfully decapsulated for the indicated security association. o Last Peer Packet Errors (4 octets) - The last value the peer has reported for the number of packets for the indicated security association discarded because of errors. Errors include such things as replay, out-of-window detection, digest error, decryption error, padding error, and the like. o Last Peer Packet Drops (4 octets) - The last value the peer reported for the number of packets for the indicated security association dropped for reasons other than errors (e.g., lack of resources). The payload type for the Send Statistics payload is TBD. 2.4. Receive Statistics Payload The Receive Statistics Payload is used to convey PQM statistics to the IKE security association peer. These statistics indicate the level of traffic received by the local system from the peer over a particular security association, as well as error statistics pertinent to the operation of that security association. This information allows the peer to gauge the loss characteristics of the security association. Figure 3 shows the format of a Receive Statistics Payload: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload | RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packets Received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kilobytes Received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Errors | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Drops | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. Receive Statistics Payload The Receive Statistics Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. This MUST only be 0, indicating the end of the PQM payload, TBD, indicating the next Send Statistics Payload, or TBD, indicating the next Receive Statistics payload. o RESERVED (1 octet) - Unused, set to 0 o Payload Length (2 octets) - The length of the Receive Statistics payload in octets. This always has the value 24. o SPI (4 octets) - The IPSec SPI of the security association used to demultiplex packets received from the peer. The IP address of the sender and this SPI uniquely identify the security association. All the counters in the payload refer to this security association. Remark: See the corresponding item in section 2.3. o Received Packets (4 octets) - The number of packets successfully decapsulated for the indiciated security association. o Received Kilobytes (4 octets) - The number of kilobytes successfully decapsulated for the indicated security association. Issue: see the corresponding item in section 2.3. o Packet Errors (4 octets) - The number of packets for the indicated security association discarded because of errors. Errors include such things as replay, out-of-window detection, digest error, decryption error, padding error, and the like. o Packet Drops (4 octets) - The number of packets for the indicated security association dropped for reasons other than errors (e.g., lack of resources). The payload type for the Receive Statistics payload is TBD. 3. Protocol PQM has two components. First it must be negotiated. Then the protocol must be implemented. 3.1. PQM negotiations If an implementation desires to use PQM, it MUST negotiate this during the negotiation of the IKE SA. No support for PQM exists for manually configured IPSec security associations. Use of PQM MUST be optional, as its operation may be counter productive in many environments, e.g., dial-on-demand. The IKE accomplishes the negotation by including the PQM attribute with a value in its IKE SA proposal. The peer IKE implementation MAY accept such a proposal in the usual way. A PQM attribute value exceeding the life of the IKE SA may be acceptable, as the value only gives the maximum delay between subsequent reports. In the case where a proposal conveying the PQM attribute is accepted, both peer IKE implementations agree to a. keep an IKE security association established as long as any IPSec security associations negotiated by the IKE security association remain. This means they will negotiate to extend the IKE session before expiry as long an IPSec session negotiated by the IKE session exists. b. run the PQM protocol with the peer over IKE, with subsequent PQM packets being sent at least as often as the negotated reporting period. If an implementation wishes to stop using PQM, it can renegotiate the IKE session and omit PQM from its proposal. 3.2. Implementation Each IPSec security association will be associated with the IKE session that negotiated it, and an IKE session with a path. To perform PQM, an implementation MUST remember these associations. A PQM message is a new species of IKE Informational exchange. It consists of a. An IKE header; b. a Hash Payload, to guarantee liveness and to provide data integrity of the message. The Hash payload must immediately follow the IKE header; c. a PQM Payload (PQM), which includes d. one Send and Receive Statistics payload representing each pair of IPSec security associations associated with the IKE session. Each of thses pairs are considered part of the PQM payload. Note that if the implementation has not negotiated any IPSec security associations, the PQM Payload will include no Send and Receive Payloads. Being an Informational Exchange, the Hash Payload is the output of the IKE SA pseudo-random function, using the IKE SA SKEYID_a as the key, and a unique message id (M-ID) concatenated to the entire PQM payload: HASH = prf(SKEYID_a, M-ID | PQM) and the Hash, PQM Payload, and Send and Receive Statistics Payloads are CBC encrypted under SKEYID_e for the IKE session. Since PQM is an Informational Exchange, each such message is considered as a new exchange rather than a continuation of an old, so the CBC encryption mode initialization vector is computed from scratch each time by using the negotiated pseudorandom function, the hash of the last phase 1 CBC output block, and te randomly selected message id M-ID which is unique to this message. Thus, in the notation from the IKE specification, the PQM message may be denoted by something like Hdr* HASH PQM The PQM, Send, and Receive Statistics payloads MUST NOT be sent during IKE phase 1; they may only be sent during IKE phase 2, after the IKE SA has been established. If PQM has been negotiated, an IKE implementation SHOULD begin sending these immediately after entering phase 2; it MAY defer the first message until after completing quick mode negotiations. An IKE implementation transmits at least one PQM message during each Reporting Period; it MAY transmit a PQM message before the reporting period lapses, however. The PQM peers transmit the PQM messages independently. However, like its PPP LQM counterpart, an IKE implementation also transmits a PQM message if it receives two consecutive PQM messages from its peer with the same Peer Receive parameter values. This can indicate that one of its own prior PQM message failed to be delivered. This document does not specify the uses to which the PQM data may be applied, as this is an implementation matter. --------------E00C1CB35929A8A780E25B7B-- --------------3221697E5DD9CB2D5CB009DF-- From owner-ipsec Sat Aug 22 12:22:26 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA12433 for ipsec-outgoing; Sat, 22 Aug 1998 12:18:56 -0400 (EDT) From: Armando Fratezi To: Subject: VPN Interoperability Workshop Oct 26 - 30 Message-ID: <5010400026154616000002L062*@MHS> Date: Sat, 22 Aug 1998 12:41:08 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Return your application via email and reserve your hotel rooms before September 25, 1998! To Networking Product Developers: The California ISDN Users' Group (CIUG) invites you to participate in the VPN Interoperability Workshop featuring IPSEC, IKE, and L2TP hosted by IBM AS/400 Endicott at the Holiday Inn Binghamton Arena in Binghamton, New York. The VPN Workshop combines the eighth CIUG PPP Interoperability Workshop and the sixth IPSEC Interoperability Workshop. The Workshop will be open to companies with products that implement: IP Security (IPSEC) Internet Key Exchange (IKE) PPP Layer 2 Tunneling Protocol (PPP L2TP) The Workshop will provide an opportunity to test the interoperability of your products with products from all of the other companies attending. The participating companies are asked to bring products that are released, at beta or near beta level for IPSEC, IKE, and L2TP. Participants are engineering staff intimately familiar with the software and hardware that implements the capabilities being tested and are expected to have a thorough understanding of the protocols. This Workshop will be open to only the participants. This is not a spectator event; it is not open to observers. Some participants will be working with unreleased products and the other attendees are expected to respect their privacy. SPONSORSHIP: IBM AS/400 Endicott is the host for the VPN Interoperability Workshop. Worldcom Advanced Networks will provide the Backbone Test Ethernet and access to the real Internet. In addition to the general test plan, ICSA, Inc. will work with IPSEC/IKE testing that is based on the ICSA IPSec 1.1 Certification Model. PRESS RELEASE: The CIUG and IBM AS/400 Endicott plan to make a press release announcing the workshop and listing the participants. There will be no mention of any specific results of the testing in this release. Please indicate in the application if you want your company's name included in this release as a participant. If you include your public relations person in the application, that contact will be given the opportunity to review the release in advance. SCHEDULE: Monday, October 26 8:00 PM to 9:30 PM Reception Tuesday, October 27 7:00 AM to 8:30 AM Buffet Breakfast 8:00 AM Setup 12:00 Noon Buffet Lunch 1:00 PM to 9:00 PM Testing Wednesday, October 28 7:00 AM to 8:30 AM Buffet Breakfast 8:00 AM to 9:00 PM Testing 12:00 Noon Buffet Lunch Thursday, October 29 7:00 AM to 8:30 AM Buffet Breakfast 8:00 AM to 9:00 PM Testing 12:00 Noon Buffet Lunch 3:00 PM to 5:00 PM Group Meeting 6:00 PM Get Together and Evening Refreshments Friday, October 30 7:00 AM to 8:30 AM Buffet Breakfast 8:00 AM to 3:00 PM Testing 12:00 Noon Buffet Lunch 3:00 PM to 5:00 PM Break Down Facility FEES: Binghamton is a small community nestled in the Catskill Mountains of New York State. The Holiday Inn is located in the Arena area of downtown. As such we have chosen to cater the meals for this interoperability workshop to insure all of the participants will maximize the value of their time spent at the workshop. The charge for the Workshop is $300 per person. The fee covers the cost of the meals and organizing the event. The fee covers the entire week. Each person attending must pay the full amount. There will be no provision for a daily rate for those not attending the entire week. Checks, wire transfers, or credit cards will be accepted. Cash payments are not available. Payment must be received in advance. Refunds will not be made for cancellations after October 16, 1998. Please fill out and return the payment form with your payment. FACILITIES: Tables and Power: Each participating company will be provided one 8-foot table, 5 Amps of power, and one power strip. Bring additional power strips if you need them. If you know your test setup will require more than 5 Amps please provide that information in advance on the application form and it will be available. Backbone Ethernet Network: Each participating company will be provided a single RJ-45 cable attached to the backbone Ethernet network. The backbone Ethernet network will be a public class C network that is connected to the Internet via a router with all routes configured statically (no dynamic routing). In the application you will be asked to specify which of the following configurations you will need and the quantity. You may request multiple host or routed network addresses but you must bring your own switches/hubs to attach more than a single device to the backbone Ethernet network. Configurations 2 and 3 require you to bring your own router. Configuration 1: Host address; a single IP address assigned from the backbone Ethernet network (a public class C network). Configuration 2: Routed private network address; a single IP address assigned from the backbone Ethernet network (a public class C network) and a private class C network (to be assigned) with a static route configured in the backbone router to the single IP address. Configuration 3: Routed private and public network addresses; a single IP address assigned from the backbone Ethernet network (a public class C network) and a private class C network (to be assigned) and a public subnetwork (/29 subnet address to be assigned) with a static route for both networks configured in the backbone router to the single IP address. Note: you can not reach the Internet with private network addresses. If these configurations do not satisfy your requirements, please contact James Matheke at 614-723-1525 or jmatheke@web.compuserve.com. File Transfer Servers: Servers will be available for file transfers as defined in the test procedures. ISDN Lines: BRI and PRI lines will be provided for testing from a Madge switch. The BRI lines will be provisioned as NI-1 with CSV/D on each B channel. The BRI lines may be either a U or S/T interface. There will be a limited number of PRI lines available. The PRI lines will be assigned to those companies with products that do not support BRI. If you request a PRI line, please bring a CSU to terminate the T1 interface. The PRI lines will be NI-2. Telephone Service: There will be a telephone on each table in the workshop for voice service provided by a networked PBX. SHIPPING EQUIPMENT TO HOLIDAY INN BINGHAMTON ARENA, BINGHAMTON, NY: Participants will be responsible for bringing workstations and network equipment. You may ship your equipment to: Your Name Holiday Inn Binghamton Arena 2-8 Hawley Street Binghamton, NY 13901 607-722-1212 Please mark "VPN" Schedule your equipment to arrive at the Holiday Inn Binghamton Arena between October 19 and October 23, 1998. Please provide shipping information, such as date shipped, tracking number, and number of boxes as well as your room reservation confirmation number, to the Holiday Inn Binghamton Arena so receipt of your shipment may be confirmed and accepted. IMPORTANT: Please bring the shipping documents for the return of your equipment back to your company. These documents include the carrier form. International shipments must include all appropriate documents, including carrier forms and invoices. Additionally, please make arrangements with your carrier in advance for pickup of the equipment at the Holiday Inn Binghamton Arena on Friday, October 30, 1998. These two points are very important. Neither IBM AS/400 Endicott nor the Holiday Inn Binghamton Arena will be able to provide shipping forms or customs forms to you. You have to bring your own. Also neither IBM AS/400 Endicott nor the Holiday Inn Binghamton Arena will be able to store your equipment past Friday, October 30, 1998. It is your responsibility to make arrangements to have everything picked up by that day. ACCOMMODATIONS: Be sure to register by September 25, 1998 to insure that rooms will be available for you and your group. The block of rooms is available at Holiday Inn Binghamton Arena 2-8 Hawley Street Binghamton, NY 13901 607-722-1212 Register under "VPN Bakeoff Lab" to get the Workshop rate of $81.00 plus tax per night with no charge for parking. Rooms are available for check in October 26, 1998 through check out October 30, 1998. Check in time is 4:00 PM and check out time is 12:00 Noon. A deposit equal to one night's stay must accompany the hotel room reservations. The Holiday Inn Binghamton Arena will accept personal checks, AMEX, MC, VISA, DC, DIS, or Vouchers. Airport Access: Jet service is available to Binghamton (BGM) by USAir through Pittsburgh, PA. Other airlines have jet service to Syracuse, New York (SYR). Directions: To the Holiday Inn Binghamton Arena from the Syracuse International Airport: Syracuse International Airport is located just north of central upstate New York's city of Syracuse. Exit from Syracuse Airport and take Interstate Route 81 South for 80 miles to Binghamton, NY. Upon approaching Binghamton, just past Exit 5, take the fork to the right from Interstate Route 81 South to New York State (NYS) Route 17 West. Proceed to directions labeled 2) below. To the Holiday Inn Binghamton Arena from the Binghamton Regional Airport: Binghamton Regional Airport is located in southern upstate New York's Broome County, just north of the city of Binghamton. Exit Binghamton Airport and keep left (south) onto two-lane asphalt "Airport Road". Proceed for approximately 7 miles to the first traffic light and Airport Road will turn into a four-lane divided highway. After passing through the second traffic light, about 2 miles, take an immediate right onto the entrance ramp to New York State (NYS) Route 17 West. 2) Proceed on NYS Route 17 West past the Oakdale Mall Exit and take exit 70S, NYS Route 201, which will lead to and then turn into NYS Route 201 South. First look for the overhead sign with Vestal and Binghamton BOTH contained, and then look for the overhead sign with just Vestal contained. Once on the bridge over the Susquehanna River begin looking for overhead signs with Binghamton and NYS Route 434 East. (NYS Route 434 West goes to the Vestal Town Mall). Loop around to the right from NYS Route 201 South to NYS Route 434 East towards Binghamton. Once on Route 434 East, proceed for 5-6 miles. Upon entering Downtown Binghamton, you cross over a concrete bridge (Conklin Bridge) with a 90-degree turn to the left. At the next traffic light turn left and the Holiday Inn Binghamton Arena is straight ahead. Just before entering the Conklin Bridge, the Number Five Restaurant is on the right. REGISTRATION: This will be a "self organizing" event. It will be your responsibility to develop your own test plan and to arrange your own testing partners. This method has worked well in the past and we believe that it provides the most productive environment for testing. In the application you will be asked to list the days you will be available for testing. Please be accurate so everyone has an opportunity to test with you. Please fill out the Product Section of the application carefully. We will use the information to put together a binder of data to assist when you are testing with partners. To register for the VPN Interoperability Workshop fill out the following application and return it by email immediately to reserve your place. The email address is . If you have any questions, send email or call Bob Larribeau, bob@larribeau.com , 415-241-9920 Based on past workshops, expected attendance is 60 companies. Get the reservation in early to assure yourself a place. ------------------------------ PAYMENT FORM---------------------------- PLEASE RETURN THIS APPLICATION VIA EMAIL. Name: __________________________________ Company: _______________________________ Address: _________________________________ __________________________________________ City, State, Zip ________________________________ Country: _____________________________________ Phone: _________________________________ Fax: ___________________________________ Email: _________________________________ Number of Attendees: _________ x $300.00 = Total Payment $_____________ Refunds will not be made for cancellations after October 16, 1998. Pay by credit card: Fill out the form below and fax it to the CIUG at (415) 753-6942. Credit Card Type (Circle One): American Express, Visa, Master Charge, JCB Credit Card Number: ______________________________ Expiration Date: _________________________________ Name: ____________________________________________ Signature: _______________________________________ Pay by check: Send a check made out to the CIUG for $300 for each participant to: California ISDN Users' Group PO Box 27901-391 San Francisco, CA 94127 Wire funds to: California ISDN Users' Group Account Number 02882 07752 Bank of America #0288 288 West Portal Avenue San Francisco, CA 94127 USA ----------------------------------------------------------------------- APPLICATION PLEASE RETURN THIS APPLICATION VIA EMAIL. Please enter the name of the Workshop Coordinator who will coordinate your registration. We will send emails to this person to give the latest information on the workshop and to verify your registration. Name: __________________________________ Address: _________________________________ __________________________________________ City, State, Zip ________________________________ Country: _____________________________________ Phone: _________________________________ Fax: ___________________________________ Email: _________________________________ Do you want your company's name included in the CIUG and IBM AS/400 Endicott press release as a participant? Yes or No Provide the name, address, phone, fax, and email of your public relations contact. We will give this person an opportunity to review the release in advance. Names of ALL Participants and Shirt size (including the Workshop Coordinator listed above if they will attend): Name_____________________ Shirt size M L XL XXL Name_____________________ Shirt size M L XL XXL Monday Evening Reception (Yes or No) Days available for testing: Tu W Th F Number of tables: IP Addresses- Number of Host addresses (configuration 1): Number of Routed private network addresses (configuration 2): Number of Routed private and public network addresses (configuration 3): Additional Power Requirements: Number of BRI lines: 1 2 More than 2 (please specify) S/T or U interface: PRI (Yes or No): Additional Madge Switch Requirements: Will you be testing: IPSEC (Y/N) IKE (Y/N) L2TP (Y/N) L2TP with IPSEC (Y/N) Will you be providing: CA services (Y/N) ---------------------------------------------------- Product Section: Fill out a Product Section for each device you are testing. Product Name: Software Version: Product Type, check all that apply: Router_____ Firewall_____ IPSEC Gateway_____ IPSEC Host_____ Client Software_____ Other________________________ For IPSEC and IKE ------------------------------------------------------ IPSEC: IPSEC manual keys (Y/N) AH tunnel (Y/N) AH transport (Y/N) ESP tunnel (Y/N) ESP transport (Y/N) Transport adjacency (Y/N) Nested tunneling (Y/N) Iterated tunneling (Y/N) ESP cipher algorithms- DES-CBC mandatory (Y/N) 3DES optional (Y/N) RC5 optional (Y/N) CAST optional (Y/N) NULL optional (Y/N) ESP authenticators- HMAC-MD-5 mandatory (Y/N) HMAC-SHA-1 mandatory (Y/N) AH- HMAC-MD-5 mandatory (Y/N) HMAC-SHA-1 mandatory (Y/N) IPPCP optional- LZS (Y/N) DEFLATE (Y/N) IKE: Exchanges- Main mode (identity protect) (Y/N) Aggressive mode (Y/N) Quick mode (Y/N) Authentication methods- Preshared keys (Y/N) RSA signature (Y/N) DSS signature (Y/N) RSA Encryption (Y/N) Revised RSA encryption (Y/N) Certificate Validation (Y/N) No CA infrastructure (Y/N) CA hierarchy supported (Y/N) CA cross-cert supported (Y/N) Encryption algorithms- DES mandatory (Y/N) Triple DES (Y/N) CAST (Y/N) RC5 (Y/N) Other___________ Hash algorithms- MD-5 (Y/N) Sha-1 (Y/N) Other___________ Optional payloads- Cert (Y/N) Vendor-ID (Y/N) Cert request (Y/N) Other___________ Commit bit (Y/N) CA Interoperability- PKIX part3 (Y/N) PKCS 10/7 (Y/N) -Manual (Y/N) -SMTP (Y/N) -HTTP (Y/N) Test roles, check all that apply- Gateway to Gateway____ Gateway to Host____ Host to Host____ NAT (Y/N) L2TP as NAT bypass (Y/N) For L2TP--------------------------------------------------------------- LCP Options: Default MRU__________________________ Default MRRU_________________________ Authentication: PAP authenticator (Y/N) PAP authenticatee (Y/N) CHAP authenticator (Y/N) CHAP authenticatee (Y/N) CHAP Re-challenge (Y/N) MS CHAP (Y/N) L2TP: LAC (Y/N) LNS (Y/N) L2TP Client (Y/N) L2TP Options - LAC: Proxy LCP (Y/N) Proxy Authentication PAP (Y/N) Proxy Authentication CHAP (Y/N) Proxy Authentication MS-CHAP (Y/N) Tunnel Authentication (Y/N) Hidden AVPs (Y/N) Outgoing Calls (Y/N) Flow Control/Sequencing (Y/N) L2TPSEC (Y/N) IPSEC (Y/N) L2TP Options - LNS: Proxy LCP (Y/N) Proxy Authentication PAP (Y/N) Proxy Authentication CHAP (Y/N) Proxy Authentication MS-CHAP (Y/N) Tunnel Authentication (Y/N) Hidden AVPs (Y/N) Outgoing Calls (Y/N) Flow Control/Sequencing (Y/N) MP (bundle tunneled links) (Y/N) ECP (Y/N) CCP (Y/N) Algorithms______________________________ CBCP (Y/N) L2TPSEC (Y/N) IPSEC (Y/N) Tunnel Types- Voluntary (Y/N) Compulsory (Y/N) L2TP Options - Client: Proxy LCP (Y/N) Proxy Authentication PAP (Y/N) Proxy Authentication CHAP (Y/N) Proxy Authentication MS-CHAP (Y/N) Tunnel Authentication (Y/N) Hidden AVPs (Y/N) Outgoing Calls (Y/N) Flow Control/Sequencing (Y/N) L2TPSEC (Y/N) IPSEC (Y/N) IPCP: Numbered links (Y/N) Un-numbered links (Y/N) Tx if Un-numbered____________ Options supported____________ IP assignment (Y/N) IP Pool (Y/N) DHCP (Y/N) IPXCP: Numbered links (Y/N) Un-numbered links (Y/N) Tx if Un-numbered____________ Options supported____________ From owner-ipsec Sat Aug 22 12:48:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA12454 for ipsec-outgoing; Sat, 22 Aug 1998 12:46:58 -0400 (EDT) Message-Id: <199808221703.KAA07354@chip.cisco.com> To: Armando Fratezi cc: ipsec@tis.com Subject: Re: VPN Interoperability Workshop Oct 26 - 30 In-reply-to: Your message of "Sat, 22 Aug 1998 12:41:08 EDT." <5010400026154616000002L062*@MHS> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7352.903805401.1@cisco.com> Date: Sat, 22 Aug 1998 10:03:21 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Wow! $300 for 4 continental breakfasts and 4 buffer lunches. Dinner is on our own. That gives Binghamton, NY a higher per-diem than Paris, London, or Rome. I actually heard it wasn't that nice. This sets a bad precedent. None of the previous sponsors charged for the IPSec bakeoffs since they got lots of free PR. I guess IBM wants their cake and wants us to pay for it too. Shame. Shame. Dan. Note: this is my personal opinion and not that of my company. I don't even know what my company's opinion on the matter is. On Sat, 22 Aug 1998 12:41:08 EDT Armando Fratezi wrote > Return your application via email and reserve your hotel rooms before > September 25, 1998! > > To Networking Product Developers: > > The California ISDN Users' Group (CIUG) invites you to participate in > the VPN Interoperability Workshop featuring IPSEC, IKE, and L2TP hosted > by IBM AS/400 Endicott at the Holiday Inn Binghamton Arena in > Binghamton, New York. The VPN Workshop combines the eighth CIUG PPP > Interoperability Workshop and the sixth IPSEC Interoperability Workshop. > > The Workshop will be open to companies with products that implement: > > IP Security (IPSEC) > Internet Key Exchange (IKE) > PPP Layer 2 Tunneling Protocol (PPP L2TP) > > The Workshop will provide an opportunity to test the interoperability of > your products with products from all of the other companies attending. > > The participating companies are asked to bring products that are > released, at beta or near beta level for IPSEC, IKE, and L2TP. > > Participants are engineering staff intimately familiar with the software > and hardware that implements the capabilities being tested and are > expected to have a thorough understanding of the protocols. > > This Workshop will be open to only the participants. This is not a > spectator event; it is not open to observers. Some participants will be > working with unreleased products and the other attendees are expected to > respect their privacy. > > SPONSORSHIP: > > IBM AS/400 Endicott is the host for the VPN Interoperability Workshop. > Worldcom Advanced Networks will provide the Backbone Test Ethernet and > access to the real Internet. In addition to the general test plan, > ICSA, Inc. will work with IPSEC/IKE testing that is based on the ICSA > IPSec 1.1 Certification Model. > > PRESS RELEASE: > > The CIUG and IBM AS/400 Endicott plan to make a press release announcing > the workshop and listing the participants. There will be no mention of > any specific results of the testing in this release. Please indicate in > the application if you want your company's name included in this release > as a participant. If you include your public relations person in the > application, that contact will be given the opportunity to review the > release in advance. > > SCHEDULE: > > Monday, October 26 > > 8:00 PM to 9:30 PM Reception > > Tuesday, October 27 > > 7:00 AM to 8:30 AM Buffet Breakfast > 8:00 AM Setup > 12:00 Noon Buffet Lunch > 1:00 PM to 9:00 PM Testing > > Wednesday, October 28 > > 7:00 AM to 8:30 AM Buffet Breakfast > 8:00 AM to 9:00 PM Testing > 12:00 Noon Buffet Lunch > > Thursday, October 29 > > 7:00 AM to 8:30 AM Buffet Breakfast > 8:00 AM to 9:00 PM Testing > 12:00 Noon Buffet Lunch > 3:00 PM to 5:00 PM Group Meeting > 6:00 PM Get Together and Evening Refreshments > > Friday, October 30 > > 7:00 AM to 8:30 AM Buffet Breakfast > 8:00 AM to 3:00 PM Testing > 12:00 Noon Buffet Lunch > 3:00 PM to 5:00 PM Break Down Facility > > FEES: > > Binghamton is a small community nestled in the Catskill Mountains of New > York State. The Holiday Inn is located in the Arena area of downtown. > As such we have chosen to cater the meals for this interoperability > workshop to insure all of the participants will maximize the value of > their time spent at the workshop. > > The charge for the Workshop is $300 per person. The fee covers the cost > of the meals and organizing the event. The fee covers the entire week. > Each person attending must pay the full amount. There will be no > provision for a daily rate for those not attending the entire week. > Checks, wire transfers, or credit cards will be accepted. Cash payments > are not available. Payment must be received in advance. Refunds will > not be made for cancellations after October 16, 1998. Please fill out > and return the payment form with your payment. From owner-ipsec Sat Aug 22 14:01:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA12571 for ipsec-outgoing; Sat, 22 Aug 1998 14:00:57 -0400 (EDT) Message-ID: <0171F2F8F9E5D011A4D10060B03CFB441225D9@SCC-SERVER3> From: CJ Gibson To: Daniel Harkins , Armando Fratezi Cc: ipsec@tis.com Subject: RE: VPN Interoperability Workshop Oct 26 - 30 Date: Sat, 22 Aug 1998 11:27:01 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hear, hear!! I think this is a bit out of line too. And that is also only a personal opinion. Seems to me the bait is the press release and the $300 is the hook. Don't know if I want to bite... -CJ -----Original Message----- From: Daniel Harkins [SMTP:dharkins@cisco.com] Sent: Saturday, August 22, 1998 10:03 AM To: Armando Fratezi Cc: ipsec@tis.com Subject: Re: VPN Interoperability Workshop Oct 26 - 30 Wow! $300 for 4 continental breakfasts and 4 buffer lunches. Dinner is on our own. That gives Binghamton, NY a higher per-diem than Paris, London, or Rome. I actually heard it wasn't that nice. This sets a bad precedent. None of the previous sponsors charged for the IPSec bakeoffs since they got lots of free PR. I guess IBM wants their cake and wants us to pay for it too. Shame. Shame. Dan. Note: this is my personal opinion and not that of my company. I don't even know what my company's opinion on the matter is. On Sat, 22 Aug 1998 12:41:08 EDT Armando Fratezi wrote > Return your application via email and reserve your hotel rooms before > September 25, 1998! > > To Networking Product Developers: > > The California ISDN Users' Group (CIUG) invites you to participate in > the VPN Interoperability Workshop featuring IPSEC, IKE, and L2TP hosted > by IBM AS/400 Endicott at the Holiday Inn Binghamton Arena in > Binghamton, New York. The VPN Workshop combines the eighth CIUG PPP > Interoperability Workshop and the sixth IPSEC Interoperability Workshop. > > The Workshop will be open to companies with products that implement: > > IP Security (IPSEC) > Internet Key Exchange (IKE) > PPP Layer 2 Tunneling Protocol (PPP L2TP) > > The Workshop will provide an opportunity to test the interoperability of > your products with products from all of the other companies attending. > > The participating companies are asked to bring products that are > released, at beta or near beta level for IPSEC, IKE, and L2TP. > > Participants are engineering staff intimately familiar with the software > and hardware that implements the capabilities being tested and are > expected to have a thorough understanding of the protocols. > > This Workshop will be open to only the participants. This is not a > spectator event; it is not open to observers. Some participants will be > working with unreleased products and the other attendees are expected to > respect their privacy. > > SPONSORSHIP: > > IBM AS/400 Endicott is the host for the VPN Interoperability Workshop. > Worldcom Advanced Networks will provide the Backbone Test Ethernet and > access to the real Internet. In addition to the general test plan, > ICSA, Inc. will work with IPSEC/IKE testing that is based on the ICSA > IPSec 1.1 Certification Model. > > PRESS RELEASE: > > The CIUG and IBM AS/400 Endicott plan to make a press release announcing > the workshop and listing the participants. There will be no mention of > any specific results of the testing in this release. Please indicate in > the application if you want your company's name included in this release > as a participant. If you include your public relations person in the > application, that contact will be given the opportunity to review the > release in advance. > > SCHEDULE: > > Monday, October 26 > > 8:00 PM to 9:30 PM Reception > > Tuesday, October 27 > > 7:00 AM to 8:30 AM Buffet Breakfast > 8:00 AM Setup > 12:00 Noon Buffet Lunch > 1:00 PM to 9:00 PM Testing > > Wednesday, October 28 > > 7:00 AM to 8:30 AM Buffet Breakfast > 8:00 AM to 9:00 PM Testing > 12:00 Noon Buffet Lunch > > Thursday, October 29 > > 7:00 AM to 8:30 AM Buffet Breakfast > 8:00 AM to 9:00 PM Testing > 12:00 Noon Buffet Lunch > 3:00 PM to 5:00 PM Group Meeting > 6:00 PM Get Together and Evening Refreshments > > Friday, October 30 > > 7:00 AM to 8:30 AM Buffet Breakfast > 8:00 AM to 3:00 PM Testing > 12:00 Noon Buffet Lunch > 3:00 PM to 5:00 PM Break Down Facility > > FEES: > > Binghamton is a small community nestled in the Catskill Mountains of New > York State. The Holiday Inn is located in the Arena area of downtown. > As such we have chosen to cater the meals for this interoperability > workshop to insure all of the participants will maximize the value of > their time spent at the workshop. > > The charge for the Workshop is $300 per person. The fee covers the cost > of the meals and organizing the event. The fee covers the entire week. > Each person attending must pay the full amount. There will be no > provision for a daily rate for those not attending the entire week. > Checks, wire transfers, or credit cards will be accepted. Cash payments > are not available. Payment must be received in advance. Refunds will > not be made for cancellations after October 16, 1998. Please fill out > and return the payment form with your payment. From owner-ipsec Sat Aug 22 19:42:12 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA13294 for ipsec-outgoing; Sat, 22 Aug 1998 19:38:57 -0400 (EDT) Message-ID: <35DF58C0.FC7CB859@ire-ma.com> Date: Sat, 22 Aug 1998 19:48:17 -0400 From: bkavsan X-Mailer: Mozilla 4.03 [en] (Win95; U) MIME-Version: 1.0 To: ipsec@tis.com Subject: OID question 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 found these four OIDs for RSA/MD5 algorithms that can be used in certificate encoding. Does anyone know which one(s) are used in IPsec certificates? #define szOID_RSA_MD5RSA "1.2.840.113549.1.1.4" #define szOID_OIWSEC_md5RSA "1.3.14.3.2.3" #define szOID_OIWSEC_md5RSASign "1.3.14.3.2.25" #define szOID_RSA_MD5 "1.2.840.113549.2.5" Thank you Slava Kavsan IRE From owner-ipsec Sun Aug 23 19:38:16 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA15170 for ipsec-outgoing; Sun, 23 Aug 1998 19:34:03 -0400 (EDT) Date: Sun, 23 Aug 1998 19:50:15 -0400 From: "D. Hugh Redelmeier" To: William Dixon cc: "'ipsec@tis.com'" Subject: Re: IPSec interop workshop Aug 31st - Sept 3 invitation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Tue, 4 Aug 1998, William Dixon wrote: | I am concerned that we are not having enough opportunities for comprehensive | and/or sophisticated interoperability testing. So I'd like to offer one | during the week after the IETF (not great timing I know). Great! Our team will be represented. (You have us down as Gnu, I think, but we are actually FreeS/WAN). | Due to the small facility, I'd like to prioritize for those who can | negotiate and perform ALL of the following functionality: | IKE - Negotiate and perform | - Multiple auth method proposals I'm not sure what you mean by this -- multiple AH transform proposals? | - Certificate authentication and certificate request payloads | - Dynamic rekey with PFS for both main mode and quick mode | - Selectors (filters) to the IPaddress, IP Subnet, and port | IPSec | - ESP with 56bitDES, null-ESP, MD5 and SHA1 I presume that you mean ESP with {DES, null} x {MD5-96, SHA1-96} | - Transport and tunnel mode | | Implementations should also have | IKE | - AND proposal Do you mean multiple transform payloads with the same transform number? | - SA delete payload | - Lifetimes in both bytes and times | - Group 2 DH with 3DES | - 512bit DH or explicit p & g Huh? Do you mean MODP with 512? 512 is not strong enough, and it is not a standard group. What is this about? | IPSec | - Protocol and port filters | - L2TP/IPSec integration | - AH with MD5 and SHA1 | - AH+ESP combination | - ESP 3DES | - ESP 40bitDES Ditto: 40 bit isn't strong enough and isn't in the standard, for good reasons. | 2. IPSec Functionality Testing | 1. Basic interop on combinations | 2. Certificate Infrastructure | - Cert Server certificates from: Entrust, Microsoft, Verisign, | Netscape | - Cert trust verification using hierarchy in PKI infrastructures | - Using CRLs during cert validation ? | - Timing of IKE successful/unsuccessful negotiation using certs, how | transparent for end-to-end? | 3. IKE retransmit behavior | 4. Export <-> Export, Export <-> Domestic | - Basic IKE and IPSec tests | - Explicit p&g DH with 40bit DES I don't understand this. We have to export to get to this site :-) | 5. IKE commit bit | 6. Throughput & number of simultaneous negotiations performance testing | against different implementations | 7. Reboot recovery (peer reboot losing it's security associations) | 8. Scenarios - | - End-to-End transport long lived security associations (over night, | data transfer >1Gb) with frequent dynamic rekey | - End-to-GW tunnel long lived security associations (over night, | data transfer >1Gb) with frequent dynamic rekey | - Policy change events while under SA load | - End-to-End SA through IPSec tunnels, initiation both ways | - Client End-to-End through client-to-GW tunnel SA, initiate from | client for tunnel, then initiation both ways for end-to-end | - Client-to-GW transport SA for secure management | 9. Multiple auth method proposals and AND proposal Is this the same as one or two of the above? | 10. Discuss reliability requirements for SA establishment, maintenance under | load, heavy fragmentation, packet corruption, packet loss Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253 From owner-ipsec Mon Aug 24 07:59:09 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA17732 for ipsec-outgoing; Mon, 24 Aug 1998 07:53:06 -0400 (EDT) Date: Sat, 22 Aug 1998 11:07:12 -0500 From: Bezalel Gavish Subject: ICTEC 98 Conference - Call for Participation X-Sender: gavishb@ctrvax.vanderbilt.edu To: (Recipient list suppressed) Message-id: <01J0WHG7DUD09GGVHY@ctrvax.Vanderbilt.Edu> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Content-type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Call for Participation First International Conference on Telecommunications and Electronic Commerce (ICTEC) Nashville, USA November 20-22, 1998 http://cottonian.ogsm.vanderbilt.edu/ICTEC/ Sponsored by Vanderbilt University Institute for Public Policy Studies (VIPPS), BellSouth, Magnetek, National Commercial Bank (Saudi Arabia), INFORMS Colleges on Information Systems and Telecommunications, IFIP WG 7.3, ATSMA Over the past few years, electronic commerce (EC) has emerged as a dramatic new mode of business. Today, almost every company is either using or considering EC. Advances in telecommunications and automated processes are already forcing dramatic changes in a variety of industries, ranging from banking and finance to music and entertainment. Yet, the TEC environment is still in a relatively early state of evolution. New forums focusing on EC are necessary to stimulate the necessary interactions and knowledge sharing; and given the central role of telecommunications networks in EC, dialogue between telecommunications researchers and EC researchers is essential. ICTEC will bring together both academic and industrial researchers in the fields of telecommunications and EC, to discuss new technological developments and their implications for EC, as well as technological issues that need to be addressed to further the effectiveness and efficiency of EC. The conference will combine research tracks in which technical papers will be presented, with industrial tracks consisting of panels, plenary speakers and exhibits. The conference will include technical sessions, panel discussions and plenary talks on topics such as the following: EC Architecture Information Management Issues in EC EC Developments in Various Countries EC Developments in Specific Industries Document Management Agent-based EC Systems EC Market Mechanisms Marketing and Operations Issues in EC Network Management issues Legal and Policy Issues in TEC EC Strategy Payment Systems in EC Traffic Management Issues Conference General Chair: Bezalel Gavish, Vanderbilt University, Nashville, USA. Information on the conference, including location and registration information, forms and contacts, is available on the WWW, at http://cottonian.ogsm.vanderbilt.edu/ICTEC/ ---------------------------------------------------------------------------- -------------- Bezalel Gavish Owen Graduate School of Management Vanderbilt University Nashville, TN 37220 USA Tel: Office (615) 322-3659 FAX (615) 343-7177 Home (615) 370-0813 Email: Gavishb@ctral1.vanderbilt.edu From owner-ipsec Mon Aug 24 09:29:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA18368 for ipsec-outgoing; Mon, 24 Aug 1998 09:26:08 -0400 (EDT) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <35C6768C.DB367A67@checkpoint.com> References: from "Stephen Kent" at Jul 25, 98 06:10:58 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 24 Aug 1998 09:45:34 -0400 To: Moshe Litvin From: Stephen Kent Subject: Re: Comments on "Hybrid Auth. mode for IKE" Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Moshe, >So what you are saying is that every one that is not yet ready to use >certificates and want to use a method not vulnerable to dictionary attack is >not allowed to use IPSEC? Gee, it sounds so negative when you say it that way ;-)! How about, a vendor who wants to sell IPsec products should get its act together and support IKE with certs, rather than taking shortcuts and using "market demand" as an excuse. Yes, I definately like that phrasing better. Steve From owner-ipsec Mon Aug 24 09:51:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA18435 for ipsec-outgoing; Mon, 24 Aug 1998 09:48:08 -0400 (EDT) Message-ID: <35E17229.3C63C4CC@cale.checkpoint.com> Date: Mon, 24 Aug 1998 17:01:13 +0300 From: Moshe Litvin X-Mailer: Mozilla 4.5b1 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: Moshe Litvin , ipsec@tis.com Subject: Re: Comments on "Hybrid Auth. mode for IKE" References: from "Stephen Kent" at Jul 25, 98 06:10:58 pm Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen Kent wrote: > > Moshe, > > >So what you are saying is that every one that is not yet ready to use > >certificates and want to use a method not vulnerable to dictionary attack is > >not allowed to use IPSEC? > > Gee, it sounds so negative when you say it that way ;-)! > > How about, a vendor who wants to sell IPsec products should get its act > together and support IKE with certs, rather than taking shortcuts and using > "market demand" as an excuse. > > Yes, I definately like that phrasing better. To make things clearer: We currently support IKE with certificates and not with legacy authentication systems, yet we believe that we should give a standard based solution for customers that want to continue using those systems as well. Moshe -- ----------------------------------------------------------------------- Moshe Litvin Check Point Software Technologies Ltd. moshe@checkpoint.com Tel: +972-3-753-4601 (972-3-753-4555) Fax: +972-3-575-9256 ----------------------------------------------------------------------- From owner-ipsec Mon Aug 24 14:13:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA19453 for ipsec-outgoing; Mon, 24 Aug 1998 14:09:16 -0400 (EDT) Date: Mon, 24 Aug 1998 11:14:49 -0700 (PDT) From: Mohan Parthasarathy Message-Id: <199808241814.LAA04444@locked.eng.sun.com> To: ipsec@tis.com Subject: MSS option with IPSEC. X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk If a TCP connection is using AH or ESP does the mss option sent during the SYN account for the AH/ESP headers also ? Assume the MTU of the link is 1500. Normally the mss (without any options) is 1460 (20 bytes of TCP and 20 bytes of IP header). If the connection uses AH/ESP does the sending side decrease the mss further ? Curious to know what the other implementation do out there. Currently i am assuming it decreases the mss further if AH/ESP is present. -mohan From owner-ipsec Mon Aug 24 14:34:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA19554 for ipsec-outgoing; Mon, 24 Aug 1998 14:33:19 -0400 (EDT) Message-Id: From: "Rizwan Mallal" To: "bkavsan" , Subject: Re: OID question Date: Mon, 24 Aug 1998 14:50:05 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I believe it is the first one #define szOID_RSA_MD5RSA "1.2.840.113549.1.1.4" unless someone can correct me. --Rizwan Raptor Systems ---------- From: bkavsan To: ipsec@tis.com Subject: OID question Date: Saturday, August 22, 1998 7:48 PM I found these four OIDs for RSA/MD5 algorithms that can be used in certificate encoding. Does anyone know which one(s) are used in IPsec certificates? #define szOID_RSA_MD5RSA "1.2.840.113549.1.1.4" #define szOID_OIWSEC_md5RSA "1.3.14.3.2.3" #define szOID_OIWSEC_md5RSASign "1.3.14.3.2.25" #define szOID_RSA_MD5 "1.2.840.113549.2.5" Thank you Slava Kavsan IRE From owner-ipsec Mon Aug 24 15:07:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA19648 for ipsec-outgoing; Mon, 24 Aug 1998 15:05:17 -0400 (EDT) To: Mohan Parthasarathy cc: ipsec@tis.com In-reply-to: Mohan.Parthasarathy's message of Mon, 24 Aug 98 11:14:49 MST. <199808241814.LAA04444@locked.eng.sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: MSS option with IPSEC. Date: Tue, 25 Aug 1998 04:21:41 +0900 Message-ID: <3302.903986501@turmeric.itojun.org> From: Jun-ichiro itojun Itoh Sender: owner-ipsec@ex.tis.com Precedence: bulk >If a TCP connection is using AH or ESP does the mss option sent >during the SYN account for the AH/ESP headers also ? > >Assume the MTU of the link is 1500. Normally the mss (without >any options) is 1460 (20 bytes of TCP and 20 bytes of IP >header). If the connection uses AH/ESP does the sending >side decrease the mss further ? Curious to know what >the other implementation do out there. Currently i am assuming >it decreases the mss further if AH/ESP is present. KAME (http://www.kame.net/) decreases mss value by AH/ESP header size. It is working well. I dunno what happens if security association is changed frequently during TCP is connected, if anyone has experiences please let me know... itojun From owner-ipsec Mon Aug 24 15:28:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA19705 for ipsec-outgoing; Mon, 24 Aug 1998 15:24:17 -0400 (EDT) Date: Mon, 24 Aug 1998 14:41:32 -0500 (CDT) From: David Borman Message-Id: <199808241941.OAA00393@frantic.bsdi.com> To: Mohan.Parthasarathy@Eng.Sun.Com Subject: Re: MSS option with IPSEC. Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Mohan, > Date: Mon, 24 Aug 1998 11:14:49 -0700 (PDT) > From: Mohan Parthasarathy > Subject: MSS option with IPSEC. > ... > If a TCP connection is using AH or ESP does the mss option sent > during the SYN account for the AH/ESP headers also ? No. The TCP MSS is MTU - sizeof(fixed TCP header) - sizeof(fixed IP header) or, MTU - 40. The sending side is then responsible for decreasing the size of the TCP data to account for any IP or TCP options. By extrapolation with the insertion of the AH and/or ESP header, the sending TCP should also decrease the size of the TCP data to account for that. The MSS option is left unchanged. Of course, if you are doing AH/ESP in the context of an encapsulating tunnel, then the tunnel should have a smaller MTU to account for the encapsulating headers. So the MSS is still MTU - 40, but it will be smaller because of the smaller MTU on the tunnel. -David Borman, dab@bsdi.com From owner-ipsec Mon Aug 24 15:49:31 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA19815 for ipsec-outgoing; Mon, 24 Aug 1998 15:46:16 -0400 (EDT) Message-Id: <35E1C720.AEF537CC@lucent.com> Date: Mon, 24 Aug 1998 15:03:44 -0500 From: "David W. Faucher" Organization: Lucent Technologies X-Mailer: Mozilla 4.03 [en] (WinNT; U) Mime-Version: 1.0 To: ipsec@tis.com Subject: IKE use of DOI=0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk When negotiating an ISAKMP SA using a value of zero for the DOI and situation, what is the size of the situation field? Below is an observation that while currently does not exist, there is the potential for it to occur. When an ISAKMP SA is negotiated with a DOI value of zero, a post phase 1 exchange using a DOI specific exchange type (32-239) could potentially be ambiguous (unless the first message of the exchange contained a payload that had a corresponding DOI field). thanks -- David W. Faucher Lucent Technologies dfaucher@lucent.com From owner-ipsec Mon Aug 24 16:31:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA20006 for ipsec-outgoing; Mon, 24 Aug 1998 16:27:18 -0400 (EDT) Message-Id: <199808242043.QAA04819@thunk.epilogue.com> From: Bill Sommerfeld To: Jun-ichiro itojun Itoh Cc: ipsec@tis.com Subject: Re: MSS option with IPSEC. In-Reply-To: Your message of "Tue, 25 Aug 1998 04:21:41 +0900." <3302.903986501@turmeric.itojun.org> Date: Mon, 24 Aug 1998 16:43:27 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk The mss value isn't as important as the path MTU; if your TCP implements MTU discovery (and it interacts correctly with your ipsec .. i.e., ipsec causes the percived MTU to shrink) the right thing should happen as long as the MSS is big enough.. - Bill From owner-ipsec Mon Aug 24 17:36:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA20317 for ipsec-outgoing; Mon, 24 Aug 1998 17:33:18 -0400 (EDT) Date: Mon, 24 Aug 1998 16:50:15 -0500 (CDT) From: David Borman Message-Id: <199808242150.QAA00649@frantic.bsdi.com> To: itojun@itojun.org, sommerfeld@orchard.arlington.ma.us Subject: Re: MSS option with IPSEC. Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Bill Sommerfeld > Subject: Re: MSS option with IPSEC. > Date: Mon, 24 Aug 1998 16:43:27 -0400 > ... > The mss value isn't as important as the path MTU; if your TCP > implements MTU discovery (and it interacts correctly with your ipsec > .. i.e., ipsec causes the percived MTU to shrink) the right thing > should happen as long as the MSS is big enough.. And that is the key. If one endpoint is the minimum MTU, and it decreases the MSS option to account for the ESP/AH header, and the sender also decreases the TCP data to account for the ESP/AH header, then it won't be sending maximum size packets. Since it is the sender that knows what is really going into the packet, it is the sender that needs to adjust the TCP data to account for the IP/TCP options and the ESP/AH header, and MSS should remain at MTU - 40. -David Borman, dab@bsdi.com From owner-ipsec Mon Aug 24 21:08:00 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA20900 for ipsec-outgoing; Mon, 24 Aug 1998 21:04:26 -0400 (EDT) X-Lotus-FromDomain: CERTICOM From: "Paul Lambert" To: ipsec@tis.com cc: Armando Fratezi , jis@MIT.EDU, "iesg" Message-ID: <8825666A.0058E3E7.00@domino2.certicom.com> Date: Mon, 24 Aug 1998 09:17:43 -0700 Subject: RE: VPN Interoperability Workshop Oct 26 - 30 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@ex.tis.com Precedence: bulk >The CIUG and IBM AS/400 Endicott plan to make >a press release announcing >the workshop and listing the participants. Standards process by press release?? It is not appropriate to have IETF related meeting be the subject of self promoting press releases. Next thing you know you'll have to pay someone to show that you're complaint with the Internet speicifications. Paul CJ Gibson on 08/22/98 11:27:01 AM To: Daniel Harkins , Armando Fratezi cc: ipsec@tis.com (bcc: Paul Lambert/Certicom) Subject: RE: VPN Interoperability Workshop Oct 26 - 30 Hear, hear!! I think this is a bit out of line too. And that is also only a personal opinion. Seems to me the bait is the press release and the $300 is the hook. Don't know if I want to bite... -CJ -----Original Message----- From: Daniel Harkins [SMTP:dharkins@cisco.com] Sent: Saturday, August 22, 1998 10:03 AM To: Armando Fratezi Cc: ipsec@tis.com Subject: Re: VPN Interoperability Workshop Oct 26 - 30 Wow! $300 for 4 continental breakfasts and 4 buffer lunches. Dinner is on our own. That gives Binghamton, NY a higher per-diem than Paris, London, or Rome. I actually heard it wasn't that nice. This sets a bad precedent. None of the previous sponsors charged for the IPSec bakeoffs since they got lots of free PR. I guess IBM wants their cake and wants us to pay for it too. Shame. Shame. Dan. Note: this is my personal opinion and not that of my company. I don't even know what my company's opinion on the matter is. On Sat, 22 Aug 1998 12:41:08 EDT Armando Fratezi wrote > Return your application via email and reserve your hotel rooms before > September 25, 1998! > > To Networking Product Developers: > > The California ISDN Users' Group (CIUG) invites you to participate in > the VPN Interoperability Workshop featuring IPSEC, IKE, and L2TP hosted > by IBM AS/400 Endicott at the Holiday Inn Binghamton Arena in > Binghamton, New York. The VPN Workshop combines the eighth CIUG PPP > Interoperability Workshop and the sixth IPSEC Interoperability Workshop. > > The Workshop will be open to companies with products that implement: > > IP Security (IPSEC) > Internet Key Exchange (IKE) > PPP Layer 2 Tunneling Protocol (PPP L2TP) > > The Workshop will provide an opportunity to test the interoperability of > your products with products from all of the other companies attending. > > The participating companies are asked to bring products that are > released, at beta or near beta level for IPSEC, IKE, and L2TP. > > Participants are engineering staff intimately familiar with the software > and hardware that implements the capabilities being tested and are > expected to have a thorough understanding of the protocols. > > This Workshop will be open to only the participants. This is not a > spectator event; it is not open to observers. Some participants will be > working with unreleased products and the other attendees are expected to > respect their privacy. > > SPONSORSHIP: > > IBM AS/400 Endicott is the host for the VPN Interoperability Workshop. > Worldcom Advanced Networks will provide the Backbone Test Ethernet and > access to the real Internet. In addition to the general test plan, > ICSA, Inc. will work with IPSEC/IKE testing that is based on the ICSA > IPSec 1.1 Certification Model. > > PRESS RELEASE: > > The CIUG and IBM AS/400 Endicott plan to make a press release announcing > the workshop and listing the participants. There will be no mention of > any specific results of the testing in this release. Please indicate in > the application if you want your company's name included in this release > as a participant. If you include your public relations person in the > application, that contact will be given the opportunity to review the > release in advance. > > SCHEDULE: > > Monday, October 26 > > 8:00 PM to 9:30 PM Reception > > Tuesday, October 27 > > 7:00 AM to 8:30 AM Buffet Breakfast > 8:00 AM Setup > 12:00 Noon Buffet Lunch > 1:00 PM to 9:00 PM Testing > > Wednesday, October 28 > > 7:00 AM to 8:30 AM Buffet Breakfast > 8:00 AM to 9:00 PM Testing > 12:00 Noon Buffet Lunch > > Thursday, October 29 > > 7:00 AM to 8:30 AM Buffet Breakfast > 8:00 AM to 9:00 PM Testing > 12:00 Noon Buffet Lunch > 3:00 PM to 5:00 PM Group Meeting > 6:00 PM Get Together and Evening Refreshments > > Friday, October 30 > > 7:00 AM to 8:30 AM Buffet Breakfast > 8:00 AM to 3:00 PM Testing > 12:00 Noon Buffet Lunch > 3:00 PM to 5:00 PM Break Down Facility > > FEES: > > Binghamton is a small community nestled in the Catskill Mountains of New > York State. The Holiday Inn is located in the Arena area of downtown. > As such we have chosen to cater the meals for this interoperability > workshop to insure all of the participants will maximize the value of > their time spent at the workshop. > > The charge for the Workshop is $300 per person. The fee covers the cost > of the meals and organizing the event. The fee covers the entire week. > Each person attending must pay the full amount. There will be no > provision for a daily rate for those not attending the entire week. > Checks, wire transfers, or credit cards will be accepted. Cash payments > are not available. Payment must be received in advance. Refunds will > not be made for cancellations after October 16, 1998. Please fill out > and return the payment form with your payment. From owner-ipsec Tue Aug 25 01:11:12 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA21406 for ipsec-outgoing; Tue, 25 Aug 1998 01:07:24 -0400 (EDT) Message-Id: <3.0.5.32.19980825002428.009f0280@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) X-Priority: 1 (Highest) Date: Tue, 25 Aug 1998 00:24:28 -0500 To: ipsec@tis.com From: Robert Moskowitz Subject: IPsecond focus groups Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I am working on getting people interested in solving select set of IPsecond issues together to put together a quick game plan to get some solid documents out for IPsecond. Times for these are: tues 1300 - 1400 wed 1530 - 1730 thur 1730 - On monday, before the policy BOF we got together a number of people to start policy discussions. One thing that came out of this was a request that each focus area have its own, open, archived, short-lived list so that work remains focused. Ted and I think this is workable. Tuesday is before our IPsec session. Perhaps the error/MIB people could get together then. We will meet on the lower level over by the riverside cafe. Wed I would like to cover remote issues and 'load sharing, high availabity'. A number of items have already been brought up on this. A unified effort should come out of this time. Thursday, I have the Missouri room. I think that those that are ready to author/edit documents or actively develop the documents should come (I am bringing in some food, but not a lot) to check over the work done in the week and set goals of when results will come back to the IPsec list, and the focus list ended. This time is for serious document development planning. Ted and I encourage people that have work items that should reasonably be in IPsecond to get with us during this week, so that we can all understand them, then take them to the list to determine wg concesus on how to proceed. If there are needs for other focus groups (like IKE interaction with certificate worlds (X.509, PGP, DNSSEC, etc)) we will facilitate that. The goal here is to get people committed to getting the next round of items well defined in the next month so that by Orlando we are down at most to nits, not just figuring out what we should do next. Thank you. My Motorola pager gizmo pin is 9934395 for anyone trying to find me..... Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Tue Aug 25 07:48:11 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA22614 for ipsec-outgoing; Tue, 25 Aug 1998 07:42:32 -0400 (EDT) To: Bill Sommerfeld cc: ipsec@tis.com In-reply-to: sommerfeld's message of Mon, 24 Aug 98 16:43:27 -0400. <199808242043.QAA04819@thunk.epilogue.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: MSS option with IPSEC. cc: itojun@itojun.org From: Jun-ichiro itojun Itoh Date: Tue, 25 Aug 1998 07:52:12 +0900 Message-ID: <646.903999132@turmeric.itojun.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk >The mss value isn't as important as the path MTU; if your TCP >implements MTU discovery (and it interacts correctly with your ipsec >.. i.e., ipsec causes the percived MTU to shrink) the right thing >should happen as long as the MSS is big enough.. thanks, I fixed my implementation to not to play with MSS option itself. itojun From owner-ipsec Wed Aug 26 19:54:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA29641 for ipsec-outgoing; Wed, 26 Aug 1998 19:49:09 -0400 (EDT) From: "Catherine A. Meadows" Date: Wed, 26 Aug 1998 20:04:21 -0400 (EDT) Message-Id: <199808270004.UAA28220@liverwurst.itd.nrl.navy.mil> To: ipsec@tis.com Subject: question about IKE Quick Mode Cc: meadows@itd.nrl.navy.mil X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk I have been working on a formal analysis of IKE. As a result of the analysis I've found some rather odd behavior when client identifiers are not specified which conceivably could be used in a denial of service attack. In that case, according to draft-ietf-ipsec-isakmp-oakley-08.txt, the identities are implicitly assumed to be to be the IP addresses of the ISAKMP peers. However, a key in that case would be associated with *two* IP addresses, and it's not clear from the specification of the messages in IKE which one would be the originator of the message. This appears to allow for a situation in which an initiator B can be convinced that it has successfully completed a Quick Mode exchange with a responder A, while in fact an intruder has fooled it into completing a Quick Mode Exchange with itself. This is done by having B initiate a Quick Mode exchange with A. The intruder intercepts this message, and replays it back to B as A initiating a quick mode exchange with B. B as responder produces a message which the intruder sends to B as initiator as a message from the responder A, and so on, until at the end B is convinced that it shares a key with A when actually it is sharing a key with itself. What I'd like to know is: is there anything that I'm missing here? In particular, is there any information that could be sent in this exchange that I'm missing because it takes place at a lower level than the IKE specification? Or is this a situation that could actually occur, in at least some, if not all, implementations? Cathy Meadows Naval Research Laboratory From owner-ipsec Thu Aug 27 08:32:11 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA00339 for ipsec-outgoing; Thu, 27 Aug 1998 08:25:33 -0400 (EDT) From: Kai Martius Organization: Uniklinik TUD To: "Catherine A. Meadows" Date: Thu, 27 Aug 1998 11:53:59 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: question about IKE Quick Mode Reply-to: kai@imib.med.tu-dresden.de CC: ipsec@tis.com In-reply-to: <199808270004.UAA28220@liverwurst.itd.nrl.navy.mil> X-mailer: Pegasus Mail for Windows (v2.54) Message-ID: <89B1328260F@fltserv.imib.med.tu-dresden.de> Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, Cathy. > attack. In that > case, according to draft-ietf-ipsec-isakmp-oakley-08.txt, > the identities are implicitly assumed to be > to be the IP addresses of the ISAKMP peers. However, a key in that > case would be associated with *two* IP addresses, and it's not clear > from the specification of the messages in IKE which one would > be the originator of the message. This appears to allow Which key you mean here? In this state of IKE all keys are associated with SAs, for processing of phase II messages with the current IKE-SA, which itself is identified by IKE cookies. However, I see the issue you address. > for a situation in which an initiator B can be convinced that > it has successfully completed a Quick Mode exchange with a responder > A, while in fact an intruder has fooled it into completing > a Quick Mode Exchange with itself. > This is done by having B initiate a Quick Mode exchange with A. > The intruder intercepts this message, and replays it back to B > as A initiating a quick mode exchange with B. B as responder produces > a message which the intruder sends to B as initiator as a message from > the responder A, and so on, until at the end B is convinced that it > shares a key with A when actually it is sharing a key with itself. This is a very interesting attack, because A doesn't need to break any key, just need to "reflect" the message. But from my point of view, IKE is resistent against the passive form of this attack: The "magic number" is the message ID. For the first Quick Mode exchange initiated by B, it's M-ID, say is 1. If A simply reflects this message, B identifies the associated IKE-SA and realizes, that there is no finished quick mode exchange with A AND M-ID 1. I'm not shure, what the "standard behavior" of an IKE implementation is now; "Pluto", the GNU-IKE-daemon, increments it's associated M-ID, if there is no so-called "full state" (i.e. finished phase II) for A and the received M-ID. That is, phase II IV (and also HASH(1)) wouldn't match anymore and the message is ignored. The active form of this attack is more problematic, that is, A could modify the message; but therefore it must have SKEYID_a and SKEYID_e, at least. Because in that case, there are other, more serious attacks possible, I suppose, you don't mean this kind of attack. Regards, Kai # Kai Martius # # Dpt. of Medical CS and Biometrics / Dresden University of Technology # # PGP Fingerprint: to be compared after download of my key # # Key and more info (especially IP-security related) see my Homepage # # http://www.imib.med.tu-dresden.de/imib/personal/kai.html # From owner-ipsec Thu Aug 27 08:32:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA00340 for ipsec-outgoing; Thu, 27 Aug 1998 08:25:36 -0400 (EDT) From: Kai Martius Organization: Uniklinik TUD To: "Catherine A. Meadows" Date: Thu, 27 Aug 1998 12:22:59 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: question about IKE Quick Mode Reply-to: kai@imib.med.tu-dresden.de CC: ipsec@tis.com In-reply-to: <199808270004.UAA28220@liverwurst.itd.nrl.navy.mil> X-mailer: Pegasus Mail for Windows (v2.54) Message-ID: <89B8EE91BF8@fltserv.imib.med.tu-dresden.de> Sender: owner-ipsec@ex.tis.com Precedence: bulk Sorry, but to avoid confusion, when I said "A" in my previous message, I meant the evil intruder, not the honest "A"... Kai # Kai Martius # # Dpt. of Medical CS and Biometrics / Dresden University of Technology # # PGP Fingerprint: to be compared after download of my key # # Key and more info (especially IP-security related) see my Homepage # # http://www.imib.med.tu-dresden.de/imib/personal/kai.html # From owner-ipsec Fri Aug 28 11:13:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA05928 for ipsec-outgoing; Fri, 28 Aug 1998 11:07:11 -0400 (EDT) Message-Id: <199808272222.SAA00796@morden.sandelman.ottawa.on.ca> To: ipsec@tis.com cc: ipsec-errors@sandelman.ottawa.on.ca Subject: mailing list for IPsec errors task force Date: Thu, 27 Aug 1998 18:22:35 -0400 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk To subscribe, send email to majordomo@sandelman.ottawa.on.ca with the body: subscribe ipsec-errors or: subscribe ipsec-errors someaddress@some.where.nice SubCharter: Work to be finished by the end of September. [Last updated on: Thu Aug 27 18:38:52 1998] This is the mailing list for three task forces of the IPsec(ond) WG. 1. The IPsec ICMP task force is a sub-group of the IPsec(ond) WG. It is mandated to document uses of ICMP messages for error, diagnostics and normal operational use. The document will classify ICMP messages into messages which have a security impact to IPsec SAs and MUST be ignored. Messages which have no security impact, but no utility either and CAN be ignored. Messages which are necessary for normal operation, error reporting and for diagnostics and which must be processed. The method of processing will be described. 2. The IPsec SNMP task force is a sub-group of the IPsec(ond) WG. It is mandated to define an IPSec SNMP MIB. Its first product is to define IPSec SNMP MIBs for the use of system administrators. As such, the MIBs will include information about phase 1 and phase 2 SAs on a system. The information provided about each SA will include static information such as endpoints IDs, transform and expirations. It will also include dynamic information related to traffic and error counts, such as HMAC failures. Some traps will also be defined. The storage and secure transmission of IPSec MIBs is beyond the scope of this sub-group. The inclusion of diagnostic information such as keying material is beyond the scope of this MIB. However, future MIBs may include this information. 3. The IPsec IKE protocol error task force is a sub group of the IPsec(ond) WG. It is mandated to a) document the errors messages, reporting practices and error conditions in current IKE implementations which are caused by error conditions in the IKE protocol, b) reduce the list of error conditions to a common set, classify them and assign numeric codes, common text, response and explanation, and c) define a common format for the notification data where the response to an error condition is a NOTIFY message. ==== This mailing list restricts who may post to it. To post to the mailing list you must be a reader of it, or you must be subscribed to the special "ipsec-errors-nomail" list. This is done as a measure to reduce spam. The mailing list is archived at http://www.sandelman.ottawa.on.ca/ipsec-errors/ The general IPsec mailing list is at ipsec@tis.com (email to majordomo@tis.com), with archives at: ftp://ftp.tis.com/pub/lists/ipsec and searchable archives at: http://www.sandelman.ottawa.on.ca/ipsec/ From owner-ipsec Mon Aug 31 07:20:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA12593 for ipsec-outgoing; Mon, 31 Aug 1998 07:12:48 -0400 (EDT) Message-Id: <3.0.1.32.19980831163842.006b4660@172.16.1.10> X-Sender: nataraj@172.16.1.10 (Unverified) X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Mon, 31 Aug 1998 16:38:42 +0500 To: ipsec@tis.com From: Ramana Yarlagadda Subject: IDs clarification Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi , we need some help in the scenerio... (N1) (N2) H1|----------|sg1|---------------|sg2|------------|H2 ->| ESP tunnel |<- In this scenario I want to negotiate an IPSEC SA from

H1 is a host with in the trusted network of SG1 (N1). H2 is a host woth in the trusted network of SG2(N2) Between SG1 and SG2 it is ESP tunnel. We have some confusion regarding the ID payload information in phase 1 and 2. The understanding we have is the following : In phase 1 we send the IP address of SG1 as IDii (assuming H1 is the initiator and hence SG1) and IP address of SG2 as IDir. In phase 2, we send the actual source and destination - IP addresses of H1 and H2 (or perhaps other ID types corresponding to entities on H1 and H2) as IDci and IDcr respectively. Is this understanding correct? -thanks in advance -ramana * Ramana Yarlagadda * Rendezvous On Chip Pvt Ltd. * NewVasaviNagar, Kharkhana, * SECUNDERABAD - 500015. * INDIA * Tele Phone : (040) 7742606, 7740406 * Email : ramana@trinc.com * http://www.trinc.com ****************************************************************** From owner-ipsec Mon Aug 31 09:10:09 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA12986 for ipsec-outgoing; Mon, 31 Aug 1998 09:08:51 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199808311326.GAA11763@kc.livingston.com> Subject: Re: IDs clarification To: ramana@trinc.com (Ramana Yarlagadda) Date: Mon, 31 Aug 1998 06:26:27 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <3.0.1.32.19980831163842.006b4660@172.16.1.10> from "Ramana Yarlagadda" at Aug 31, 98 04:38:42 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Yes. cheers, suresh > > Hi , > > > we need some help in the scenerio... > > > (N1) (N2) > H1|----------|sg1|---------------|sg2|------------|H2 > ->| ESP tunnel |<- > > In this scenario I want to negotiate an IPSEC SA from

> H1 is a host with in the trusted network of SG1 (N1). > H2 is a host woth in the trusted network of SG2(N2) > Between SG1 and SG2 it is ESP tunnel. > > We have some confusion regarding the ID payload information in phase 1 and > 2. The understanding we have is the following : > > In phase 1 we send the IP address of SG1 as IDii (assuming H1 is the > initiator and hence SG1) and IP address of SG2 as IDir. In phase 2, we > send the actual source and destination - IP addresses of H1 and H2 (or > perhaps other ID types corresponding to entities on H1 and H2) as IDci and > IDcr respectively. > > Is this understanding correct? > > > -thanks in advance > -ramana > > * Ramana Yarlagadda > * Rendezvous On Chip Pvt Ltd. > * NewVasaviNagar, Kharkhana, > * SECUNDERABAD - 500015. > * INDIA > * Tele Phone : (040) 7742606, 7740406 > * Email : ramana@trinc.com > * http://www.trinc.com > ****************************************************************** > From owner-ipsec Mon Aug 31 10:21:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA13287 for ipsec-outgoing; Mon, 31 Aug 1998 10:16:54 -0400 (EDT) Message-Id: <199808311433.QAA18091@stax05.cubis.de> From: "Schaa, Tahar" To: "'IPsec Mailinglist'" Subject: Question about SA Date: Mon, 31 Aug 1998 16:33:54 +0200 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 Hello all here, I hope someone can help me. I'm wondering about the dependecies of SA's. -in the RFC 1825-28 there stands something like "SA is destination adress and SPI", but what adress ???? Is there meant IP adress with port number or without? -if it is only the IP without port what is about the following case: There is a server (with one IP adress) in the internet with two services: Realaudio Broadcast and Online Banking. Then I want to connect to both as a client, but for the Online Banking I want AH and ESP and for the Audio Broadcast only AH or perhaps nothing. The adress is always the same, there are only different ports. -I've got IPv4 and DHCP. The IP adress changes everytime I start my PC. Now its unpossible to identify my machine in a SA as communication partner with my IP adress. The same if I get dynamic IP adresses from my Provider. Is there something I did not read or is there still nothing about it??? Perhaps it would be a good sollution to let the client application select the SA or SPI? , because the application knows what strength of security is recommendet for the action that will be done. Sorry for my bad english, I'm from Germany. Thanks for answers. ________________________________________________________________________ _ T A H A R S C H A A tahar@tahar.ping.de schaa@secunet.de From owner-ipsec Mon Aug 31 10:57:54 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA13490 for ipsec-outgoing; Mon, 31 Aug 1998 10:55:57 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199808311433.QAA18091@stax05.cubis.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 31 Aug 1998 11:06:54 -0400 To: "Schaa, Tahar" From: Stephen Kent Subject: Re: Question about SA Cc: "'IPsec Mailinglist'" Sender: owner-ipsec@ex.tis.com Precedence: bulk Check the new IPsec architectrure document for clarification of these and other topics. The RFCs you cited are to be replaced very soon by the newly arrpoved set of IPsec I-Ds. Steve From owner-ipsec Mon Aug 31 16:56:12 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA14704 for ipsec-outgoing; Mon, 31 Aug 1998 16:50:10 -0400 (EDT) Message-ID: <35EB10D7.7AA8E07D@redcreek.com> Date: Mon, 31 Aug 1998 14:08:39 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.06 [en] (Win95; U) MIME-Version: 1.0 To: ipsec@tis.com Subject: IKE problem? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk At last week's IETF meeting(s) there were several references to "Tero's IKE problem", but I never heard the specifics on this. Can anyone fill me in on this?