From owner-ipsec Wed Apr 1 07:34:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA23277 for ipsec-outgoing; Wed, 1 Apr 1998 07:28:07 -0500 (EST) Date: Tue, 31 Mar 1998 23:36:11 -0500 (EST) From: Christian Huitema Message-Id: <980331233611.ZM14627@seawind.bellcore.com> In-Reply-To: "Steven M. Bellovin" "Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard" (Mar 30, 11:15pm) References: <199803310715.CAA15246@smb.research.att.com> X-Mailer: Z-Mail (5.0.0 30July97) To: "Steven M. Bellovin" , ablair@erols.com Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Cc: Bill Sommerfeld , iesg@ns.ietf.org, ipsec@tis.com, ietf@ns.ietf.org, tcp-over-satellite@achtung.sp.trw.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@ex.tis.com Precedence: bulk On Mar 30, 11:15pm, Steven M. Bellovin wrote: > Subject: Re: Last Call: Security Architecture for the Internet Protocol to > My understanding is that the TCP Over Satellite WG is considering the > use > of spoofing (at least as a research topic). I presume this means that > IPSec and spoofing to improve performance on a long latency satellite > network are incompatible. Is there any way to maintain security and > still do TCP spoofing for satellites (i.e., could you elaborate on the > evil)? > > You're right -- IPsec will not permit window-size spoofing. To understand > why, imagine that an enemy were to play games with window sizes -- > probably sending small ones, but just large enough to avoid tickling the > silly window syndrome code; slamming the window shut (remember that > closed windows are probed very infrequently); opening it wide and then > slamming it shut (against the spec, but is your stack robust enough > to cope?), etc. > > It's an interesting question how to have both good security and how > to play such TCP games. There are other issues between IPsec and > ECN; I spoke at that BoF today. By the way, it should be noted that the only rationale, if any, for TCP spoofing in the satellite relays is the inadequacy of the end-to-end TCP implementation. The specificities of satellites and their interaction with transport protocols have been known for more than 15 years, and the cure is also very well known: use large windows, use selective acknowledgments. The only slightly researchy subject is the possible use of pacing mechanisms to avoid the swings caused by large windows. TCP support both large windows and selective acknowledgements. A user that opts for end to end encryption will still get good performances over satellite links if they also select proper TCP implementations. -- Christian Huitema ---------- See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/ From owner-ipsec Wed Apr 1 07:34:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA23319 for ipsec-outgoing; Wed, 1 Apr 1998 07:31:07 -0500 (EST) Message-Id: <199804011146.DAA19132@dharkins-ss20.cisco.com> To: internet-drafts@ietf.org From: anvil@lounge.org Cc: ipsec@tis.com Subject: draft-ietf-ipsec-internet-key-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 01 Apr 1998 03:46:12 -0800 Sender: owner-ipsec@ex.tis.com Precedence: bulk Network Working Group Derrell Piper, The Electric Loft INTERNET-DRAFT Dan Harkins, The Industrial Lounge draft-ieft-ipsec-internet-key-00.txt April 1, 1998 The Pre-Shared Key for the Internet Protocol Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet Draft, please check the "1id-abstracts.txt" listing contained in the Internet Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Australia), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 0. Table Of Contents 1. Abstract 2. Discussion 3. Terms and Definitions 4. Pre-Shared Key Definition 5. Security Considerations 6. Acknowledgments 7. References 1. Abstract Recent efforts from the IPsec Working Group of the IETF in securing the Internet ([AH], [ARCH], [ESP], [ESPBLOW], [ESPCAST], [ESPCBC], [ESPNULL], [ESP3D], [DES], [DESMAC], [HMACMD5], [HMACSHA], [IKE], [DOI], [IPCOMP], [ISAKMP], and [OAKLEY]) imply the continued use of pre-shared keys. This document defines the Pre-Shared Key for the Internet. Piper, Harkins [Page 1] INTERNET DRAFT April 1, 1998 2. Discussion Pre-shared keys are normally used for interoperability purposes. The basic idea is that two parties sharing a common secret can communicate securely. This idea has been used since cryptography first sprung onto the scene. For a complete history of cryptography, see Wired magazine. An additional motivation is that pre-shared keys are, for the most part, unencumbered technology. (It's speculated that RSA Data Security, Inc. has made various claims relating to use of pre-shared keys, but these claims have not yet been tested in court). In order to validate security implementations it is necessary to agree on a pre-shared key in an out-of-band fashion. Such a technique is inherently problematic: the two parties must communicate and agree upon a key using a medium which is, itself, probably insecure. By standardizing on a Pre-Shared Key for the Internet, such communication is precluded. Additionally, the technique of pre-communication apriori to subsequent communication has obvious scaling problems. By standardizing on a cannonical Pre-Shared Key for the Internet, pre- shared keys now scale. Previous, non-standard attempts at agreeing on a pre-shared key were deficient in their use of standard English. For example, the ANX sponsored IPSec bakeoffs rather confusingly used both "whatcertificatereally" as well as the more accepted key, "gwock". By standardizing on Pidgin, the Pre-Shared Key for the Internet now sounds, like, most cool. In addition, one use of pre-shared key technology which has been discussed at length is that of secure multicast. By standardizing on a single pre-shared key, the need for a key distribution protocol is obviated. Of course the use of pre-shard keys for encrypting multicast traffic does not address issues such as content watermarking, threat models, or source authentication of multicast traffic (please see the Security Considerations below) and may therefore be unsatisfactory for some people. 3. Terms and Definitions Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [Bra97]. 4. Pre-Shared Key Definition Piper, Harkins [Page 2] INTERNET DRAFT April 1, 1998 All security implementations that include support for pre-shared keys MUST be capable of supporting the Pre-Shared Key for the Internet. The pre-shared key for the Internet is 14 octets in length. It is represented in ASCII as "mekmitasdigoat" without the accompanying quotation marks. In hexadecimal it is represented as: 0x6d656b6d697461736469676f6174. There MUST NOT be any additional termination characters (such as a terminating NULL). When used with [IKE], the pre-shared key for the Internet MUST be used directly for authentication of the Phase 1 exchange ([IKE], Section 5.4). When used with [ARCH], the manual key for the Internet may need to be expanded depending on the actual algorithmic requirements of the corresponding security association. Expansion of the key is performed by successive concatenation until the required length has been met or exceeded, but never both. Other used of pre-shared keys which require greater than 14 octets MUST expand the Pre-Shared Key for the Internet in the manner described above for use with [ARCH]. Other uses which require less than 14 octets MUST truncate the key to the required length. Other uses which require exactly 14 octets or have no limit to the length of a pre-shared key MUST use the Pre-Shared Key for the Internet in the manner described above for use with [IKE]. 5. Security Consideration The use of pre-shared keys has known security implications. When used for authentication, the presentation of a shared secret is proof of identity. When used for datagram authentication, the pre-shared key authenticates the content and source of the datagram. Using the Pre-Shared Key for the Internet will, in effect, allow you to authenticate everyone. One drawback is that this will negate the effects of all related security protocols. 6. Acknowledgments The authors would like to thank Roy Pereira, Steve Sneddon, William Dixon, Rob Adams, Perry Metzger, Bronislav Kavsan, and Ran Atkinson for their encouragement in writing this draft. 10. References [Bra97] Bradner, S., "Key Words for use in RFCs to indicate Requirement Levels", RFC-2119, March 1997. Piper, Harkins [Page 3] INTERNET DRAFT April 1, 1998 [ARCH] Kent, S., Atkinson, R., "Security Architecture for the Internet Protocol," draft-ietf-ipsec-arch-sec-04.txt. [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security Payload (ESP)," draft-ietf-ipsec-esp-v2-04.txt. [ESPBLOW] Adams, R., "The ESP Blowfish-CBC Algorithm Using an Explicit IV", draft-ietf-ipsec-ciph-blowfish-cbc-00.txt [ESPCAST] Pereira, R., G. Carter, "The ESP CAST128-CBC Algorithm", draft-ietf-ipsec-ciph-cast128-cbc-00.txt [ESPCBC] Pereira, R., Adams, R., "The ESP CBC-Mode Cipher Algorithms," draft-ietf-ipsec-ciph-cbc-02.txt. [ESPNULL] Glenn, R., Kent, S., "The NULL Encryption Algorithm and Its Use With IPsec," draft-ietf-ipsec-ciph-null-00.txt. [ESP3D] Pereira, R., R. Thayer, "The ESP 3DES-CBC Algorithm Using an Explicit IV", draft-ietf-ipsec-ciph-3des-expiv-00.txt [DES] Madson, C., Doraswamy, N., "The ESP DES-CBC Cipher Algorithm With Explicit IV," draft-ietf-ipsec-ciph-des-expiv-02.txt. [DESMAC] Bitan, S., "The Use of DES-MAC within ESP and AH," draft- bitan-auth-des-mac-00.txt. [DOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP," draft-ietf-ipsec-ipsec-doi-08.txt. [HMACMD5] Madson, C., Glenn, R., "The Use of HMAC-MD5 within ESP and AH," draft-ietf-ipsec-auth-hmac-md5-96-03.txt. [HMACSHA] Madson, C., Glenn, R., "The Use of HMAC-SHA-1-96 within ESP and AH," draft-ietf-ipsec-auth-hmac-sha196-03.txt. [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)," draft-ietf-ipsec-isakmp-oakley-06.txt. [IPCOMP] Shacham, A., Monsour, R., Pereira, R., Thomas, M., "IP Payload Compression Protocol (IPComp)," draft-ietf-ippcp- protocol- 05.txt. [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J., "Internet Security Association and Key Management Protocol (ISAKMP)," draft-ietf-ipsec-isakmp-09.{ps,txt}. [OAKLEY] H. K. Orman, "The OAKLEY Key Determination Protocol," draft- Piper, Harkins [Page 4] INTERNET DRAFT April 1, 1998 ietf-ipsec-oakley-02.txt. [X.501] ISO/IEC 9594-2, "Information Technology - Open Systems Interconnection - The Directory: Models", CCITT/ITU Recommendation X.501, 1993. [X.509] ISO/IEC 9594-8, "Information Technology - Open Systems Interconnection - The Directory: Authentication Framework", CCITT/ITU Recommendation X.509, 1993. Authors' Addresses: Derrell Piper The Electric Loft 41 6th Ave Santa Cruz, CA 95060 hobbit@yoyodyne.com Dan Harkins The Industrial Lounge anvil@lounge.org Piper, Harkins [Page 5] From owner-ipsec Wed Apr 1 12:35:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA25926 for ipsec-outgoing; Wed, 1 Apr 1998 12:32:19 -0500 (EST) Date: Wed, 1 Apr 1998 12:37:30 -0500 (EST) From: Eric Travis To: Christian Huitema cc: "Steven M. Bellovin" , ablair@erols.com, Bill Sommerfeld , iesg@ns.ietf.org, ipsec@tis.com, ietf@ns.ietf.org, tcp-over-satellite@achtung.sp.trw.com Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard In-Reply-To: <980331233611.ZM14627@seawind.bellcore.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Tue, 31 Mar 1998, Christian Huitema wrote: > By the way, it should be noted that the only rationale, if any, for > TCP spoofing in the satellite relays is the inadequacy of the end-to-end > TCP implementation. The specificities of satellites and their interaction > with transport protocols have been known for more than 15 years, and the > cure is also very well known: use large windows, use selective > acknowledgments. The only slightly researchy subject is the possible > use of pacing mechanisms to avoid the swings caused by large windows. > TCP support both large windows and selective acknowledgements. A user > that opts for end to end encryption will still get good performances > over satellite links if they also select proper TCP implementations. Actually, no... (!) For one thing, you are assuming that both ends of a transport connection are aware that they have a path including a long-delay path. Good assumption 15 years ago, bad today and in the future. Rather than rehash the problem space here, let me just say that BOTH sides of a TCP connection must use a "proper TCP implementation" when the path includes a satellite hop. For ad hoc connectivity this is a dicey proposition at best; Even if the anonymous ftp server at foo.bar.com was RFC-1323 capable, what makes anyone think it can offer appropriate windows for the available bw-delay product? Second, satellite links take far longer to recover from congestion than their terrestrial counterparts (it turns out to be an r**2 thing with the increase in ratios of relative delays in the path); There are many other little nits that make me disagree with the notion that the problems are "solved" already. Suffice it to say, my vision of future "last hop" connectivity to the Internet backbone is going to be more asymmetric and possibly dirty. For satellite users with long delays, short of upgrading every TCP implementation known on Earth (and flying above) and providing omniscient capabilities to the TCP implementations & applications as to proper socket buffer sizes something else needs be done for performance enhancement. Spoofing conjures up bad images - but there is great benefit to overall performance to splitting a connection. Spoofing/proxying is not just for long delay paths, but also for noisy environments (such as wireless/mobile). It has it's end-to-end downsides, but it's happening already and should be brought out of the closet - if for no other reason than to categorize the impacts (positive and negative) to the larger network. No need to debate it here, we can take it to tcp-over-satellite (exclusively) if you so desire. Regards, Eric From owner-ipsec Wed Apr 1 13:23:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA26329 for ipsec-outgoing; Wed, 1 Apr 1998 13:22:24 -0500 (EST) Date: Wed, 1 Apr 1998 10:33:51 -0800 (PST) Message-Id: <199804011833.KAA22522@servo.qualcomm.com> From: Phil Karn To: travis@clark.net CC: huitema@bellcore.com, smb@research.att.com, ablair@erols.com, sommerfeld@orchard.arlington.ma.us, iesg@ns.ietf.org, ipsec@tis.com, ietf@ns.ietf.org, tcp-over-satellite@achtung.sp.trw.com In-reply-to: (message from Eric Travis on Wed, 1 Apr 1998 12:37:30 -0500 (EST)) Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Sender: owner-ipsec@ex.tis.com Precedence: bulk The TCP-over-satellite group is misnamed. It should be called the TCP-over-large-bandwidth-delay-paths group. Many terrestrial paths now have bandwidth*delay products as large (or larger) than satellite paths. Cable modems are an increasingly important example. One very popular modem, the Motorola CyberSURFR, has a 27 Mb/s downstream path (limited to 10 Mb/s by the 10-Base-T interface) but only a 768 kb/s polled upstream path. Delays in the upstream direction are highly variable, frequently reaching several hundred milliseconds under evening load. (Contributing factors: other users doing large uploads and a cable company that's notably stingy about adding resources). Analyze a download over such a modem and you can see how large bandwidth*delay products are not confined to satellite paths. Worse, most of these cable modems support only one directly-connected host computer running the Windows 95 TCP/IP stack. This has spawned a minor cottage industry in programs to increase the TCP receive window size in the W95 system registry. But the W95 stack doesn't support window scaling, so 64K is the limit. The only solution to the problem is to get Microsoft to update their stack, as difficult as that may be. (Suggestions that the cable modems should silently proxy every TCP connection will be greeted with derisive silence.) --Phil From owner-ipsec Wed Apr 1 14:07:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA26701 for ipsec-outgoing; Wed, 1 Apr 1998 14:05:34 -0500 (EST) Date: Wed, 1 Apr 1998 14:10:43 -0500 (EST) From: Christian Huitema Message-Id: <980401141043.ZM15292@seawind.bellcore.com> In-Reply-To: Phil Karn "Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard" (Apr 1, 10:33am) References: <199804011833.KAA22522@servo.qualcomm.com> X-Mailer: Z-Mail (5.0.0 30July97) To: Phil Karn , travis@clark.net Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Cc: huitema@bellcore.com, smb@research.att.com, ablair@erols.com, sommerfeld@orchard.arlington.ma.us, iesg@ns.ietf.org, ipsec@tis.com, ietf@ns.ietf.org, tcp-over-satellite@achtung.sp.trw.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@ex.tis.com Precedence: bulk Phil, Yes, this really is a TCP problem. The classic objections to end to end solutions are: 1) Both systems need to be able to handle long windows. No question there; you will only go as fast as both ends allow. 2) Using long windows is harmful in some cases. This second objection is actually the root of the first one. If it is harmful in some cases, e.g. low speed modems, then it won't be deployed everywhere, and we will have to hack our ways through horrible proxying solutions. The two solutions that apply to TCp are the long window extensions and the selective acknowledge extensions. There is no question that using selective acknowledge result in better performance in all environments, including low speed links. I would thus expect that selective acks will be implemented everywhere in the near future (ping your favorite vendor). The problem that remain is thus the possible cost of using large windows. The arguments that I have collected so far are: 1) Per packet overhead is increased. Using large windows increases the likelihood of resuing the same sequence number, which implies a need for a timestamp option, and increases the overhead by about 6 bytes per packet. 2) The window option has to be negotiated at the beignning of the session, at a time when you don't know whether you will actually need it. 3) Using large windows allow the sender to send a shockwave of packets through the Internet, which can swamp intermediate routers. 4) Using large windows may lead to large buffer requirements. As Craig Partridge mentioned, the buffer requirement is red herring. In fact, the congestion control algorithm will reduce the window size to what is effectively needed. Implementors can then use proper local control to match buffer allocation to these needs. The three other problems could be addressed by a working group. There should be a way to switch in and out of large window mode within the life of a connection. One can easily imagine only sending time stamps when the number of packets in a window passes a threshold, which would fit a "use it only when you need it" requirement. One can also imagine a negotiation option when the receiver essentially opts for an "infinite" receive window if it has received the assurance that the sender uses a proper implementation of congestion control. One can devise a pacing option that obliges senders to abide by some rate limitation. These three points can in fact make it in the charter of a new "Better large window TCP" working group. -- Christian Huitema ---------- See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/ From owner-ipsec Wed Apr 1 15:50:48 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA27452 for ipsec-outgoing; Wed, 1 Apr 1998 15:48:39 -0500 (EST) Date: Wed, 1 Apr 1998 12:59:06 -0800 (PST) Message-Id: <199804012059.MAA23099@servo.qualcomm.com> From: Phil Karn To: huitema@bellcore.com CC: travis@clark.net, huitema@bellcore.com, smb@research.att.com, ablair@erols.com, sommerfeld@orchard.arlington.ma.us, iesg@ns.ietf.org, ipsec@tis.com, ietf@ns.ietf.org, tcp-over-satellite@achtung.sp.trw.com In-reply-to: <980401141043.ZM15292@seawind.bellcore.com> (message from Christian Huitema on Wed, 1 Apr 1998 14:10:43 -0500 (EST)) Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Sender: owner-ipsec@ex.tis.com Precedence: bulk I fully agree. TCP window advertisements are supposed to show how much buffer space the receiver has available. The receiver should not have to artificially limit its window because of network considerations -- that's the function of congestion control on the transmitting end. One problem we do have with the existing TCP congestion control mechanism is that the sender will increase its congestion window all the way up to the offered window as long as no packets are lost, even if all those extra packets just pile up in a queue at the bottleneck router. Various ad-hoc methods involving real-time bandwidth/delay measurements have been tried to solve this problem, but they don't seem to work really well because of measurement noise (competing traffic, route changes, etc). Signalling congestion by deliberately dropping packets when buffer space is still available has always bothered me. There has to be a better way. Besides, I'm of the opinion that there's just no alternative to having lots and lots of router buffering, especially on high speed/long delay links. If a TCP sends a packet into a bottlenecked path with generous link buffering, the worst that happens is that the packet waits in the queue for awhile. The link continues to pass traffic at full capacity. But if TCP timidly shrinks its congestion window to avoid packet drops in memory-starved routers, that increases the chance of the link going idle even when the TCPs have traffic to send. Idle link time is gone forever. Explicit congestion notification would help considerably. This doesn't necessarily require the definition of new bits in the IP and TCP headers; you can actually do quite a lot with the oft-maligned ICMP Source Quench message. I've found it quite effective in the common case of a host on a private leaf Ethernet sending data through a dialup router to the outside world. It certainly reacts more quickly than a mechanism that requires a far-end turnaround of the congestion bit. Phil From owner-ipsec Wed Apr 1 18:26:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA28591 for ipsec-outgoing; Wed, 1 Apr 1998 18:20:45 -0500 (EST) Message-ID: From: Greg Carter To: "'ipsec@tis.com'" Subject: draft-ietf-ipsec-spicy-manual-pki-00.txt Date: Wed, 1 Apr 1998 11:51:37 -0500 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 I was asked to post this... Network Working Group Geek Spice, Bitter Spice INTERNET-DRAFT SpiceWorld Systems draft-ietf-ipsec-spicy-manual-pki-00.txt April 1, 1998 The Simple Public Key Infrastructure And Certificate Exchange Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inapproporiate to use Internet Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Australia), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. This draft will expire six months prior to date of issue. 1. Abstract IPSEC mandates the use of manual keying for ESP and AH. However with the introduction of the scaleable key exchange mechanism, IKE [Hawkins98], it has become necessary to define a scaleable process to issue and manage certificates used by IPSEC devices during the IKE exchange. In keeping with the design goals of manual keying this document outlines a minimum set of requirements for IPSEC devices which wish to use X.509 certificates during IKE exchanges. However current 'state of the art' will be ignored, as well as any work done in other IETF working groups, specifically PKIX. Instead we will focus on 1993 technology, specifically PKCS#10. 2. Introduction Before an IPSEC device can acquire a certificate it must establish trust in the Certification Authority. To do this all IPSEC devices will hard code the root public key of a well known CA. We believe this to be a Veri, Veri good idea. This will enable implicit trust throughout the Internet, interoperability will be greatly improved, and users will not have to worry about things like where the points of trust are in their network. Roll over of the root key will take place in 4 year increments, with each update occurring in a leap year on the date of April 1. In order to make this transparent to end users, IPSEC vendors are required to release new versions of their OS's on theses dates. Embedded in the OS will be the root key. This way the roll over occurs without the knowledge of the end users and looks like any other OS update. Hence automated key roll over is supported. Root key compromise is not addressed in this document. Since IKE allows us to do away with manual keying at the IPSEC layer we have decided that the PKI used with IKE MUST support manual certificate management. We see this as the best solution, since we avoid the hassles of automated protocols and scaleable architectures, at the same time we can satisfy the needs of those who originally opted for manual keying infrastructures for IPSEC. They will be excited to know that they can continue to manually manage their public keys instead of their session keys. If an automated system were in place we would predict a 10% decrease in IT positions, now using manual public key infrastructures we expect an increase of 5%!. LDAP is not used, instead CRLs are moved by floppy to the IPSEC devices at 1 hour time intervals, key updates are not automated, instead the process outlined in this document is repeated. However this process maybe covered by patent. Unlike other IETF specification, this document does not specify any 'over the wire' protocol. Instead the manual process is considered to occur all out of band. The protocol maybe operated over transport protocols, however end to end integrity is not provided, since PKCS10 only specifies how to format a request, not how to securely transport that request to a CA (or how to establish trust in that CA). Although some have suggested that IPSEC be used to secure this transaction, we think this is an excellent idea! We can bootstrap IPSEC by using IPSEC! To summarize all IPSEC compliant CA's MUST support PKCS#10 requests received from IPSEC devices by some out of band means. All IPSEC devices MUST support a common root key so that a single point of trust is available throughout the Internet. However IPSEC devices MUST support multiple root keys, this has the excellent security feature of allowing end entities to pick and choose who they trust, instead of the trust being administered from a centrally managed entity (such as an organization's CA). This has many benefits in the corporate world where organizations are always looking for new ways to decentralize management of users. Acknowledgments Unfortunately much of this document was written without the knowledge of Bitter Spice. However it includes many of the design ideals originally expressed by Bitter Spice to me over shoots of tequila. Bitter Spice has moved on, with the recent conviction of the Montana Freedom Fighters Bitter has packed up his computer and arsenal of assault rifles and headed to foot hills of Montana to continue the fight. One of his first projects is to modify the existing Free SWAN code to support the SPICE protocol. Bitter Spice, the first crypto warrior! The slack is being picked up by Extranet Spice who has left his role as Marketing Technologist to work in the IETF standards group. Security Considerations This document specifies a means to obtain certificates, by definition there are not security considerations. Geek & Bitter Spice Expired 6 months Ago [Page 1] INTERNET DRAFT SPICE April 1, 1998 ---- Greg Carter, Entrust Technologies greg.carter@entrust.com From owner-ipsec Thu Apr 2 08:08:54 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA03740 for ipsec-outgoing; Thu, 2 Apr 1998 08:04:46 -0500 (EST) Message-ID: <35238DB2.83ABFA1A@ncs.com.sg> Date: Thu, 02 Apr 1998 21:08:02 +0800 From: Kok Leong X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 To: ipsec@tis.com Subject: Status of SKIP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, I am checking with u is the SKIP being dropped from the IETF draft? as I have not seen any update to the draft and they are not in the IETF list. Any advice? Regards KokLeong Low From owner-ipsec Fri Apr 3 07:56:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA13002 for ipsec-outgoing; Fri, 3 Apr 1998 07:49:03 -0500 (EST) Message-ID: <11622C999F23D111BA620000F8662EB7012F7F7F@zrchb152.us.nortel.com> From: "Spencer Dawkins" To: tcp-over-satellite@achtung.sp.trw.com Cc: ipsec@tis.com Subject: RE: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Date: Thu, 2 Apr 1998 20:23:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Gee, what a great opportunity to guess how TCP works in front of experts, but: I thought the problem with advertising windows that are "too large" is that (at least some) TCPs keep trying to probe unsuccessfully into the "too large" region. Doubling the number of segments every round trip does stop after the first few round trips, but I thought TCPs continued to increase the number of segments sent by one every round trip after that, until the sender starts missing ACKs. This allows TCPs to "speed up" when cross-traffic stops; when the FTP over (at least part of) your path stops, your TCP throughput will expand to fill the capacity left. I'm not questioning Peter's math, but it sure sounds like his TCP doesn't probe the way I thought TCPs do. And, on an related topic, I thought the problem with source quench was that IPsec hasn't been deployed in sufficient volume to prevent massive denial of service attacks (don't like someone? tell them to shut up). (and this is why I left IPsec on the cc: list) You can flame me in person tomorrow, if you're in LA... Spencer > ---------- > From: Peter Warren[SMTP:pwarren@gte.com] > Sent: Thursday, April 02, 1998 1:16 PM > To: Phil Karn > Cc: travis@clark.net; huitema@bellcore.com; smb@research.att.com; > ablair@EROLS.COM; sommerfeld@orchard.arlington.ma.us; ipsec@tis.com; > tcp-over-satellite@achtung.sp.trw.com > Subject: Re: Last Call: Security Architecture for the Internet > Protocol to Proposed Standard > > [Phil Karn wrote:] > >One problem we do have with the existing TCP congestion control > >mechanism is that the sender will increase its congestion window all > >the way up to the offered window as long as no packets are lost, even > >if all those extra packets just pile up in a queue at the bottleneck > >router. Various ad-hoc methods involving real-time bandwidth/delay > >measurements have been tried to solve this problem, but they don't > >seem to work really well because of measurement noise (competing > >traffic, route changes, etc). > > It seems to me that, since the sender uses incoming ACKs to clock out its > data packets, the rate of ACKs from the receiver will act as a break on > the > data steam, no matter how big the effective TCP window is. > > I have seen this in operation during a bulk transfer over an ADSL link > (1.5Mbps/64Kbps) where the receiver is set to advertize a 24KByte window > and the RTT is about 45 msec. In this case, the downstream ADSL modem > buffer is the bottleneck. (Here, the window is set wide enough to allow a > downstream rate of over 4Mbps, so the limiting factor is the downstream > ADSL link rate of 1.5Mbps). By looking at packet arrival times at the ADSL > modem vs. those at the receiver, I see that the downstream ADSL modem's > queue starts to fill up fairly quickly. However, at a certain point (one > second into the transfer), the increase stops, and the queue level drops > gradually at a constant rate until the end of the transfer. And I've > verified that *no* packets have been dropped, in either direction, and > there are no retransmissions nor duplicate ACKs. So the server did not > enter congestion avoidance nor slow-start at any point. I infer that it is > using the rate of returning ACKs to adjust its data rate. Am I overlooking > anything? > > If this is true, then it seems it would do no harm for the receiver to > advertize the largest window possible, by default, rather than the paultry > 8760 bytes we see commonly. I fully agree with Phil's comment: > > > The receiver should not have > >to artificially limit its window because of network considerations -- > >that's the function of congestion control on the transmitting end. From owner-ipsec Mon Apr 6 03:10:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA04678 for ipsec-outgoing; Mon, 6 Apr 1998 02:57:00 -0400 (EDT) Message-Id: <3.0.1.32.19980406124620.006b39e4@192.9.200.10> X-Sender: padma@192.9.200.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Mon, 06 Apr 1998 12:46:20 +0500 To: kent@bbn.com From: Padma Goli Subject: why single value destipaddress in SA selector Cc: ipsec@ex.tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, According to the Ipsec Architecture RFC, Destination address part of selectors can have single, range, wildcard in SPD but SA can have only single IP address. Why is it so? Why can't we have range or wildcard in SA dest ip address part of selectors as in SPD. We are implementing Manual Key Management MKM. For inbound policies, SAs have to be created before any packet matching a policy comes in. So, in MKM we are creating SAs for inbound policies at system startup. H2 / H1 ---- SG1 -- H3 \ H4 Consider an example wherein there are policies at H1 and SG1 saying host H1 can have ESP tunnel upto SG1 for any of the hosts beyond SG1. Assume SG1 is connected to H2, H3 and H4 on 192.9.100.0 subnet and SG1 address is 192.9.100.1 and H2 is 192.9.100.2, 100.3 for H3 and 100.4 for H4 So SPD policy selectors at SG1 would be Srcipaddr destipaddr H1 192.9.100.0 As SA selector destipaddress is only single value we are forced to create 3 SAs with selector destipaddress as 192.9.100.2 in one SA and 192.9.100.3 in second SA and 192.9.100.4 in third SA which seems to be an overkill. If wildcard or range was allowed, creation of one SA with selector destipaddress as 192.9.100.0 would Suffice with the outer IP header dest address set to the SG2 IP address. Thanking you in anticipation. Padma *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| *Padma Goli | *Rendzevous Onchip Pvt Ltd. | *First Floor, Plot No 14 | *New Vasavi Nagar, Karkhana | *Secunderbad -500019. | *Phone No : (040)7742606 | *email address : padma@trinc.com | *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| From owner-ipsec Mon Apr 6 19:40:07 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA11790 for ipsec-outgoing; Mon, 6 Apr 1998 19:36:49 -0400 (EDT) Message-ID: From: Roy Pereira To: "'Michael C. Richardson'" , "'ipsec@tis.com'" Subject: Summary of issues from RTP (third/IETF edition) Date: Mon, 6 Apr 1998 19:59:42 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Here are the interoperability issues as presented at IETF-LA. Most of these were from the ANX bakeoff as stated by Michael Richardson's email. Those items with (******), have added discussions. 1. ISAKMP SPI Sizes Some implementations got upset (i.e. crash) when offered different sizes of SPIs eg. 2 octets was required for IP Comp 2. Correctly Ordered Payloads For some vendors, ISAKMP payloads had to be in the order that they are documented. Most ISAKMP payloads may be sent in any order (except for the SA, Proposal and Transform payloads) 3. IP Addresses in Certificates Some people expected strings, other expected 4 octets in ipAddress "It is never a string when encoded in subjectAltName" 3. IP Addresses in certificates "... consensus was that if IP Addresses (or dns name or rfc822 name) were going to be added to an X.509 certificate then they should go into the subjectAltName extension (that is after all what it is for). This is consistent with work done in the PKIX WG" 4. No IP Address in Certificate An IP Address does not have to be within the certificate if the IPSec entity is mobile and uses a dynamic address But, there must be some other type of identity within the certificate (rfc822name, domain name, X.500 DN) 5. Replay of Zero (******) Some implementations were sending a replay prevention value of 0 when doing manually keying ****** This is incorrect behavior, since the replay prevention field must be incremented. ****** 6. AH & Auth Attribute Some vendors were not sending both the AH Transform type (e.g. AH_MD5) and the Authentication Algorithm attribute (e.g. HMAC-MD5) Some vendors would not accept receiving both the Transform type and the Authentication Algorithm attribute 7. New CertReq Format Some vendors were using the old isakmp-08 certificate request format 8. Hash in RSA Encryption Some vendors did not like getting a key hash payload in rsa encryption mode 9. Unknown Notify Payloads Some vendors were discarding entire ISAKMP packet when an unknown notify payload was received (ie. INITIAL-CONTACT) Only the single Notify payload should be discarded 10. Handling CertReq Some vendors did not like receiving certificate request payloads when using pre-shared keys The isakmp draft says certificate requests payloads can exist in any message Some vendors did not like receiving certificate request payloads at any time 11. Packet Padding (******) Some vendors did not like ISAKMP packets to be padded to a multiple of 4 byte. The ISAKMP draft states that the ISAKMP message MUST be 4-octet aligned ****** Actually, the draft is incorrect and will be modified. No alignment is required for ISAKMP messages ****** 12. IDui & Idur Some vendors expected to see client ID's in phase 2 (QuickMode), even though they are optional This caused QuickMode to complete, but fail to setup the correct SAs 13. IP4_ADDR_RANGE Some vendors do not accept a QuickMode ID type of IP4_ADDR_RANGE while they do accept IP4_ADDR and IP4_ADDR_SUBNET 14. Nonce Sizes Some vendors could not handle larger sized nonces (40 bytes) and would only allow 20 byte nonces The new IKE document does state: "The length of nonce payload MUST be between 8 and 256 bytes inclusive." 15. Overlapping SAs Some vendors did not support having a SA with the whole subnet at the same time as another SA with one host in that subnet 16. CONNECT Notify Message (******) Due to QuickMode's 1.5 exchanges, the initiator might not know that the responder did not receive the 3rd message One vendor suggested we should send a Notify CONNECT message for the responder's 2nd quickmode message ****** This is not necessary because of the COMMIT bit in the ISAKMP header. ****** From owner-ipsec Tue Apr 7 11:12:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA17819 for ipsec-outgoing; Tue, 7 Apr 1998 11:02:52 -0400 (EDT) Message-Id: <199804061349.JAA00250@morden.sandelman.ottawa.on.ca> To: ipsec@tis.com CC: Padma Goli Subject: Re: why single value destipaddress in SA selector In-reply-to: Your message of "Mon, 06 Apr 1998 12:46:20 +0500." <3.0.1.32.19980406124620.006b39e4@192.9.200.10> Date: Mon, 06 Apr 1998 09:49:46 -0400 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Padma" == Padma Goli writes: Padma> According to the Ipsec Architecture RFC, Destination Padma> address part of selectors can have single, range, wildcard Padma> in SPD but SA can have only single IP address. Why is it Padma> so? Why can't we have range or wildcard in SA dest ip You confusing the thing that determines what goes into a tunnel, and what the tunnel end points are. Padma> Consider an example wherein there are policies at H1 and Padma> SG1 saying host H1 can have ESP tunnel upto SG1 for any of Padma> the hosts beyond SG1. Assume SG1 is connected to H2, H3 Padma> and H4 on 192.9.100.0 subnet and SG1 address is 192.9.100.1 Padma> and H2 is 192.9.100.2, 100.3 for H3 and 100.4 for H4 Padma> So SPD policy selectors at SG1 would be Padma> Srcipaddr destipaddr H1 192.9.100.0 That isn't what I'd do. I'd make an SA: SRC=H1, DST=SG1, SPI= It would have an SPD: src=H1, DST=192.9.100.0/24 IMHO, I think you are suffering from overspecification in the architecture documents. Please read that document as a set of functional requirements, rather than a detailed design specification. ] Network Security Consulting and Contract Programming | SSH IPsec [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |international[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQBVAwUBNSjdcx4XQavxnHg9AQGwbQH/elaQ0U4Y8pt/UHzNp0felTxDLbzL4YPx vK1dNd5+BLAkMJj5F1UXWcptGWWu38w/TK6MRr/O1jf7mk3CA0sUaA== =0NMR -----END PGP SIGNATURE----- From owner-ipsec Tue Apr 7 11:29:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA18191 for ipsec-outgoing; Tue, 7 Apr 1998 11:26:53 -0400 (EDT) Message-Id: <199804071404.KAA28185@ns.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-internet-key-00.txt Date: Tue, 07 Apr 1998 10:04:45 -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 : The Pre-Shared Key for the Internet Protocol Author(s) : D. Piper, D. Harkins Filename : draft-ietf-ipsec-internet-key-00.txt Pages : 5 Date : 06-Apr-98 Recent efforts from the IPsec Working Group of the IETF in securing the Internet ([AH], [ARCH], [ESP], [ESPBLOW], [ESPCAST], [ESPCBC], [ESPNULL], [ESP3D], [DES], [DESMAC], [HMACMD5], [HMACSHA], [IKE], [DOI], [IPCOMP], [ISAKMP], and [OAKLEY]) imply the continued use of pre-shared keys. This document defines the Pre-Shared Key for the Internet. 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-internet-key-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-internet-key-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-internet-key-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: <19980406133407.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-internet-key-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-internet-key-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980406133407.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Apr 7 11:38:00 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA18254 for ipsec-outgoing; Tue, 7 Apr 1998 11:34:54 -0400 (EDT) Message-Id: <199804071548.LAA28855@relay.rv.tis.com> Date: Tue, 7 Apr 98 11:42:37 EDT From: Karen Seo To: padma@trinc.com cc: ipsec@tis.com Subject: Re: why single value destipaddress in SA selector Sender: owner-ipsec@ex.tis.com Precedence: bulk Padma, >>According to the Ipsec Architecture RFC, Destination address part of >>selectors can have single, range, wildcard in SPD but SA can have only >>single IP address. Why is it so? Why can't we have range or wildcard >>in SA dest ip address part of selectors as in SPD. You're right. We will change the 2nd entry in the table on page 21 from: Field Traffic Value SAD Entry SPD Entry -------- ------------- ---------------- -------------------- src addr single IP addr single,range,wild single,range,wildcard --> dst addr single IP addr single IP addr single,range,wildcard to: Field Traffic Value SAD Entry SPD Entry -------- ------------- ---------------- -------------------- src addr single IP addr single,range,wild single,range,wildcard --> dst addr single IP addr single,range,wild single,range,wildcard >>For inbound policies, SAs have to be created before any packet >>matching a policy comes in. So, in MKM we are creating SAs for inbound >>policies at system startup. >> H2 >> / >> H1 ---- SG1 -- H3 >> \ >> H4 >> >>Consider an example wherein there are policies at H1 and SG1 saying >>host H1 can have ESP tunnel upto SG1 for any of the hosts beyond SG1. >>Assume SG1 is connected to H2, H3 and H4 on 192.9.100.0 subnet and SG1 >>address is 192.9.100.1 and H2 is 192.9.100.2, 100.3 for H3 and 100.4 for >>H4 Just to be sure that I've addressed the question you're asking... There are 2 kinds of "Destination Address" referred to in this document when talking about SAs and the SAD. a) The Destination Address as "index to SAD" -- used by the receiver (along with SPI and IPsec protocol) to look up the SA to use for a given packet. If the SA is tunnel mode, then this Destination Address is the one in the outer header (not the inner IP header) and is the single value that refers to the the receiver. (There is no ambiguity if the SA is transport mode. *This* Destination Address is always a single value. b) The Destination Address as a "selector" -- [from page 22] "For the sender, these values are used to decide whether a given SA is appropriate for use with an outbound packet. This is part of checking to see if there is an existing SA that can be used. For the receiver, these values are used to check that the selector values in an inbound packet match those for the SA (and thus indirectly those for the matching policy)." This Destination Address could have the value single/range/wildcard. So looking at your example, suppose the IP address for H1 is 192.1.2.3 and the IP address of the SG1 interface facing towards H1 is 192.2.3.4. While the policy you describe is for traffic from H1 to H2/H3/H4, the SA you describe is from H1 to SG1. So in your example, the SA terminates at SG1. Therefore, if there were traffic flowing from H1 to one of the hosts, H2/H3/H4, then: a) at H1, - there is an outbound SPD entry saying that traffic from H1 to H2/H3/H4 must be protected by a tunnel to SG1. - there is an outbound SAD entry for an SA with a "selector" Destination Address for a range covering H2/H3/H4 b) at SG1, - there is an inbound SPD entry saying that traffic from H1 to H2/H3/H4 must be protected by a tunnel to SG1. - there is an inbound SAD entry for an SA with + an "index" Destination Address of 192.2.3.4, + a "selector" Destination Address for a range covering H2/H3/H4 If you had an additional policy requiring transport SAs from H1 to H2/H3/H4, then c) at H1, - there would be an outbound SPD entry requiring that traffic from H1 to H2/H3/H4 be protected by a transport SA to H2/H3/H4. (This is in addition to the SPD entry described in (a) above.) - there would be 3 separate outbound SAD entries - one w/ "selector" Dest. Addr. of H2 (192.9.100.2) - one w/ "selector" Dest. Addr. of H3 (192.9.100.3) - one w/ "selector" Dest. Addr. of H4 (192.9.100.4) d) at H2, - there'd be an inbound SPD entry requiring that traffic from H1 to H2 be protected by a transport SA - there'd be an inbound SAD entry for an SA with: + an "index" Destination Address of 192.9.100.2 + a "selector" Destination Address of 192.9.100;2 e) at H3, - there'd be an inbound SPD entry requiring that traffic from H1 to H3 be protected by a transport SA - there'd be an inbound SAD entry for an SA with: + an "index" Destination Address of 192.9.100.3 + a "selector" Destination Address of 192.9.100.3 f) at H4, - there'd be an inbound SPD entry requiring that traffic from H1 to H3 be protected by a transport SA - there'd be an inbound SAD entry for an SA with: + an "index" Destination Address of 192.9.100.4 + a "selector" Destination Address of 192.9.100.4 Karen From owner-ipsec Tue Apr 7 14:07:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA19589 for ipsec-outgoing; Tue, 7 Apr 1998 14:03:54 -0400 (EDT) Date: Tue, 7 Apr 1998 14:18:12 -0400 Message-Id: <199804071818.OAA00318@rsts-11.mit.edu> To: kllow@ncs.com.sg CC: ipsec@tis.com In-reply-to: <35238DB2.83ABFA1A@ncs.com.sg> (message from Kok Leong on Thu, 02 Apr 1998 21:08:02 +0800) Subject: Re: Status of SKIP From: tytso@MIT.EDU Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 References: <35238DB2.83ABFA1A@ncs.com.sg> Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Thu, 02 Apr 1998 21:08:02 +0800 From: Kok Leong Hi, I am checking with u is the SKIP being dropped from the IETF draft? as I have not seen any update to the draft and they are not in the IETF list. Any advice? The IPSEC working group reached the decision quite a while ago to pursue other approaches which was felt to be more scaleable and more flexible than SKIP. The key management protocol which was ultimately chosen, and which is currently in IETF Last Call in preparation for being moved forward on the IETF Standards Track as a Proposed Standard is IKE, previously known as ISAKMP/Oakley. - Ted From owner-ipsec Tue Apr 7 18:36:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA21512 for ipsec-outgoing; Tue, 7 Apr 1998 18:32:59 -0400 (EDT) Date: Tue, 7 Apr 1998 18:46:31 -0400 (EDT) From: "M.C.Nelson" To: "Scott G. Kelly" cc: Peter Ford , ipsec@tis.com Subject: Re: Last Call: Security Architecture for the Internet Protocol to In-Reply-To: <351C2432.CF89D5E3@redcreek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Fri, 27 Mar 1998, Scott G. Kelly wrote: > > IPSEC as currently spec'd is SSSSEEEECCCCUUURRRREEE. > Has this been established? It seems doubtful in view of (i) its complexity, and (ii) its explicit support for gateways and "trusted networks". Lets construct a set of ten targets and award a cash prize to the first ten hackers to break three of them. Regards, Mitch Nelson NetSec, Inc. From owner-ipsec Tue Apr 7 18:45:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA21619 for ipsec-outgoing; Tue, 7 Apr 1998 18:43:56 -0400 (EDT) Message-ID: <352AAFBC.B7593D5C@redcreek.com> Date: Tue, 07 Apr 1998 15:59:08 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: "M.C.Nelson" , ipsec@tis.com Subject: Re: Last Call: Security Architecture for the Internet Protocol to References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk M.C.Nelson wrote: > > On Fri, 27 Mar 1998, Scott G. Kelly wrote: > > > > IPSEC as currently spec'd is SSSSEEEECCCCUUURRRREEE. > > > Geez, I'll never live this one down :-( > Has this been established? It seems doubtful in view of > (i) its complexity, and (ii) its explicit support for gateways > and "trusted networks". On a more serious note, in terms of complexity, I don't think you can avoid it. Hackers are pretty sophisticated people (or at least, the ones capable of compromising your banking transactions are), and so complex measures are required. In terms of your second point, I'm not sure of what you're referring to here. What 'trusted networks'? And I think the 'explicit support for gateways' is a bit unclear as well: do you mean its support for tunnel endpoints which are different than the transaction endpoint? I guess I wouldn't want to get into the philosophical discussion surrounding the inappropriate nature of anything which gets in the way of end-to-end communications on the internet (at least, not on *this* mailing list), but these gateways *are* endpoints with respect to security. Scott From owner-ipsec Tue Apr 7 19:54:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA22115 for ipsec-outgoing; Tue, 7 Apr 1998 19:48:55 -0400 (EDT) Message-Id: <199804072356.TAA18797@postal.research.att.com> To: "M.C.Nelson" cc: "Scott G. Kelly" , Peter Ford , ipsec@tis.com Subject: Re: Last Call: Security Architecture for the Internet Protocol to Date: Tue, 07 Apr 1998 19:56:25 -0400 From: Steve Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk On Fri, 27 Mar 1998, Scott G. Kelly wrote: > > IPSEC as currently spec'd is SSSSEEEECCCCUUURRRREEE. > Has this been established? It seems doubtful in view of (i) its complexity, and (ii) its explicit support for gateways and "trusted networks". Lets construct a set of ten targets and award a cash prize to the first ten hackers to break three of them. The weaknesses that have been found thus far -- and the ones I fear in IKE -- have been in the cryptographic protocols. I've never yet seen a hacker attack one of those -- it's an arcane skill, and difficult for even the best cryptographers. However -- cryptography is not equivalent to security. An ipsec channel between a hacker and, say, an old version of sendmail will not protect you. From owner-ipsec Wed Apr 8 09:13:23 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA27219 for ipsec-outgoing; Wed, 8 Apr 1998 09:09:44 -0400 (EDT) Message-ID: <352AEAFC.167E@cs.umass.edu> Date: Tue, 07 Apr 1998 23:11:56 -0400 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V4.0 alpha) MIME-Version: 1.0 To: The IESG CC: IP Security List Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard References: <199803202008.PAA28002@ns.ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Regarding the Last Call on (aka IKE), two issues were raised last month that have yet to be addressed as far as I know. (I haven't received any replies to my suggestions on the IPSEC list of ways to deal with these issues.) [1] As Matt Thomas observed, IKE does not specify what action should be taken in the "original" Encryption Mode of authentication in the event that the ID payload exceeds the maximum data size for PKCS #1 encryption with the peer's public RSA key. Rather than attempt to specify a block chaining mechanism for RSA encryption, I proposed prohibiting the use of the "original" Encryption Mode whenever this situation arises. (See the first included message from IPSEC below.) Depending upon how individual implementations currently react to this situation, potential effects of the underspecification could vary between failures of interoperability and failures of the intended authentication guarantees. [2] Pau-Chen Cheng suggested that the original Encryption Mode in IKE may be vulnerable to the small RSA encryption exponent attacks due to Coppersmith et al. It appears that the encryption of very long ID payloads with very small exponents is vulnerable to such attacks. Rather than increasing the minimum padding size -- thus diverging from the PKCS #1 encryption block format -- I proposed prohibiting the use of RSA encryption exponents below a certain size in the original Encryption Mode. The lower limit on the exponent size depends on the size of the modulus in a simple way. (See the second included message from IPSEC below.) -- Lewis McCarthy --- begin included messages from the IPSEC list --- From owner-ipsec Fri Mar 20 21:05:05 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA03550 for ipsec-outgoing; Fri, 20 Mar 1998 21:04:51 -0500 (EST) Message-ID: <35132368.794B@cs.umass.edu> Date: Fri, 20 Mar 1998 21:18:16 -0500 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V4.0 alpha) MIME-Version: 1.0 To: matt@ljo.dec.com CC: IP Security List Subject: Re: new IKE draft References: <9803161550.AA26962@secpwr.watson.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Matt Thomas writes: >>> (Also what happens in the non-Revised mode if the identification payload is >>> larger than what can be encrypted via the RSA modulus?) Good question. How do existing implementations behave when this situation arises? I presume there are routine length checks in place to calculate the PKCS#1 padding length and avoid buffer overflows. Is the exchange aborted, are some bits of the ID payload ignored (bad), is the ID payload silently reduced mod N by the crypto engine before encryption (bad) ?? For encryption, PKCS #1 focuses on the common use of RSA to provide a "digital envelope" bearing a key for a conventional symmetric cipher. Secure RSA modulus and symmetric key sizes being what they are, the issue of plaintext that exceeds the block size just doesn't arise in that situation. I'm not aware of any standard that specifies the use of pure RSA for multi- block encryption, presumably in some CBC-like block chaining mode. I think the right way to fix this problem is to prohibit use of the "original" Authentication with Public Key Encryption method if RSA encryption is used and the length of the ID payload exceeds the data length limit specified in Section 8 of PKCS #1. If this condition is discovered after the method of 5.2 has been proposed (and maybe even accepted), the exchange must be aborted and a different authentication method negotiated. If only the responder encountered a length problem, then the initiator might propose use of Auth. with PK Encryption again. *sigh* I'm not sure whether there's a good Notify message type for the responder to send in this case. Maybe Invalid-Exchange-Type or Invalid-Key-Information? Comments? Incidentally, there doesn't seem to be a bibliographic reference in the draft for PKCS #1: [RSA93] RSA Laboratories, "PKCS #1: RSA Encryption Standard", version 1.5, RSA Data Security, Inc. Public-Key Cryptography Standards (PKCS), November 1993, ftp://ftp.rsa.com/pub/pkcs/ascii/pkcs-1.asc -Lewis "damn good...and very dangerous" --P.M. Netanyahu, of Ehud Tenebaum From owner-ipsec Sun Mar 29 23:29:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA29741 for ipsec-outgoing; Sun, 29 Mar 1998 23:24:45 -0500 (EST) Message-ID: <351F21C4.446B@cs.umass.edu> Date: Sun, 29 Mar 1998 23:38:28 -0500 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V4.0 alpha) MIME-Version: 1.0 To: IP Security List CC: pau@watson.ibm.com Subject: Re: new IKE draft References: <9803161550.AA26962@secpwr.watson.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Pau-Chen wrote on 16 Mar 1998: > Actually, for stronger securuty, I think the input to > RSA encryption should not be longer than 2/3 of the size of the modulus. Coppersmith's attack from Eurocrypt `96 imposes this security condition when the public exponent is e=3. As his paper notes, there are security tradeoffs between the amount (and location) of padding and the size of the public exponent. For some realistic modulus and public exponent sizes (e.g. e=3, |N| = 1024 bits), the minimum 64 bits of PKCS #1 padding isn't enough to prevent an attack when the adversary knows a good chunk of the plaintext. This means trouble for the encryption of long identities in the original PK Encryption Mode of authentication when the peer's public key has a very small e, and the adversary has a manageable set of identity guesses to check. One way to patch this hole would be to increase the minimum padding length. This would mean IKE would no longer be doing vanilla PKCS #1 encryption block formatting. An alternative is to impose a minimum size for the public exponent in RSA keys used with the original Encryption mode. The adversary's task is easiest when the ID payload is the longest allowed by PKCS #1 (i.e. k-11 octets in length) and the adversary knows all but a single bit of the ID payload. Thus only 65 bits of the input to encryption are unknown to the adversary. Conservatively the public exponent e should satisfy 65 >= n^(1/e), where n is the modulus. (This errs on the side of safety, since the padding and payload aren't contiguous in PKCS #1, and the padding isn't the most significant block of bits in the plaintext. But I think this is not too far off the mark.) For example, for n approximately 2^1024, the requirement would be e > 170. I mildly prefer the latter option. What does the WG think? I don't believe these attacks pose a threat to the encryption of nonces in the original and Revised PK Encryption Modes of authentication. Since the nonces are randomly generated, the adversary won't start with any partial information on the nonces. So there's no realistic foothold for a stereotyped message attack. Because the nonces are random and sufficiently large, the adversary essentially has no hope of finding groups of ciphertext susceptible to related message attacks. -- Lewis http://www.cs.umass.edu/~lmccarth/ --- end included messages from IPSEC list --- From owner-ipsec Wed Apr 8 09:13:23 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA27218 for ipsec-outgoing; Wed, 8 Apr 1998 09:09:43 -0400 (EDT) Message-Id: <199804080245.WAA20570@jekyll.piermont.com> To: "M.C.Nelson" cc: "Scott G. Kelly" , Peter Ford , ipsec@tis.com Subject: Re: Last Call: Security Architecture for the Internet Protocol to In-reply-to: Your message of "Tue, 07 Apr 1998 18:46:31 EDT." 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: Tue, 07 Apr 1998 22:45:05 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk "M.C.Nelson" writes: > > On Fri, 27 Mar 1998, Scott G. Kelly wrote: > > > > IPSEC as currently spec'd is SSSSEEEECCCCUUURRRREEE. > > Has this been established? It seems doubtful in view of > (i) its complexity, The basic protocol is highly simple. It encrypts and encapsulates a packet. Lots of niggling details show up, like "what does this do to the reported MTU of the link" and such, but I can explain IPSec's essense to people in a couple of minutes with reasonably high detail. > and (ii) its explicit support for gateways and "trusted networks". IPSec permits you to build VPNs. VPNs are naturally only as secure as the end networks, but the IPSec tunnels themselves are almost certainly going to be hard to break. Perry From owner-ipsec Wed Apr 8 23:19:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA04135 for ipsec-outgoing; Wed, 8 Apr 1998 23:14:58 -0400 (EDT) Date: Wed, 8 Apr 1998 23:29:14 -0400 (EDT) From: "M.C.Nelson" To: "Scott G. Kelly" cc: ipsec@tis.com Subject: Re: Last Call: Security Architecture for the Internet Protocol to In-Reply-To: <352AAFBC.B7593D5C@redcreek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Tue, 7 Apr 1998, Scott G. Kelly wrote: > > On a more serious note, in terms of complexity, I don't think you can > avoid it. Hackers are pretty sophisticated people (or at least, the ones > capable of compromising your banking transactions are), and so complex > measures are required. I'm afraid that I miss your logic here. One can thing of lots of counter examples. > > but these gateways *are* endpoints with respect to security. > ... and 68% - 80% of attacks are launched from the local part of the network. From owner-ipsec Wed Apr 8 23:24:09 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA04209 for ipsec-outgoing; Wed, 8 Apr 1998 23:23:58 -0400 (EDT) Date: Wed, 8 Apr 1998 23:37:18 -0400 (EDT) From: "M.C.Nelson" To: Steve Bellovin cc: "Scott G. Kelly" , Peter Ford , ipsec@tis.com Subject: Re: Last Call: Security Architecture for the Internet Protocol to In-Reply-To: <199804072356.TAA18797@postal.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, You yourself made the empirical connection between the quantity of code and likelihood of vulnerability, in your firewall book. I think your point there was well taken, and easily justified on simple statistical considerations. Regards, Mitch Nelson On Tue, 7 Apr 1998, Steve Bellovin wrote: > > On Fri, 27 Mar 1998, Scott G. Kelly wrote: > > > > IPSEC as currently spec'd is SSSSEEEECCCCUUURRRREEE. > > > > Has this been established? It seems doubtful in view of > (i) its complexity, and (ii) its explicit support for gateways > and "trusted networks". > > Lets construct a set of ten targets and award a cash prize to the > first ten hackers to break three of them. > > The weaknesses that have been found thus far -- and the ones I fear in > IKE -- have been in the cryptographic protocols. I've never yet seen > a hacker attack one of those -- it's an arcane skill, and difficult > for even the best cryptographers. > > However -- cryptography is not equivalent to security. An ipsec channel > between a hacker and, say, an old version of sendmail will not protect > you. > From owner-ipsec Wed Apr 8 23:30:07 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA04243 for ipsec-outgoing; Wed, 8 Apr 1998 23:29:58 -0400 (EDT) Date: Wed, 8 Apr 1998 23:43:45 -0400 (EDT) From: "M.C.Nelson" To: Steve Bellovin cc: "Scott G. Kelly" , Peter Ford , ipsec@tis.com Subject: Re: Last Call: Security Architecture for the Internet Protocol to In-Reply-To: <199804072356.TAA18797@postal.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk P.S. In any case, since the hoped for standards are to be mandatory, it seems a simple matter of public responsibility that they be subjected to a meaningful and practical test. This seems preferable to any attempt at proof by inspection. On Tue, 7 Apr 1998, Steve Bellovin wrote: > > On Fri, 27 Mar 1998, Scott G. Kelly wrote: > > > > IPSEC as currently spec'd is SSSSEEEECCCCUUURRRREEE. > > > > Has this been established? It seems doubtful in view of > (i) its complexity, and (ii) its explicit support for gateways > and "trusted networks". > > Lets construct a set of ten targets and award a cash prize to the > first ten hackers to break three of them. > > The weaknesses that have been found thus far -- and the ones I fear in > IKE -- have been in the cryptographic protocols. I've never yet seen > a hacker attack one of those -- it's an arcane skill, and difficult > for even the best cryptographers. > > However -- cryptography is not equivalent to security. An ipsec channel > between a hacker and, say, an old version of sendmail will not protect > you. > From owner-ipsec Wed Apr 8 23:47:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA04358 for ipsec-outgoing; Wed, 8 Apr 1998 23:46:58 -0400 (EDT) Date: Thu, 9 Apr 1998 00:00:09 -0400 (EDT) From: "M.C.Nelson" To: "Perry E. Metzger" cc: "Scott G. Kelly" , Peter Ford , ipsec@tis.com Subject: Re: Last Call: Security Architecture for the Internet Protocol to In-Reply-To: <199804080245.WAA20570@jekyll.piermont.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Perry, On Tue, 7 Apr 1998, Perry E. Metzger wrote: > > The basic protocol is highly simple. It encrypts and encapsulates a > packet. Lots of niggling details show up, like "what does this do to > the reported MTU of the link" and such, but I can explain IPSec's > essense to people in a couple of minutes with reasonably high detail. > The niggling details are no doubt, the source of a lot of the complexity. I agree with you that it should be a simple and short exercise to describe the simple task of encrypting IP datagrams. > IPSec permits you to build VPNs. VPNs are naturally only as secure as > the end networks, but the IPSec tunnels themselves are almost > certainly going to be hard to break. Most of the attacks occur on the local networks. Imagine a sniffer that copies itself from one network to another. The encryption tunnel that joins those networks is irrelevant to this scenario. In effect, the security of the second network is parameterized by the security decisions implemented on the first network. Regards, Mitch Nelson From owner-ipsec Thu Apr 9 00:55:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA04694 for ipsec-outgoing; Thu, 9 Apr 1998 00:53:56 -0400 (EDT) Date: Thu, 9 Apr 1998 01:08:13 -0400 From: Ran Canetti Message-Id: <9804090508.AA29328@ornavella.watson.ibm.com> To: iesg@ietf.org, lmccarth@cs.umass.edu Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Lewis McCarthy ... > I proposed prohibiting the use of the "original" Encryption Mode whenever > this situation arises. (See the first included message from IPSEC below.) ... > I proposed prohibiting the use of RSA encryption exponents below a certain > size in the original Encryption Mode. The lower limit on the exponent size > depends on the size of the modulus in a simple way. (See the second > included message from IPSEC below.) In fact, why not remove the original encryption mode from the IKE standard altogether (or, if you wish, make it "historic")? Recall that the revised mode does not suffer from the problems that Lewis points out (since there the RSA encryption encrypts only a key to some block cipher). Does anyone see an aspect in which the original mode is better than the revised? if not, and if the original mode may be problematic in some cases then why keep it? (also for sake of simplicity, size of code, the usual stuff.) Ran From owner-ipsec Thu Apr 9 01:08:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA04790 for ipsec-outgoing; Thu, 9 Apr 1998 01:07:58 -0400 (EDT) From: Jackie Wilson Message-Id: <199804090522.AAA35084@jhwilson.austin.ibm.com> Subject: ESP Pad byte changes To: ipsec@tis.com Date: Thu, 9 Apr 1998 00:22:13 -0500 (CDT) 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 I was wondering how many implementations are numbering the pad bytes and checking the values as indicated in the latest ESP draft. This seems to be a problem that if you check the values, you may not be able to interoperate with many ipsec implementations. I realize this is a 'should' issue, but this is a low-level detail I don't want to surface to the user to turn on or off. In addition, it is not an attribute that can be negotiated with ISAKMP/Oakley. Is checking the pad numbering strategic, do most implementers plan on doing it? Are most people making this a configurable option? If it's not being done now, are people planning on doing it soon (ie 1998)? If it is not important from a security standpoint to have it, then why is it in the draft? For all the noise made about freezing the drafts, I question the decision to add this in the last round of changes to ESP. Just wondering what others thought. Jackie -- Jacqueline Wilson | Phn: (512) 838-2702 IBM, AIX/6000 | Fax: (512) 838-3509 11400 Burnet Road ZIP 9551 | Ext: 8-2702 Tie-Line: 678 Austin, TX 78758-3493 | inet: jhwilson@austin.ibm.com From owner-ipsec Thu Apr 9 04:15:24 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA06153 for ipsec-outgoing; Thu, 9 Apr 1998 04:11:57 -0400 (EDT) Date: Thu, 9 Apr 1998 11:26:26 +0300 (EET DST) Message-Id: <199804090826.LAA13265@pilari.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Lewis McCarthy Cc: The IESG , IP Security List Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard In-Reply-To: <352AEAFC.167E@cs.umass.edu> References: <199803202008.PAA28002@ns.ietf.org> <352AEAFC.167E@cs.umass.edu> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 7 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Lewis McCarthy writes: > [1] As Matt Thomas observed, IKE does not specify what action should be taken > in the "original" Encryption Mode of authentication in the event that the > ID payload exceeds the maximum data size for PKCS #1 encryption with the > peer's public RSA key. Note, that also the revised RSA encryption mode of authentication has this problem. The nonce size can be up to 256 bytes so you need bigger than 2048+padding RSA bit key to encrypt that. I think in the revised rsa encryption mode we should just say that the nonce size used must be such that it can be encrypted using single rsa encryption operation. -- kivinen@iki.fi Work : +358-9-4354 3207 Magnus Enckellin kuja 9 K 19, 02610, Espoo Home : +358-9-502 1573 From owner-ipsec Thu Apr 9 06:18:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA06965 for ipsec-outgoing; Thu, 9 Apr 1998 06:16:57 -0400 (EDT) Message-Id: <199804091030.TAA02858@splpe610.ccs.mt.nec.co.jp> To: ipsec@tis.com Subject: public key cryptography on ISAKMP Date: Thu, 09 Apr 1998 19:30:39 +0900 From: Shigeyoshi SHIMA Sender: owner-ipsec@ex.tis.com Precedence: bulk I think of a new key exchange protocol which is based on ISAKMP. On ISAKMP, I want to use a the public key of RSA or Ellipic Curve Cryptosystem, instead of the Deffie-Hellman key exchange algorithm. I don't know whether using public key cryptography on ISAKMP or not in the sence of standard and patent. Please answer this question. Thanks and Regards. ----------------------------------- Shigeyoshi SHIMA shima@ccs.mt.nec.co.jp NEC C&C Software Development Group From owner-ipsec Thu Apr 9 06:59:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA07323 for ipsec-outgoing; Thu, 9 Apr 1998 06:57:56 -0400 (EDT) Message-Id: <199804091108.HAA25185@postal.research.att.com> To: "M.C.Nelson" cc: "Scott G. Kelly" , Peter Ford , ipsec@tis.com Subject: Re: Last Call: Security Architecture for the Internet Protocol to Date: Thu, 09 Apr 1998 07:08:42 -0400 From: Steve Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, You yourself made the empirical connection between the quantity of code and likelihood of vulnerability, in your firewall book. I think your point there was well taken, and easily justified on simple statistical considerations. Absolutely. But it's not just code per se, it's code complexity. Raw ipsec -- especially as one would see in an outboard encryptor -- is comparatively linear. isakmp worries me more, because of the number of complicated states. From owner-ipsec Thu Apr 9 07:36:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA07654 for ipsec-outgoing; Thu, 9 Apr 1998 07:33:48 -0400 (EDT) Date: Thu, 9 Apr 1998 14:44:48 +0300 (EET DST) Message-Id: <199804091144.OAA14625@pilari.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Ran Canetti Cc: iesg@ietf.org, lmccarth@cs.umass.edu, ipsec@tis.com Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard In-Reply-To: <9804090508.AA29328@ornavella.watson.ibm.com> References: <9804090508.AA29328@ornavella.watson.ibm.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 10 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Ran Canetti writes: > In fact, why not remove the original encryption mode from the > IKE standard altogether (or, if you wish, make it "historic")? I think it should stay in. > Recall that the revised mode does not suffer from the problems that Lewis > points out (since there the RSA encryption encrypts only a key to > some block cipher). Not true. You still have to limit the nonce size from the maximum of 256 bytes to such that it can be encrypted using the given key. > Does anyone see an aspect in which the original mode is better than the > revised? if not, and if the original mode may be problematic in some cases > then why keep it? (also for sake of simplicity, size of code, the > usual stuff.) The rsa encryption mode is much easier to implement [I have implemented the RSA encryption mode, but I haven't implemented the revised mode because it would require so much more stuff]. In the RSA encryptionmode I only need to do special prosessing for nonce and id payloads. In the revised rsa encryption mode I have to add special processing to all payloads that can exist in the last packet (ke, cert, cr, vendor id, nonce etc). -- kivinen@iki.fi Work : +358-9-4354 3207 Magnus Enckellin kuja 9 K 19, 02610, Espoo Home : +358-9-502 1573 From owner-ipsec Thu Apr 9 08:35:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA08123 for ipsec-outgoing; Thu, 9 Apr 1998 08:34:02 -0400 (EDT) From: hsw@columbia.sparta.com (Howard Weiss) Message-Id: <9804091213.AA12346@katahdin.columbia.sparta.com> Subject: Re: Last Call: Security Architecture for the Internet Protocol to To: netsec@panix.com (M.C.Nelson) Date: Thu, 9 Apr 1998 08:13:29 -0400 (EDT) Cc: smb@research.att.com, skelly@redcreek.com, peterf@microsoft.com, ipsec@tis.com In-Reply-To: from "M.C.Nelson" at Apr 8, 98 11:43:45 pm Organization: SPARTA Inc. (Secure Systems Engineering Division) Usmail: 9861 Broken Land Parkway, Suite 300, Columbia MD 21046 Phone: (410) 381-9400 x201 Fax: (410) 381-5559 X-Mailer: ELM [version 2.4PL24 PGP3 ALPHA] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > > > P.S. In any case, since the hoped for standards are to be mandatory, it > seems a simple matter of public responsibility that they be subjected to a > meaningful and practical test. This seems preferable to any attempt at > proof by inspection. There is absolutely no doubt that once the IPSEC technology is fielded, it *will* be *stress tested* ! Howie -- ___________________________________________________________________ | | |Howard Weiss phone (410) 381-9400 x201 | |SPARTA, Inc. (301) 621-8145 x201 (DC) | |9861 Broken Land Parkway fax: (410) 381-5559 | |Columbia, MD 21046 email: hsw@columbia.sparta.com | |___________________________________________________________________| From owner-ipsec Thu Apr 9 09:48:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA08806 for ipsec-outgoing; Thu, 9 Apr 1998 09:46:09 -0400 (EDT) Message-ID: From: Rob Tashjian To: Jackie Wilson , ipsec@tis.com Subject: RE: ESP Pad byte changes Date: Thu, 9 Apr 1998 06:59:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk VPNet implements both the pad fill and the pad check. We made the pad check a 'tunable' parameter for interoperability testing because when we first implemented it, we were unable to talk to anyone. For the production release it is non-tunable. At the Raleigh workshop, most people we tested with had implemented the pad fill. Generally, when we found someone who had not implemented the pad fill, it took them well under an hour to add it to their code. rwt > -----Original Message----- > From: Jackie Wilson [mailto:jhwilson@austin.ibm.com] > Sent: Wednesday, April 08, 1998 10:22 PM > To: ipsec@tis.com > Subject: ESP Pad byte changes > > > I was wondering how many implementations are numbering the > pad bytes and > checking the values as indicated in the latest ESP draft. > This seems to be a > problem that if you check the values, you may not be able to > interoperate with > many ipsec implementations. I realize this is a 'should' > issue, but this > is a low-level detail I don't want to surface to the user to > turn on or > off. In addition, it is not an attribute that can be negotiated with > ISAKMP/Oakley. Is checking the pad numbering strategic, do > most implementers > plan on doing it? Are most people making this a configurable > option? If it's > not being done now, are people planning on doing it soon (ie > 1998)? If it > is not important from a security standpoint to have it, then > why is it in > the draft? > > For all the noise made about freezing the drafts, I question > the decision > to add this in the last round of changes to ESP. > > Just wondering what others thought. > > Jackie > -- > Jacqueline Wilson | Phn: (512) 838-2702 > IBM, AIX/6000 | Fax: (512) 838-3509 > 11400 Burnet Road ZIP 9551 | Ext: 8-2702 Tie-Line: 678 > Austin, TX 78758-3493 | inet: jhwilson@austin.ibm.com > From owner-ipsec Thu Apr 9 10:16:51 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA09132 for ipsec-outgoing; Thu, 9 Apr 1998 10:16:01 -0400 (EDT) Message-ID: <8D8EF175E72CD111805800805F3198EE03925D67@red-msg-46.dns.microsoft.com> From: Peter Ford To: "'iesg@ietf.org'" Cc: "'ipsec@tis.com'" Subject: Last Call for IPSEC Date: Thu, 9 Apr 1998 07:30:30 -0700 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: owner-ipsec@ex.tis.com Precedence: bulk IESG members, My recommendation to the IESG is to pass all BUT the IPSEC Architecture document to PS as requested by the working group(I am including AH in this). This allows all vendors to claim IETF proposed standards compliance with their products. The architecture document should follow when experience with IPSEC fleshes out and can catch up in the standards process at the time for movement to Draft standard. The ISAKMP documents will need to be changed to address peer recovery - see below. My understanding is that you will all be sitting down to discuss the last call for IPSEC in the immediate future. I am asking you to consider the issues I have raised with the collection protocols proposed to date. To recap: 1) AH is technically flawed (and not needed for IPv4, and it is dubious in the context of IPv6), 2) the system (IPSEC + ISAKMP) as it is currently defined is not sufficiently robust in light of failure of a peer (the net result is that people will have to crank their Security Association timers down to a ridiculous interval), and 3) calling anything the Internet Key Exchange (IKE) should not happen since there are many Internet Key Exchanges going on in the Internet today and several are being standardized by Internet working groups(e.g TLS). IPSEC is a critical and important set of standards and it should be done well, the first time. The collection of standards and the "MUSTS" in the IPSEC Architecture document make the minimal standards compliant implementation very large. For example: AH+ESP, tunnel+transport modes, DES+NULL+3DES, SHA+MD-5, Manual+Certs, result in way to many options mandated for managing the system in the Architecture doc. My concern here is that the value of the standard will be deprecated when vendors building small minimal implementations will elect to subset from this long list. If I were to build the Internet toaster I would not build in everything mandated (MUSTs) in the current collection of drafts you are reviewing (When Peter Ford is using the word I in this piece of email, Peter Ford is talking from a personal perspective, not that of the Microsoft Corporation). The working group process to date has been turbulent but relatively fair. I thank the chairs and the Area director for the opportunity to raise and discuss my concerns at the LA IETF. The outcome of those discussions was to move the documents forward as is. The dominant reason expressed: 1) we have working interoperable implementations of AH, 2) the working group has already discussed AH and its flaws, but several people felt it is a MUST for IPv6, most people agree that it is not useful for IPv4, 3) that if we deliberate further IPSEC will be delayed and the market will be delayed as a result. 1) is not a reason for standardization, it is a requirement for standardization. 2) is a sorry state to be in due to the coupling of IPv4 and IPv6 in several standards (a mistake ...) 3) the market demand for IPSEC is high and most vendors in the room are already selling something they label as IPSEC compliant in some manner. The issue of peer recovery was not addressed in the working group since the topic was not put on the agenda by the working group chairs. This needs to be addressed. Host vendor implementations should address this issue prior to deployment (I know of one implementation in beta that does not do this and the vendor is sorry about it). It is critical to get the standards document process for IPSEC kicked off. Thus my recommendation at the top of this note is a measured approach that should meet the needs of vendors, implementators and the market in general. Some might be surprised I am recommending standardization of AH. The standards are meant to guide implementations so we get Interoperability between implementations. AH should be built in an interoperable manner. Having a standard for AH is all well and good. Cynics in the audience recommended to me that I should simply ignore the process and implement whatever is needed: "that is what everyone else will do". My desire is to get the documents fixed. I hope others share my optimism in making the standards process result in good standards. One reason we have rules of governance in societies to provide measured and proper oversight. with regards, Peter S. Ford - peterf@microsoft.com From owner-ipsec Thu Apr 9 10:25:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA09194 for ipsec-outgoing; Thu, 9 Apr 1998 10:24:01 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C014AE00E@wade.reo.dec.com> From: Stephen Waters To: ipsec@tis.com Cc: Mark.Gillott@digital.com, Stephen Waters , Tom Kiely Subject: a simple question, I hope. Why do we need tunnel mode? Date: Thu, 9 Apr 1998 11:51:58 +0100 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk I have read most of the IPSEC drafts now, and I am still not sure why there is this distinction between 'tunnel mode' and 'transport mode'. If you consider life before IPSEC, to connect two routers over a foreign network requires some 'encapsulation'. If that foreign network is the Internet, the encapsulation required is an IP header. If you are connecting sections of your Intranet together, this IP encapsulation constitutes and IP-IP 'tunnel'. Assuming your IP tunnel is in place, the IP forwarding function in a router perceives these IP-in-IP packets as sourced datagrams and then applies 'transport mode' security to protect the packet (if required by the SPD). Is there room for breaking-out the tunnel requirement here? If I want a router to support L2TP-over-IP and IP-IP tunnels, and I want both to be secure, why can't I just use 'transport mode' security to do that? So, could IPSEC always be node-to-node/transport-mode - even if the node is a router. I could see no protocol difference in the AH draft for not doing this. On this topic, I'd like to use ESP and AH on the exchanges between my routers and the architecture does not support that for 'tunnel mode' (in the version I looked at any way). If I treat everything as transport-mode as a true IPSEC BITS/BITL, I could do that. One vote for untangling tunneling from IPSEC. What is probably missing is a decent IP tunnel draft, to cover multi-protocol for in a standard way! Cheers, Steve. From owner-ipsec Thu Apr 9 10:46:48 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA09342 for ipsec-outgoing; Thu, 9 Apr 1998 10:46:01 -0400 (EDT) Message-ID: <001c01bd63c7$d4687860$5b2c13ce@bmonsour.mtg.ietf.org> Reply-To: "Bob Monsour" From: "Bob Monsour" To: "Jackie Wilson" , Subject: Re: ESP Pad byte changes Date: Thu, 9 Apr 1998 07:57:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@ex.tis.com Precedence: bulk In the interest of 'being strict on what we send and liberal on what we accept/receive', we are sending the incrementing pad values according to the spec, but not checking them on receipt. As long as you know the right number of pad bytes to process, I don't see the value in checking contents; after all they *pad* bytes. -Bob -----Original Message----- From: Jackie Wilson To: ipsec@tis.com Date: Wednesday, April 08, 1998 10:38 PM Subject: ESP Pad byte changes >I was wondering how many implementations are numbering the pad bytes and >checking the values as indicated in the latest ESP draft. This seems to be a >problem that if you check the values, you may not be able to interoperate with >many ipsec implementations. I realize this is a 'should' issue, but this >is a low-level detail I don't want to surface to the user to turn on or >off. In addition, it is not an attribute that can be negotiated with >ISAKMP/Oakley. Is checking the pad numbering strategic, do most implementers >plan on doing it? Are most people making this a configurable option? If it's >not being done now, are people planning on doing it soon (ie 1998)? If it >is not important from a security standpoint to have it, then why is it in >the draft? > >For all the noise made about freezing the drafts, I question the decision >to add this in the last round of changes to ESP. > >Just wondering what others thought. > >Jackie >-- >Jacqueline Wilson | Phn: (512) 838-2702 >IBM, AIX/6000 | Fax: (512) 838-3509 >11400 Burnet Road ZIP 9551 | Ext: 8-2702 Tie-Line: 678 >Austin, TX 78758-3493 | inet: jhwilson@austin.ibm.com > > From owner-ipsec Thu Apr 9 12:00:06 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA09976 for ipsec-outgoing; Thu, 9 Apr 1998 11:58:05 -0400 (EDT) To: Stephen Waters Cc: ipsec@tis.com, Mark.Gillott@digital.com, Tom Kiely Subject: Re: a simple question, I hope. Why do we need tunnel mode? References: <250F9C8DEB9ED011A14D08002BE4F64C014AE00E@wade.reo.dec.com> From: Ben Rogers Date: 09 Apr 1998 12:12:13 -0400 In-Reply-To: Stephen Waters's message of Thu, 9 Apr 1998 11:51:58 +0100 Message-ID: Lines: 60 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen Waters writes: > > I have read most of the IPSEC drafts now, and I am still not sure why > there is this distinction between 'tunnel mode' and 'transport mode'. > > If you consider life before IPSEC, to connect two routers over a > foreign network requires some 'encapsulation'. If that foreign network > is the Internet, the encapsulation required is an IP header. If you > are connecting sections of your Intranet together, this IP > encapsulation constitutes and IP-IP 'tunnel'. > > Assuming your IP tunnel is in place, the IP forwarding function in a > router perceives these IP-in-IP packets as sourced datagrams and then > applies 'transport mode' security to protect the packet (if required by > the SPD). > > Is there room for breaking-out the tunnel requirement here? If I want a > router to support L2TP-over-IP and IP-IP tunnels, and I want both to be > secure, why can't I just use 'transport mode' security to do that? > > So, could IPSEC always be node-to-node/transport-mode - even if the node > is a router. > > I could see no protocol difference in the AH draft for not doing this. > > On this topic, I'd like to use ESP and AH on the exchanges between my > routers and the architecture does not support that for 'tunnel mode' (in > the version I looked at any way). If I treat everything as > transport-mode as a true IPSEC BITS/BITL, I could do that. It doesn't explicitly support it, because the case you describe is not using the precise language. You would apply ESP in tunnel mode, then looking at the packet, you no longer have an object which begins with two IP headers, so you could only apply AH in transport mode: IP Data IP ESP IP Data (apply ESP in tunnel mode) IP AH ESP IP Data (apply AH in transport mode) This is what I do in my implementation. ISAKMP can be used to negotiate this by negotiating a pair of SA's in a single Quick Mode exchange: the first an AH with an Encapsulation Mode attribute of transport, the second an ESP with an Encapsulation Mode attribute of tunnel. I suggested this to the list a while ago and didn't meet any criticism, but didn't seem to have elicited changes to the documents. Since language describing such a situation doesn't exist in the DOI, I'd suggest that anyone interested in implementing this encapsulation technique use the ISAKMP negotiation I've outlined above. > One vote for untangling tunneling from IPSEC. What is probably missing > is a decent IP tunnel draft, to cover multi-protocol for in a standard > way! I'd like to see the same. I really don't see any necessity to re-define IP-in-IP encapsulation (a reason I still prefer RFC1825). ben From owner-ipsec Thu Apr 9 12:11:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA10095 for ipsec-outgoing; Thu, 9 Apr 1998 12:11:04 -0400 (EDT) To: iesg@ietf.org Cc: ipsec@tis.com Subject: IPsec re-defining IP-in-IP? From: Ben Rogers Date: 09 Apr 1998 12:24:41 -0400 Message-ID: Lines: 22 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-ipsec@ex.tis.com Precedence: bulk I am a bit concerned as to the redefinition of IP-in-IP tunneling within the proposed IPsec architecture document. One of the reasons RFC1825 was able to remain much smaller and simpler than the current document was that it seems to have been content leaving tunneling to the folks working on tunneling, while security was handled by the folks working on security. As such, I see no need to more or less duplicate the information in RFC2003. I would suggest that an explicit description of what to do with IP protocol 4 ought to be defined in only one location. We (the IPsec WG) need it to provide a tunneling capability. MobileIP needs it to satisfy some very funtamental needs in their protocol. There is no reason that we cannot share the same document. If we don't then we run the risk of not knowing what to do within an IP stack in the event that the two documents diverge. We might end up making the interpretation of IP protocol 4 context dependent, the "IPsec protocol 4" used whenever our parsing engine finds a protocol 4 in an AH or ESP, and the "RFC2003 protocol 4" in all other cases. ben From owner-ipsec Thu Apr 9 12:54:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA10506 for ipsec-outgoing; Thu, 9 Apr 1998 12:53:04 -0400 (EDT) From: Pyda Srisuresh Message-Id: <199804091658.JAA11472@server.livingston.com> Subject: Re: a simple question, I hope. Why do we need tunnel mode? To: Stephen.Waters@digital.com (Stephen Waters) Date: Thu, 9 Apr 1998 10:02:58 -0700 (PDT) Cc: ipsec@tis.com, Mark.Gillott@digital.com, Stephen.Waters@digital.com, kiely@marvin.reo.dec.com In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C014AE00E@wade.reo.dec.com> from "Stephen Waters" at Apr 9, 98 11:51:58 am Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk My thinking similar. IP-in-IP mode of transport is a solution to get around enterprise firewall scrutiny. However, IPSec is not limited to this type of transport alone. Specifically, L2TP tunnels are equally good candidates for IPSec in the remote access realm of security solutions. So, I dont see a need to categorize "IP-in-IP Tunnel Mode" as a distinct type of security. Transport mode security does cover the Ip-in-IP tunnel mode, as a special case. cheers, suresh > > > I have read most of the IPSEC drafts now, and I am still not sure why > there is this distinction between 'tunnel mode' and 'transport mode'. > > If you consider life before IPSEC, to connect two routers over a > foreign network requires some 'encapsulation'. If that foreign network > is the Internet, the encapsulation required is an IP header. If you > are connecting sections of your Intranet together, this IP > encapsulation constitutes and IP-IP 'tunnel'. > > Assuming your IP tunnel is in place, the IP forwarding function in a > router perceives these IP-in-IP packets as sourced datagrams and then > applies 'transport mode' security to protect the packet (if required by > the SPD). > > Is there room for breaking-out the tunnel requirement here? If I want a > router to support L2TP-over-IP and IP-IP tunnels, and I want both to be > secure, why can't I just use 'transport mode' security to do that? > > So, could IPSEC always be node-to-node/transport-mode - even if the node > is a router. > > I could see no protocol difference in the AH draft for not doing this. > > On this topic, I'd like to use ESP and AH on the exchanges between my > routers and the architecture does not support that for 'tunnel mode' (in > the version I looked at any way). If I treat everything as > transport-mode as a true IPSEC BITS/BITL, I could do that. > > One vote for untangling tunneling from IPSEC. What is probably missing > is a decent IP tunnel draft, to cover multi-protocol for in a standard > way! > > Cheers, Steve. > From owner-ipsec Thu Apr 9 13:16:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA10721 for ipsec-outgoing; Thu, 9 Apr 1998 13:15:10 -0400 (EDT) Message-Id: <199804091727.NAA26525@jekyll.piermont.com> To: Peter Ford cc: "'iesg@ietf.org'" , "'ipsec@tis.com'" Subject: Re: Last Call for IPSEC In-reply-to: Your message of "Thu, 09 Apr 1998 07:30:30 PDT." <8D8EF175E72CD111805800805F3198EE03925D67@red-msg-46.dns.microsoft.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, 09 Apr 1998 13:27:09 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Peter Ford writes: > My recommendation to the IESG is to pass all BUT the IPSEC Architecture > document to PS as requested by the working group(I am including AH in this). > This allows all vendors to claim IETF proposed standards compliance with > their products. The architecture document should follow when experience > with IPSEC fleshes out and can catch up in the standards process at the time > for movement to Draft standard. The reason the IETF has "Proposed Standard" status, which then only slowly moves on to "Draft Standard" and then "Standard", is so that people can get time and experience with things. We've already held up these documents for five years. What possible purpose could there be to adding additional delay over that already imposed by the standards process itself? > The collection of standards and the "MUSTS" in the IPSEC Architecture > document make the minimal standards compliant implementation very large. > For example: AH+ESP, tunnel+transport modes, DES+NULL+3DES, SHA+MD-5, > Manual+Certs, result in way to many options mandated for managing the system > in the Architecture doc. This simply isn't true. There are several implementations out there already, and they aren't huge. (ISAKMP is another matter, but the IPSEC layer itself isn't that big). Perry From owner-ipsec Thu Apr 9 13:19:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA10740 for ipsec-outgoing; Thu, 9 Apr 1998 13:19:06 -0400 (EDT) Message-Id: <3.0.1.32.19980409125017.006aa198@192.9.200.10> X-Sender: srinu@192.9.200.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Thu, 09 Apr 1998 12:50:17 +0500 To: kent@bbn.com From: K SrinivasRao Subject: What is meant by routing header ? Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, With respect to the draft-ietf-ipsec-arch-sec-04.txt section 5.1.2.1 IPv4 -- Header Construction for Tunnel Mode protocol AH, ESP, routing hdr no change The protocol field of the outer is filled with AH or ESP depending on the SA that has been selected. But the SA can have IPsec protocol as either AH/ESP. I didn't get where the concept of routing will come in picture. Can any one clarify how we will conctruct the outer header *protocol* field. And where does the concept of routing header will come in picture. Note that this is in IPv4. Thank U SrinivasRao. B. Kulkarni Rendezvous On Chip Pvt Ltd. First Floor, Plot No. 14, NewVasaviNagar, Kharkhana, SECUNDERABAD - 500019. Ph : (040)7742606 email address : srinu@trinc.com From owner-ipsec Thu Apr 9 13:54:38 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA11094 for ipsec-outgoing; Thu, 9 Apr 1998 13:54:07 -0400 (EDT) Message-ID: <352D0EE2.40C06C64@redcreek.com> Date: Thu, 09 Apr 1998 11:09:38 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Jackie Wilson , ipsec@tis.com Subject: Re: ESP Pad byte changes References: <199804090522.AAA35084@jhwilson.austin.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Jackie Wilson wrote: > > if it > is not important from a security standpoint to have it, then why is it in > the draft? One argument for using this mechanism is that filling the pad bytes with a predictable value prevents filling them with other things, i.e. leaking information. I'm not personally arguing for or against, just making an observation. From owner-ipsec Thu Apr 9 14:10:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA11197 for ipsec-outgoing; Thu, 9 Apr 1998 14:10:06 -0400 (EDT) Message-ID: <352D1160.446B@cs.umass.edu> Date: Thu, 09 Apr 1998 14:20:16 -0400 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V4.0 alpha) MIME-Version: 1.0 To: Peter Ford CC: iesg@ietf.org, ipsec@tis.com Subject: Re: Last Call for IPSEC References: <8D8EF175E72CD111805800805F3198EE03925D67@red-msg-46.dns.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Peter Ford writes: > 3) calling anything the Internet > Key Exchange (IKE) should not happen since there are many Internet Key > Exchanges going on in the Internet today and several are being standardized > by Internet working groups(e.g TLS). Until now I didn't realize you were raising this as a serious objection. To my ear, calling the key exchange for the "Internet Protocol" the "Internet Key Exchange" makes the terminology nicely consistent. It might be said that nothing should be called the "Internet Protocol" since there are many (Internet) Protocols going on in the Internet today and several have been standardized (e.g. TCP). But the Internet goes everywhere IP is laid down; hopefully a baseline of Internet security will go everywhere IPSEC is laid down. I don't see a reason to rename IKE. -- Lewis, who wasn't involved in choosing the name "IKE" From owner-ipsec Thu Apr 9 14:32:48 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA11378 for ipsec-outgoing; Thu, 9 Apr 1998 14:31:06 -0400 (EDT) Message-ID: <0171F2F8F9E5D011A4D10060B03CFB440CAF1C@scc-server3.semaphorecom.com> From: CJ Gibson To: ipsec@tis.com, ipsec@ns.ncsa.com Cc: margaret , prashant Subject: FW: Key Recovery Date: Thu, 9 Apr 1998 12:00:03 -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 Can anybody out there help us with this issue of Key Recovery ?? Have any of you decided to implement this ?? Thanks in advance, CJ -----Original Message----- From: CJ Gibson [SMTP:cjgibson@semaphorecom.com] Sent: Thursday, April 09, 1998 11:52 AM To: Margaret Gaynes Cc: cj; Roger Wang Subject: RE: Key Recovery Reply at bottom of note.. -----Original Message----- From: Margaret Gaynes [SMTP:mgaynes@semaphorecom.com] Sent: Thursday, April 09, 1998 11:11 AM To: CJ Cc: Roger Wang Subject: Key Recovery By the end of the year we have to implement Key Recovery using the TIS RecoverKey tool kit. The way it works is that each encrypted packet has a Key Recovery Field (KRF) that travels with the encrypted data. It is the session key and recovery info encrypted with the public RSA key of the Key Recovery Center (KRC). If the key needs to be recovered, it can only be done with the private key of the KRC. You have to prove to the KRC with a subpoena or whatever that you are entitled to the data. For FR and SMDS adding this data to the packet is no problem because we control the packet contents. However, how does this fit in with IPSEC and IKE? Is there an IKE option that says "TIS key recovery" packet format? Not that I know of. I'll send this out on the IPSEC list to see what others are doing... --CJ From owner-ipsec Thu Apr 9 15:01:49 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA11618 for ipsec-outgoing; Thu, 9 Apr 1998 15:01:06 -0400 (EDT) Message-ID: <012401bd63eb$7f7859a0$5b2c13ce@bmonsour.mtg.ietf.org> Reply-To: "Bob Monsour" From: "Bob Monsour" To: "Scott G. Kelly" , "Jackie Wilson" , Subject: Re: ESP Pad byte changes Date: Thu, 9 Apr 1998 12:12:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@ex.tis.com Precedence: bulk >Jackie Wilson wrote: [snip] >One argument for using this mechanism is that filling the pad bytes with >a predictable value prevents filling them with other things, i.e. >leaking information. I'm not personally arguing for or against, just >making an observation. > I would concur that it's the generation with unleaked data that's important and not the checking. -Bob From owner-ipsec Thu Apr 9 15:06:15 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA11676 for ipsec-outgoing; Thu, 9 Apr 1998 15:06:07 -0400 (EDT) Message-Id: <3.0.3.32.19980409151641.0383c3dc@pop.pn.com> X-PGP-Key: X-Sender: rodney@pop.pn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 09 Apr 1998 15:16:41 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: Re: ESP Pad byte changes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk It was put in to allow detection of decryption failures. >Date: Thu, 09 Apr 1998 11:09:38 -0700 >From: "Scott G. Kelly" >Organization: RedCreek Communications >X-Mailer: Mozilla 4.04 [en] (Win95; I) >To: Jackie Wilson , ipsec@tis.com >Subject: Re: ESP Pad byte changes >Sender: owner-ipsec@ex.tis.com > >Jackie Wilson wrote: > >> >> if it >> is not important from a security standpoint to have it, then why is it in >> the draft? > >One argument for using this mechanism is that filling the pad bytes with >a predictable value prevents filling them with other things, i.e. >leaking information. I'm not personally arguing for or against, just >making an observation. > > > From owner-ipsec Thu Apr 9 15:06:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA11675 for ipsec-outgoing; Thu, 9 Apr 1998 15:06:07 -0400 (EDT) Message-Id: <3.0.3.32.19980409151508.037ca344@pop.pn.com> X-PGP-Key: X-Sender: rodney@pop.pn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 09 Apr 1998 15:15:08 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: [ipsec] FW: Key Recovery Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk IETF protocols (like IKE) tend to not support technologies such as key recovery. That is "the Danvers Doctrine". >From: CJ Gibson >To: ipsec@tis.com, ipsec@ns.ncsa.com >Cc: margaret , > prashant > >Subject: [ipsec] FW: Key Recovery >Date: Thu, 9 Apr 1998 12:00:03 -0700 >X-Mailer: Internet Mail Service (5.0.1458.49) >Sender: owner-ipsec@ns.ncsa.com > >Can anybody out there help us with this issue of Key Recovery ?? Have >any of you decided to implement this ?? >Thanks in advance, > CJ > >-----Original Message----- >From: CJ Gibson [SMTP:cjgibson@semaphorecom.com] >Sent: Thursday, April 09, 1998 11:52 AM >To: Margaret Gaynes >Cc: cj; Roger Wang >Subject: RE: Key Recovery > >Reply at bottom of note.. > -----Original Message----- > From: Margaret Gaynes [SMTP:mgaynes@semaphorecom.com] > Sent: Thursday, April 09, 1998 11:11 AM > To: CJ > Cc: Roger Wang > Subject: Key Recovery > >By the end of the year we have to implement Key Recovery using >the TIS >RecoverKey tool kit. The way it works is that each encrypted >packet has >a Key Recovery Field (KRF) that travels with the encrypted data. >It is >the session key and recovery info encrypted with the public RSA >key of >the Key Recovery Center (KRC). If the key needs to be recovered, >it can >only be done with the private key of the KRC. You have to prove >to the >KRC with a subpoena or whatever that you are entitled to the data. >For FR and SMDS adding this data to the packet is no problem >because we >control the packet contents. However, how does this fit in with >IPSEC >and IKE? >Is there an IKE option that says "TIS key recovery" packet format? > > > >Not that I know of. I'll send this out on the IPSEC list to see what >others are doing... >--CJ > > From owner-ipsec Thu Apr 9 15:17:32 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA11842 for ipsec-outgoing; Thu, 9 Apr 1998 15:17:04 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C014AE00E@wade.reo.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 9 Apr 1998 14:27:56 -0400 To: Stephen Waters From: Stephen Kent Subject: Re: a simple question, I hope. Why do we need tunnel mode? Cc: ipsec@tis.com, Mark.Gillott@digital.com, Stephen Waters , Tom Kiely Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, If an SA is tunnel mode, it has an interior IP header which is checked against the selectors associated with that SA, whereas the outer IP header is discarded. If an SA is transport mode, the outer IP header is checked against these selectors and is not discarded. Thus the two modes impose different processing requirements on received traffic. It is a security requirement that a receiver be able top tell what processing is expected of each packet received on an SA. If one transports other than IP in an IPsec environment, there is still a requirement to use tunnel mode and to have an inner IP header, above which one might employ a GRE header to encapsulate the foreign protocol. We have not specified how non-IP traffic is to be handled, but what I described would be consistent with the architectrure as it stands. Steve From owner-ipsec Thu Apr 9 15:49:48 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA12087 for ipsec-outgoing; Thu, 9 Apr 1998 15:48:06 -0400 (EDT) Date: Thu, 9 Apr 1998 16:01:16 -0400 Message-Id: <9804092001.AA10012@kona.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: skelly@redcreek.com Cc: jhwilson@austin.ibm.com, ipsec@tis.com Subject: Re: ESP Pad byte changes References: <199804090522.AAA35084@jhwilson.austin.ibm.com> <352D0EE2.40C06C64@redcreek.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Scott" == Scott G Kelly writes: Scott> Jackie Wilson wrote: >> if it is not important from a security standpoint to have it, >> then why is it in the draft? Scott> One argument for using this mechanism is that filling the pad Scott> bytes with a predictable value prevents filling them with Scott> other things, i.e. leaking information. I'm not personally Scott> arguing for or against, just making an observation. That's an excellent argument for requiring the sending of some specified value. But I sure am puzzled about why there's a requirement (or even a suggestion) that it be checked on receive. Unless I'm missing something, the only thing that's necessary for packet parsing is that you have to be able to tell the length of the pad. The only additional property needed for security is that the pad must not be someone else's data. The current pad pattern certainly does both of these. Lots of other pad count plus pad data rules would work just as well -- e.g., pad data = constant byte N (any N), or random, or pseudorandom. But since the current pattern works, I wouldn't want to argue for changing it. On the other hand, I would like to know why the rule is that you MUST (rather than MAY) check the pad on receive. paul From owner-ipsec Thu Apr 9 16:16:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA12352 for ipsec-outgoing; Thu, 9 Apr 1998 16:16:06 -0400 (EDT) Message-ID: <352D2FF9.C3530302@redcreek.com> Date: Thu, 09 Apr 1998 13:30:49 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Lewis McCarthy CC: Peter Ford , iesg@ietf.org, ipsec@tis.com Subject: Re: Last Call for IPSEC References: <8D8EF175E72CD111805800805F3198EE03925D67@red-msg-46.dns.microsoft.com> <352D1160.446B@cs.umass.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Lewis McCarthy wrote: > > Peter Ford writes: > > 3) calling anything the Internet > > Key Exchange (IKE) should not happen since there are many Internet Key > > Exchanges going on in the Internet today and several are being standardized > > by Internet working groups(e.g TLS). > > Until now I didn't realize you were raising this as a serious objection. > To my ear, calling the key exchange for the "Internet Protocol" the "Internet > Key Exchange" makes the terminology nicely consistent. ...and therein lies the flaw: it is not 'the' key exhange for IP, it's 'a' key exchange, of which there are many others. The initial assessment (in my view) is correct: IKE is too broad, and perhaps even misleading. This nibbles around the corners of a larger problem which I'm surprised no one has mentioned. ISAKMP is the base protocol within which key exchange takes place. However, it is NOT strictly a key-exchange protocol. In fact, it is primarily a SA management protocol, of which key exchange is one component. The point is, ISAKMP is the protocol here, not IKE. ISAKMP is designed to accept key-exchange plug-ins. This makes ISAKMP a well-designed protocol, in that if we find flaws with the key-exchange component, it may be replaced without designing an entirely new protocol. This seems quite reasonable to anticipate, given the relative dearth of practical operating experience in this frontier. The IKE document proposes an instantiation of a key-exchange plug-in, and describes (for purposes of clarity) the entire conglomeration of the plug-in and the base component in one document, and there now seems to be this general notion that this is the new ISAKMP, and that (the old) ISAKMP is now irrelevant. What happens if we find a flaw with the key exchange portion of the conglomerate? What do we call the next iteration (if there is one)? The 'Better Internet Key Exchange'?? The 'Second Internet Key Exchange'? I would suggest that the title of the document convey the actual document contents. It was called 'The resolution of ISAKMP with Oakley'. Perhaps it should be called something like 'The Oakley Key Exchange for ISAKMP', which more accurately describes it than the current title. From owner-ipsec Thu Apr 9 16:36:19 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA12616 for ipsec-outgoing; Thu, 9 Apr 1998 16:35:05 -0400 (EDT) Message-Id: <199804092048.QAA12575@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com CC: CJ Gibson Reply-To: nobody@sandelman.ottawa.on.ca Subject: Re: FW: Key Recovery In-reply-to: Your message of "Thu, 09 Apr 1998 12:00:03 PDT." <0171F2F8F9E5D011A4D10060B03CFB440CAF1C@scc-server3.semaphorecom.com> Date: Thu, 09 Apr 1998 16:48:33 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- CJ: Non-realtime of recovery of bulk/symmetric session keys has no law enforcement value according to many. It also requires hugh amounts stable (i.e. subpoenable), secure storage. If some law enforcement agency wants real time access to symmetric keys, then they can define the protocols to do that securely, and if there is a market (or they legislate one), I suppose that some vendors will produce compliant products. Their protocol would presumably also apply to S/MIME, PGP, SSL and SSH, so we in the IPsec world would be smart to let them design the protocol. The law enforcement agencies will need clear legislation defining (probably limiting) their liability. The RSA keys used in IKE are used for signature purposes only. Escrow of them results in a mistrial when used for law enforcement purposes because the defendant can prove that the law enforcement agency could have fabricated the evidence. ("Entrapment") Access to escrowed signature keys does not directly result in recover of symmetric session keys, only disclosure of identities. To recover session keys, an active, man-in-the-middle attack must be done. Further, escrow of RSA signing keys is already a feature in many PKI offerings, and outside of the scope of both IPsec and IKE. If people could *PLEASE* tell whatever NARCs work at their respective organizations to get a clue. The IETF and IPsec WG position on this has been made clear on numerous occasions. If you don't like that, take it to the IAB directly. Don't even bother this WG. [Greping for "escrow" on my achives: http://www.sandelman.ottawa.on.ca/ipsec/1994/03/msg00005.html http://www.sandelman.ottawa.on.ca/ipsec/1995/02/msg00042.html http://www.sandelman.ottawa.on.ca/ipsec/1995/07/msg00016.html http://www.sandelman.ottawa.on.ca/ipsec/1995/12/msg00077.html http://www.sandelman.ottawa.on.ca/ipsec/1996/07/msg00046.html Also: 1996/08/msg00000.html 1996/08/msg00005.html 1996/08/msg00018.html 1996/08/msg00110.html 1996/08/msg00111.html 1996/08/msg00126.html 1996/08/msg00128.html 1996/08/msg00129.html 1996/08/msg00130.html 1996/08/msg00131.html 1996/08/msg00137.html 1996/09/msg00000.html 1996/09/msg00057.html 1996/10/msg00050.html 1996/10/msg00058.html 1997/09/msg00121.html 1998/02/msg00266.html 1998/02/msg00311.html 1998/02/msg00333.html :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON Michael Richardson | SSH IPsec: http://www.ssh.fi/. Secure, strong, international Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNS00G9iXVu0RiA21AQEDzgMAicMggqJHa+ABMj5XS2Vrfe2/JKTCcjXT B8SsE/cA483EGO8Dgb/o7Jg3VNCcWwz8aCDBA7K127BYtT0VIpx42DJEvf3XBYUB BqjxtdYkxSyfrdx3p4OJzsVdaFU60OZ2 =XP6o -----END PGP SIGNATURE----- From owner-ipsec Thu Apr 9 17:02:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA12824 for ipsec-outgoing; Thu, 9 Apr 1998 17:01:05 -0400 (EDT) Message-ID: <0171F2F8F9E5D011A4D10060B03CFB440CAF2E@scc-server3.semaphorecom.com> From: CJ Gibson To: ipsec@tis.com, ipsec@ns.ncsa.com Subject: RE: FW: Key Recovery - nevermind! Date: Thu, 9 Apr 1998 14:29:21 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk As Rosanne Rosannadana would say 'Nevermind" and I apologize for upsetting anyone ! -----Original Message----- From: Michael C. Richardson [SMTP:mcr@sandelman.ottawa.on.ca] Sent: Thursday, April 09, 1998 1:49 PM To: ipsec@tis.com Cc: CJ Gibson Subject: Re: FW: Key Recovery -----BEGIN PGP SIGNED MESSAGE----- CJ: Non-realtime of recovery of bulk/symmetric session keys has no law enforcement value according to many. It also requires hugh amounts stable (i.e. subpoenable), secure storage. If some law enforcement agency wants real time access to symmetric keys, then they can define the protocols to do that securely, and if there is a market (or they legislate one), I suppose that some vendors will produce compliant products. Their protocol would presumably also apply to S/MIME, PGP, SSL and SSH, so we in the IPsec world would be smart to let them design the protocol. The law enforcement agencies will need clear legislation defining (probably limiting) their liability. The RSA keys used in IKE are used for signature purposes only. Escrow of them results in a mistrial when used for law enforcement purposes because the defendant can prove that the law enforcement agency could have fabricated the evidence. ("Entrapment") Access to escrowed signature keys does not directly result in recover of symmetric session keys, only disclosure of identities. To recover session keys, an active, man-in-the-middle attack must be done. Further, escrow of RSA signing keys is already a feature in many PKI offerings, and outside of the scope of both IPsec and IKE. If people could *PLEASE* tell whatever NARCs work at their respective organizations to get a clue. The IETF and IPsec WG position on this has been made clear on numerous occasions. If you don't like that, take it to the IAB directly. Don't even bother this WG. [Greping for "escrow" on my achives: http://www.sandelman.ottawa.on.ca/ipsec/1994/03/msg00005.html http://www.sandelman.ottawa.on.ca/ipsec/1995/02/msg00042.html http://www.sandelman.ottawa.on.ca/ipsec/1995/07/msg00016.html http://www.sandelman.ottawa.on.ca/ipsec/1995/12/msg00077.html http://www.sandelman.ottawa.on.ca/ipsec/1996/07/msg00046.html Also: 1996/08/msg00000.html 1996/08/msg00005.html 1996/08/msg00018.html 1996/08/msg00110.html 1996/08/msg00111.html 1996/08/msg00126.html 1996/08/msg00128.html 1996/08/msg00129.html 1996/08/msg00130.html 1996/08/msg00131.html 1996/08/msg00137.html 1996/09/msg00000.html 1996/09/msg00057.html 1996/10/msg00050.html 1996/10/msg00058.html 1997/09/msg00121.html 1998/02/msg00266.html 1998/02/msg00311.html 1998/02/msg00333.html :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON Michael Richardson | SSH IPsec: http://www.ssh.fi/. Secure, strong, international Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on. ca. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNS00G9iXVu0RiA21AQEDzgMAicMggqJHa+ABMj5XS2Vrfe2/JKTCcjXT B8SsE/cA483EGO8Dgb/o7Jg3VNCcWwz8aCDBA7K127BYtT0VIpx42DJEvf3XBYUB BqjxtdYkxSyfrdx3p4OJzsVdaFU60OZ2 =XP6o -----END PGP SIGNATURE----- From owner-ipsec Thu Apr 9 17:27:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA13017 for ipsec-outgoing; Thu, 9 Apr 1998 17:27:10 -0400 (EDT) Message-ID: <013b01bd63ff$e0b042a0$5b2c13ce@bmonsour.mtg.ietf.org> Reply-To: "Bob Monsour" From: "Bob Monsour" To: "Paul Koning" , Cc: , Subject: Re: ESP Pad byte changes Date: Thu, 9 Apr 1998 14:38:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@ex.tis.com Precedence: bulk Paul, the requirement is as follows, per the latest ESP draft. "The first padding byte appended to the plaintext is numbered 1, with subsequent padding bytes making up a monotonically increasing sequence: 1, 2, 3, ... When this padding scheme is employed, the receiver SHOULD inspect the Padding." It's merely a SHOULD, not a MUST. Regards, -Bob field. -----Original Message----- From: Paul Koning To: skelly@redcreek.com Cc: jhwilson@austin.ibm.com ; ipsec@tis.com Date: Thursday, April 09, 1998 1:25 PM Subject: Re: ESP Pad byte changes >>>>>> "Scott" == Scott G Kelly writes: > > Scott> Jackie Wilson wrote: > >> if it is not important from a security standpoint to have it, > >> then why is it in the draft? > > Scott> One argument for using this mechanism is that filling the pad > Scott> bytes with a predictable value prevents filling them with > Scott> other things, i.e. leaking information. I'm not personally > Scott> arguing for or against, just making an observation. > >That's an excellent argument for requiring the sending of some >specified value. But I sure am puzzled about why there's a >requirement (or even a suggestion) that it be checked on receive. > >Unless I'm missing something, the only thing that's necessary for >packet parsing is that you have to be able to tell the length of the >pad. The only additional property needed for security is that the pad >must not be someone else's data. > >The current pad pattern certainly does both of these. Lots of other >pad count plus pad data rules would work just as well -- e.g., pad >data = constant byte N (any N), or random, or pseudorandom. But since >the current pattern works, I wouldn't want to argue for changing it. > >On the other hand, I would like to know why the rule is that you MUST >(rather than MAY) check the pad on receive. > > paul > From owner-ipsec Thu Apr 9 17:40:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA13089 for ipsec-outgoing; Thu, 9 Apr 1998 17:40:10 -0400 (EDT) Message-ID: <352D4311.15FB@cs.umass.edu> Date: Thu, 09 Apr 1998 17:52:17 -0400 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V4.0 alpha) MIME-Version: 1.0 To: "Scott G. Kelly" CC: Peter Ford , iesg@ietf.org, ipsec@tis.com Subject: Re: Last Call for IPSEC References: <8D8EF175E72CD111805800805F3198EE03925D67@red-msg-46.dns.microsoft.com> <352D1160.446B@cs.umass.edu> <352D2FF9.C3530302@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Scott G. Kelly writes: > ...and therein lies the flaw: it is not 'the' key exhange for IP, it's > 'a' key exchange, of which there are many others. There are certainly other key exchanges defined for IP, but AFAIK the IETF is only standardizing this one as the key exchange protocol for IP security. If Photuris or SKIP were continuing in the IETF standards process then I would agree that the name "IKE" would be inappropriate. [...elided...] > The IKE document proposes an instantiation of a key-exchange plug-in, > and describes (for purposes of clarity) the entire conglomeration of the > plug-in and the base component in one document, and there now seems to > be this general notion that this is the new ISAKMP, and that (the old) > ISAKMP is now irrelevant. As you say, IKE = ISAKMP + Oakley + other_stuff (e.g. some pieces of SKEME), and we may need to switch to ISAKMP + something_else in the future. Endowing the conglomeration with a single new name such as "IKE" is clearer IMHO than referring to it in terms of both "ISAKMP" and "Oakley". Anyone who reads as far as the abstract will understand that IKE is a synthesis of several protocols. I believe the title is easier to grasp if it doesn't enumerate all those other protocols. "1. Abstract "[MSST98] (ISAKMP) provides a framework for authentication and key exchange but does not define them. ISAKMP is designed to be key exchange independant; that is, it is designed to support many different key exchanges. "[Orm96] (Oakley) describes a series of key exchanges-- called "modes"-- and details the services provided by each (e.g. perfect forward secrecy for keys, identity protection, and authentication). "[Kra96] (SKEME) describes a versatile key exchange technique which provides anonymity, repudiability, and quick key refreshment. "This document describes a protocol using part of Oakley and part of SKEME in conjunction with ISAKMP to obtain authenticated keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI." > What happens if we find a flaw with the key > exchange portion of the conglomerate? What do we call the next iteration > (if there is one)? The 'Better Internet Key Exchange'?? The 'Second > Internet Key Exchange'? Since we have "IPv4" and "IPv6", it would seem entirely reasonable to me to have, say, "IKE" and "IKEv2". I admit that your acronyms are more appealing, though. :-) -Lewis From owner-ipsec Thu Apr 9 18:15:32 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA13367 for ipsec-outgoing; Thu, 9 Apr 1998 18:14:10 -0400 (EDT) Message-Id: <199804092227.PAA27071@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: "Scott G. Kelly" Cc: Lewis McCarthy , Peter Ford , iesg@ietf.org, ipsec@tis.com Subject: Re: Last Call for IPSEC In-Reply-To: Your message of "Thu, 09 Apr 1998 13:30:49 PDT." <352D2FF9.C3530302@redcreek.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 09 Apr 1998 15:27:57 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk The "flaw"? The name is a flaw? Please tell me your opinion on The Point-to-Point Tunneling Protocol. There are others, and some would say better ones, yet no one claims that PPTP is flawed because of its name. And no one is upset at the broadness of it's claim to be _The_ Point-to-Point Tunneling Protocol. The problem of the conglomeration of a plug-in? If there was any doubt anywhere that the IPSec WG was finished, I hope this rediculous discussion dispells it. Dan. > Lewis McCarthy wrote: > > > > Peter Ford writes: > > > 3) calling anything the Internet > > > Key Exchange (IKE) should not happen since there are many Internet Key > > > Exchanges going on in the Internet today and several are being standardized > > > by Internet working groups(e.g TLS). > > > > Until now I didn't realize you were raising this as a serious objection. > > To my ear, calling the key exchange for the "Internet Protocol" the "Internet > > Key Exchange" makes the terminology nicely consistent. > > ...and therein lies the flaw: it is not 'the' key exhange for IP, it's > 'a' key exchange, of which there are many others. > > > > The initial assessment (in my view) is correct: IKE is too broad, and > perhaps even misleading. This nibbles around the corners of a larger > problem which I'm surprised no one has mentioned. ISAKMP is the base > protocol within which key exchange takes place. However, it is NOT > strictly a key-exchange protocol. In fact, it is primarily a SA > management protocol, of which key exchange is one component. The point > is, ISAKMP is the protocol here, not IKE. > > ISAKMP is designed to accept key-exchange plug-ins. This makes ISAKMP a > well-designed protocol, in that if we find flaws with the key-exchange > component, it may be replaced without designing an entirely new > protocol. This seems quite reasonable to anticipate, given the relative > dearth of practical operating experience in this frontier. > > The IKE document proposes an instantiation of a key-exchange plug-in, > and describes (for purposes of clarity) the entire conglomeration of the > plug-in and the base component in one document, and there now seems to > be this general notion that this is the new ISAKMP, and that (the old) > ISAKMP is now irrelevant. What happens if we find a flaw with the key > exchange portion of the conglomerate? What do we call the next iteration > (if there is one)? The 'Better Internet Key Exchange'?? The 'Second > Internet Key Exchange'? > > I would suggest that the title of the document convey the actual > document contents. It was called 'The resolution of ISAKMP with Oakley'. > Perhaps it should be called something like 'The Oakley Key Exchange for > ISAKMP', which more accurately describes it than the current title. From owner-ipsec Thu Apr 9 18:23:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA13419 for ipsec-outgoing; Thu, 9 Apr 1998 18:23:10 -0400 (EDT) Message-ID: <352D4DC8.88652668@redcreek.com> Date: Thu, 09 Apr 1998 15:38:00 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Daniel Harkins CC: Lewis McCarthy , Peter Ford , iesg@ietf.org, ipsec@tis.com Subject: Re: Last Call for IPSEC References: <199804092227.PAA27071@dharkins-ss20.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Daniel Harkins wrote: > > The "flaw"? The name is a flaw? > How to respond... nothing personal here, Dan. The flaw is in the logic of the argument that since this is 'the' key exchange for IP, it should be called the IP key exchange. The argument against is simply that the title is misleading and unecessarily broad. I know it's your document, and the post is not meant as an insult. It's an observation. Take it easy. > If there was any doubt > anywhere that the IPSec WG was finished, I hope this rediculous discussion > dispells it. > Agreed - end of my input on this one. From owner-ipsec Thu Apr 9 18:50:57 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA13563 for ipsec-outgoing; Thu, 9 Apr 1998 18:50:10 -0400 (EDT) To: Ben Rogers Cc: iesg@ietf.org, ipsec@tis.com In-Reply-To: Your message of "09 Apr 1998 12:24:41 EDT" From: Dave Johnson Reply-To: Dave Johnson Subject: Re: IPsec re-defining IP-in-IP? Date: Thu, 09 Apr 1998 19:02:25 -0400 Message-ID: <1352.892162945@ux6.sp.cs.cmu.edu> Sender: owner-ipsec@ex.tis.com Precedence: bulk >I am a bit concerned as to the redefinition of IP-in-IP tunneling >within the proposed IPsec architecture document. One of the reasons >RFC1825 was able to remain much smaller and simpler than the current >document was that it seems to have been content leaving tunneling to >the folks working on tunneling, while security was handled by the >folks working on security. As such, I see no need to more or less >duplicate the information in RFC2003. > >I would suggest that an explicit description of what to do with IP >protocol 4 ought to be defined in only one location. We (the IPsec >WG) need it to provide a tunneling capability. MobileIP needs it to >satisfy some very funtamental needs in their protocol. There is no >reason that we cannot share the same document. If we don't then we >run the risk of not knowing what to do within an IP stack in the event >that the two documents diverge. We might end up making the >interpretation of IP protocol 4 context dependent, the "IPsec protocol >4" used whenever our parsing engine finds a protocol 4 in an AH or >ESP, and the "RFC2003 protocol 4" in all other cases. > >ben Agreed! In fact, since RFC 2003 is already a Proposed Standard, it is already the official protocol 4, so any other similar protocol defined by IPsec would need to be a different protocol number. Before we get into such an escalation of essentially redundant protocol number assignments, if there is some reason that RFC 2003 doesn't do what IPsec needs (or any other protocol that needs IP-in-IP-like behavior), we should talk about it. If there are some minor revisions that can be made to 2003, please let us (the Mobile IP Working Group, who defined 2003) know about it. Dave From owner-ipsec Thu Apr 9 20:47:44 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA14312 for ipsec-outgoing; Thu, 9 Apr 1998 20:39:34 -0400 (EDT) Date: Thu, 9 Apr 1998 20:52:02 -0400 (EDT) Message-Id: <199804100052.UAA01652@bual.research.att.com> From: John Ioannidis To: dbj@cs.cmu.edu CC: ben@morningstar.com, iesg@ietf.org, ipsec@tis.com In-reply-to: <1352.892162945@ux6.sp.cs.cmu.edu> (message from Dave Johnson on Thu, 09 Apr 1998 19:02:25 -0400) Subject: Re: IPsec re-defining IP-in-IP? Reply-To: ji@research.att.com Organization: AT&T Labs - Research References: <1352.892162945@ux6.sp.cs.cmu.edu> Sender: owner-ipsec@ex.tis.com Precedence: bulk In <1352.892162945@ux6.sp.cs.cmu.edu> (message from Dave Johnson on Thu, 09 Apr 1998 19:02:25 -0400), Dave Johnson writes: > Agreed! In fact, since RFC 2003 is already a Proposed Standard, > it is already the official protocol 4, so any other similar protocol > defined by IPsec would need to be a different protocol number. > Before we get into such an escalation of essentially redundant > protocol number assignments, if there is some reason that RFC 2003 > doesn't do what IPsec needs (or any other protocol that needs > IP-in-IP-like behavior), we should talk about it. If there are > some minor revisions that can be made to 2003, please let us (the > Mobile IP Working Group, who defined 2003) know about it. I finally looked up rfc2003, which I hadn't bothered to do so far, as I have been developing protocols that do IP encapsulation since ~1990, first in my Mobile IP protocols and then swIPe, the precursor to IPSEC, all long before 2003 was written. I was surprised to notice that there were no references to any of that work in rfc2003 (for example, my Sigcomm'91 paper (joint paper with Maguire and Duchamp), my winter Usenix'93 paper (joint paper with Maguire), my 4th Usenix Security symposium paper (joint paper with Blaze), not to mention my 1993 PhD thesis!). This omission is particularly surprising in light of the fact that the editor of 2003 is Charlie Perkins, who has been very familiar with my work since at least 1990, and other members of the MobileIP working group would also have been expected to have known about it. There are more missing references, other than those to my own work: the MBONE people have been using prococol 4 instead of source routing to do multicast tunneling since the meltdown at the December '92 IETF. There are no references to any of that either. I'm mentioning all this because the IETF community traditionally has been very careful to give credit where credit is due and to reference the work upon which protocols are based (to rfc2003's credit, rfc1853 by Bill Simpson *is* referenced (which, in turn, does reference the Sigcomm and the swIPe papers), as is rfc1826, which references RFC1825, which references the swIPe paper). I trust that when the mobile-ip protocols move to the next stage of the standardization process, care will be taken to ensure that proper references are made. I will be happy to supply all the citations that I'm aware of. Regards, /ji From owner-ipsec Fri Apr 10 07:41:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA17453 for ipsec-outgoing; Fri, 10 Apr 1998 07:38:40 -0400 (EDT) Message-Id: <3.0.1.32.19980410115519.00689490@192.9.200.10> X-Sender: anupama@192.9.200.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Fri, 10 Apr 1998 11:55:19 +0500 To: ipsec@tis.com From: Anupama Potluri Subject: Questions about IKE Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id HAA17450 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi all, · The ISAKMP RFC (and so IKE) says that the peers establishing the SA may be doing so on behalf of clients. So, when we have to send out a packet to a remote machine, how do we know which are the ISAKMP peers for this connection? · What are the default values for the attributes of an ISAKMP SA if they are not negotiated? · What is to be done if a phase 2 exchange type is detected before a phase 1 exchange is complete or if there is no such ISAKMP SA as indicated by the cookie pair? Send a notify message? If so, which message? · The SPI value included in the proposal payload --- is the value given by initiator assumed to be for the incoming SA into the initiator? And vice versa for the responder? · What happens if, in the middle of the quick mode exchange, the ISAKMP SA expires? Do we drop the datagram for which the quick mode exchange was initiated or start a new phase 1 negotiation and continue with the phase 2 negotiation? Regards, Anupama From owner-ipsec Fri Apr 10 07:43:48 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA17537 for ipsec-outgoing; Fri, 10 Apr 1998 07:43:43 -0400 (EDT) Date: Fri, 10 Apr 1998 15:34:51 +0900 (JST) Message-Id: <199804100634.PAA12029@parasite.yokogawa.co.jp> From: Ne To: ipsec@tis.com Subject: Question about PFKEYv2 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Mailer: mnews [version 1.21] 1997-12/23(Tue) Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, I'm working to implement PFKEYv2. I have read the draft, but I can't find how to specify whether transport mode or tunnel mode of each security protocol by PFKEYv2 protocol. Could anyone tell me the way to specify the mode by application, or the pointer to the way. Regards ========================================================== Shoichi Sakane From owner-ipsec Fri Apr 10 07:44:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA17552 for ipsec-outgoing; Fri, 10 Apr 1998 07:44:45 -0400 (EDT) Message-Id: <199804100426.VAA27209@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: "Scott G. Kelly" Cc: Lewis McCarthy , Peter Ford , iesg@ietf.org, ipsec@tis.com Subject: Re: Last Call for IPSEC In-Reply-To: Your message of "Thu, 09 Apr 1998 15:38:00 PDT." <352D4DC8.88652668@redcreek.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 09 Apr 1998 21:26:44 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm not taking it personally and I don't feel insulted. The vision you should have in mind is not bloodshot eyes and smoke leaving ears, it's the slackjawed, "jeez, I can't believe it!" My point is, is that this is a well travelled path I'm on here. If anyone has a problem with the name IKE then I hope it's a problem with a half dozen (actually, I think it's more like a "wild mileau of") other protocols too, otherwise it _is_ personal. Criticize IKE for being complicated, poorly written or whatever but if naming is an issue let's argue about "The Pre-Shared Key for The Internet". That's something that I'm taking personally (insert emoticon here). Dan. > How to respond... nothing personal here, Dan. The flaw is in the logic > of the argument that since this is 'the' key exchange for IP, it should > be called the IP key exchange. The argument against is simply that the > title is misleading and unecessarily broad. I know it's your document, > and the post is not meant as an insult. It's an observation. Take it > easy. From owner-ipsec Fri Apr 10 08:38:06 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA18043 for ipsec-outgoing; Fri, 10 Apr 1998 08:37:45 -0400 (EDT) Date: Fri, 10 Apr 1998 21:57:56 +0900 (JST) Message-Id: <199804101257.VAA13254@parasite.yokogawa.co.jp> From: Ne To: ipsec@tis.com Subject: Re: Question about PFKEYv2 In-Reply-To: Your message of "Fri, 10 Apr 1998 15:34:51 JST". <199804100634.PAA12029@parasite.yokogawa.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Mailer: mnews [version 1.21] 1997-12/23(Tue) Sender: owner-ipsec@ex.tis.com Precedence: bulk :I have read the draft, but I can't find how to specify :whether transport mode or tunnel mode of each security protocol :by PFKEYv2 protocol. : :Could anyone tell me the way to specify the mode by application, :or the pointer to the way. If there is SADB_EXT_ADDRESS_PROXY header in the message passed by application, it is as tunnel mode. Is that right ? ------------ Shoichi Sakene From owner-ipsec Fri Apr 10 10:38:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA18813 for ipsec-outgoing; Fri, 10 Apr 1998 10:36:44 -0400 (EDT) Mime-Version: 1.0 Date: Fri, 10 Apr 1998 10:45:27 -0400 Message-ID: <0008E044.@smtp.microcom.com> From: rgreene@smtp.microcom.com (Roy Greene) To: ipsec@tis.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ipsec@ex.tis.com Precedence: bulk I recently evaluated some "ipsec" products. I do not feel a high level of interoperability has been achieved so far I have ploughed through the ipsec email archive and skimmed through the ipsec drafts listed on the ietf web site. Can someone please tell me:- 1) Which of these drafts will be submitted for last call ? 2) When will this happen ? 3) When are the drafts expected to become RFCs ? 4) Which of these drafts will be mandatory for a product to be properly labelled as ipsec ? I hope this is relevant for this mailing list. Roy Greene Principal Engineer Compaq ASD rgreene@microcom.com From owner-ipsec Fri Apr 10 12:13:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA19479 for ipsec-outgoing; Fri, 10 Apr 1998 12:11:14 -0400 (EDT) Message-ID: <352E47AE.15FB@cs.umass.edu> Date: Fri, 10 Apr 1998 12:24:14 -0400 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V4.0 alpha) MIME-Version: 1.0 To: IP Security List CC: ho@earth.hpc.org Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard References: <199803202008.PAA28002@ns.ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk The IESG wrote: > The IESG will also consider publication of the following > Internet-Drafts as Informational RFCs: [...] > o The OAKLEY Key Determination Protocol > Hi, Just a few editorial comments w.r.t. Oakley: [1] The 2000-bit modulus recommendation for 90 bits of strength in Sec. 2.11.1 doesn't seem to jibe with the at-least-1400-bit modulus recommendation for 90 bits of strength in Appendix D. [2] In Appendix D, the clause "the size of the largest prime factor of the modulus" should instead say something like `the size of the largest prime factor of the group size`. The suggested phrasing mirrors the existing language in Sec. 2.8: "The security of a modular exponentiation group depends on the largest prime factor of the group size." [3] In a couple of places Appendix A says: "Strength of group: a 32-bit integer. We will specify a formula for calculating this number (TBD)." Presumably the "TBD" should be changed.... -- Lewis http://www.cs.umass.edu/~lmccarth/ From owner-ipsec Fri Apr 10 12:13:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA19525 for ipsec-outgoing; Fri, 10 Apr 1998 12:13:13 -0400 (EDT) Message-ID: <352E48AE.768273B9@redcreek.com> Date: Fri, 10 Apr 1998 09:28:30 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Roy Greene CC: ipsec@tis.com Subject: [Fwd: Last Call: Security Architecture for the Internet Protocol toProposed Standard] Content-Type: multipart/mixed; boundary="------------7A046B6EDE6A7BB239DBCB65" Sender: owner-ipsec@ex.tis.com Precedence: bulk This is a multi-part message in MIME format. --------------7A046B6EDE6A7BB239DBCB65 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Roy, Attached is the IESG announcement... --------------7A046B6EDE6A7BB239DBCB65 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from [192.94.214.101] by smtp.redcreek.com (SMTPD32-4.0) id AD74A31D016C; Fri, 20 Mar 1998 15:36:20 -0800 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA02092 for ipsec-outgoing; Fri, 20 Mar 1998 17:02:49 -0500 (EST) Message-Id: <199803202008.PAA28002@ns.ietf.org> To: IETF-Announce:;;;;@tis.com@tis.com;;; Cc: ipsec@tis.com From: The IESG SUBJECT: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Reply-to: iesg@ns.ietf.org Date: Fri, 20 Mar 1998 15:08:18 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk The IESG has received a request from the IP Security Protocol Working Group to consider publication of the following Internet-Drafts as Proposed Standards: 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 The IESG will also consider 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 The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by April 11, 1998. Files can be obtained via: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-arch-sec-04.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-auth-header-05.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-md5-96-03.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-sha196-03.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-des-expiv-02.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v2-04.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-ipsec-doi-08.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-09.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-oakley-07.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-null-00.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-doc-roadmap-02.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-oakley-02.txt --------------7A046B6EDE6A7BB239DBCB65-- From owner-ipsec Fri Apr 10 16:24:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA21279 for ipsec-outgoing; Fri, 10 Apr 1998 16:22:14 -0400 (EDT) Date: Fri, 10 Apr 1998 16:36:00 -0400 From: Ran Canetti Message-Id: <9804102036.AA24144@ornavella.watson.ibm.com> To: canetti@watson.ibm.com, kivinen@ssh.fi Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Tero Kivinen writes: > > Recall that the revised mode does not suffer from the problems that Lewis > > points out (since there the RSA encryption encrypts only a key to > > some block cipher). > > Not true. You still have to limit the nonce size from the maximum of > 256 bytes to such that it can be encrypted using the given key. > Tero, indeed one has to limit the size of the nonce to fit within the appropriate length, say the PKCS-allowed length. (In fact, it may be easier to have the recipient simply truncate the nonce to the appropriate length.) But this is very different than the problems that Lewis brought up. You cannot truncate a long ID (say, an X509 ID); and you have the low exponent problem because the ID is not random. The natural way to get around these problems would be to use RSA to encrypt a key for a symmetric cipher, and then encrypt the ID with this key. However, this is already done in the revised mode... Ran From owner-ipsec Mon Apr 13 08:13:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA09954 for ipsec-outgoing; Mon, 13 Apr 1998 08:01:15 -0400 (EDT) Date: Fri, 10 Apr 1998 18:15:12 -0400 (EDT) From: Henry Spencer To: "Scott G. Kelly" cc: iesg@ietf.org, ipsec@tis.com Subject: Re: Last Call for IPSEC In-Reply-To: <352D4DC8.88652668@redcreek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Thu, 9 Apr 1998, Scott G. Kelly wrote: > ...The flaw is in the logic > of the argument that since this is 'the' key exchange for IP, it should > be called the IP key exchange. The argument against is simply that the > title is misleading and unecessarily broad... TCP is not the only transmission-control protocol used on the Internet. Nor is ICMP the only control-message protocol. Nor is PPP the only point-to-point protocol. Nor, for that matter, is IP the only protocol. Names of this kind are typically metaphors. They should not be taken too literally. To make the name more descriptive, TCP should really be called something like the First Internet Reliable Flow-Controlled Bidirectional Stream Protocol, but who cares? For that matter, the abbreviations become names in their own right. I'd bet that at least 75% of people who know what TCP is wouldn't immediately recognize it if you called it "Transmission Control Protocol", and 95% of the people who know what "IP" is would say "huh?" if you referred to "the Internet Protocol" instead of "eye-pee". The United Nations International Children's Emergency Fund became so well-known as "UNICEF" that when they changed the name of the agency -- they dropped the "International" part as redundant, and the "Emergency" part because the postWW2 emergency was over -- they left the acronym unchanged. The one thing that would make "Internet Key Exchange" a poor name would be if IETF was standardizing more than one key-exchange system, which it isn't. We need a short name for it; this one may not be perfect but it is good enough. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec Mon Apr 13 08:13:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA09987 for ipsec-outgoing; Mon, 13 Apr 1998 08:03:15 -0400 (EDT) Message-Id: <3.0.3.32.19980411122108.009e2530@mail.zserv.tuwien.ac.at> X-Sender: vanas@mail.zserv.tuwien.ac.at X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sat, 11 Apr 1998 12:21:08 +0200 To: ipsec@tis.com From: "Harmen R. van As" Subject: 8th IFIP Conference on High Performance Networking (HPN'98) Mime-Version: 1.0 Content-Type: text/enriched; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-ipsec@ex.tis.com Precedence: bulk Dear member of the IP Security Protocol community We still are looking for some papers for the HPN'98 Conference in Vienna. Would there be any change that you or somebody else would be able to submit a contribution within the next two weeks? Please notify coming submission With best regards Harmen R. van As
CALL FOR TUTORIALS CALL FOR PAPERS DEADLINE EXTENDED BUT NOTIFY COMING SUBMISSION ----------------------------------------------------------- 8th IFIP Conference on High Performance Networking (HPN'98) The Millennium Push of Internet =20 Vienna University of Technology, Vienna, Austria September 21-25, 1998 ------------------------------------------------------------ http://www.ikn.tuwien.ac.at/IKN/events/hpn-cfp.html March 15, 1998: Tutorial proposal March 15, 1998: Paper submission April 15, 1998: Notification May 15, 1998: Camera-ready paper =20 Conference book published by Chapman & Hall
Paper submission: preferably postscript file attached to email=20 otherwise 5 copies of paper by postal mail Topics of interest:=20 - Trends of Internet/Intranet Technologies=20 - Next Generation Internet, Evolutionary approaches=20 - Fast Internet (ADSL, HDSL, VHDSL, PONs)=20 - Cable Network, Wireless and Satellite Access=20 - Next Generation Routers, Tag Switching=20 - Bypass Tunneling (SDH, Photonics) =20 - Network/System Architecture and Design=20 - Cache Server Allocation and Interconnection=20 - Network Availability, Automatic Reconfiguration=20 - Coporate Networks, Global Networking =20 - Security in Internet, Network/System Security=20 - Network Management using Internet=20 - WWW and Java Network Service Management=20 - Distributed Systems Management in Internet=20 - Interworking with ATM, ISDN, and LANs=20 - System Interoperability =20 - Internet Mobility Support, Mobility Management=20 - Mobile-IP, Mobile-IPv6=20 - Mobile Agents, Intelligent/Smart Agents=20 - Flow Control, Traffic Monitoring and Control=20 - Adressing and Routing =20 - Advanced Internet Protocols (RTP, RSVP)=20 - Multicast Protocols=20 - Protocol Design, Combined ATM and IP=20 - Secure Protocols (S-HTTP, SSL, SET)=20 - Internet Tunneling =20 - Quality of Service, Service Level Guarantees=20 - Resource Management=20 - Real-Time Services over Internet=20 - IP Telephony, Voice over Internet=20 - Teleconferencing, Broadband Internet=20 - Integrated Services Internet=20 - Internet in Multimedia Environments=20 - Heterogenous Distributed Environments =20 - Internet Groupware and Cooperative Work=20 - Information Management over Internet=20 - Electronic Commerce, Online-Marketing=20 - Internet Payment Systems, Webcasting=20 - WWW Servers, Tele-Service-Systems=20 - Internet Servers (Data-Base, Cache, Archive)=20 - High-Performance Tele-Activities=20 - Social Impacts, Opportunities and Threats=20 INTERNATIONAL PROGRAM COMMITTEE:=20 General Chair:=20 Harmen R. van As, Vienna University of Technology, Austria=20 Ian Akyildiz, Georgia Tech, USA=20 Torsten Braun, Univ. of Berne, CH=20 Augusto Casaca, INESC, Portugal=20 Andre Danthine, Univ. Liege, Belgium=20 Michel Diaz, Univ. Toulouse, France=20 Christophe Diot, INRIA, France=20 Otto Duarte, Univ. Fed. Rio de Janeiro, Brazil=20 J=F6rg Ebersp=E4cher, Techn. Univ. Munich, Germany=20 Serge Fdida, Univ. Paris VI, France=20 Zygmunt Haas, Cornell University, USA=20 Marjory Johnson, NASA-RIACS, USA=20 Paul K=FChn, Univ. Stuttgart, Germany=20 Ralf Lehnert, Dresden Univ. of Technology, Germany=20 Helmut Leopold, Alcatel, Austria=20 Kurt Maly, Old Dominion Univ., USA=20 Olli Martikainen, Helsinki Univ. of Technology, Finland=20 Georg Mittenecker, Vienna Univ. of Technology, Austria=20 Hussein Mouftah, Queens Univ., Canada=20 Ignas Niemegeers, Univ. of Twente, The Netherlands=20 Guru Parulkar, Washington U. St. Louis, USA=20 Stephen Pink, SICS, Sweden=20 Radu Popescu-Zeletin, GMD Fokus, Germany=20 Ramon Puigjanier, Univ. Illes Balears, Spain=20 Guy Pujolle, Univ. Versailles, France=20 Doug Shepherd, Univ. Lancaster, UK=20 Thomas Sommer, Vienna Univ. of Technology, Austria=20 Otto Spaniol, Univ. Aachen, Germany=20 Ralf Steinmetz, Techn. Univ. Darmstadt, Germany=20 Ahmed Tantawi, IBM Res., Yorktown Heights, USA=20 Fouad Tobagi, Stanford Univ., USA=20 Samir Tohm=E9, ENST, France=20 Giorgio Ventre, Univ. Napoli, Italy=20 Martina Zitterbart, Univ. Braunschweig, Germany=20 ---------------------------------------------------------------------------- Prof.Dr. Harmen R. van As Institute of Communication Networks Vienna University of Technology Tel +43-1-58801-5246 Gusshausstrasse 25/388 Fax +43-1-5870583 A-1040 Vienna, Austria email: Harmen.R.van-As@tuwien.ac.at http://www.ikn.tuwien.ac.at=20 ---------------------------------------------------------------------------- From owner-ipsec Mon Apr 13 08:13:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA09981 for ipsec-outgoing; Mon, 13 Apr 1998 08:02:16 -0400 (EDT) Message-Id: <002001bd6507$1531bec0$a606c5ca@iceman.nudt.edu.cn> From: "Wei Peng" To: Subject: Questions Date: Sat, 11 Apr 1998 13:02:46 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, I'm a doctoral student and now engaged in the research of Mobile IP. Because I'm unfamiliar with the IP security, I have two questions : 1) Is there any way to transfer the security relationship between the Correspondent Node (CN) and the Home Agent (HA) to that between the CN and the Mobile Node (MN) ? 2) if the CN trusts the HA, the HA can distribute a key to both the CN and the MN that is known to no other entity. How to establish the Registration Key between the CN and the MN ? Is there a Internet Draft to tackle this problem ? Thanks. Best regards, Wei Peng From owner-ipsec Mon Apr 13 09:58:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA11009 for ipsec-outgoing; Mon, 13 Apr 1998 09:57:17 -0400 (EDT) Message-Id: <35321CF9.31D9014A@xedia.com> Date: Mon, 13 Apr 1998 10:11:05 -0400 From: Leonard Schwartz Organization: Xedia Corp., X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.4 sun4m) Mime-Version: 1.0 To: Roy Pereira , "'ipsec@tis.com'" Subject: Radius authentication and client configuration Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk In the remote dial-in world there are numbers of features and/or services expected by users. These include (but certainly not limited to): a) ability to perform user authorization to gain access to corporate networks. This is typically done via Radius authentication; b) user accounting. This is typically done via Radius accounting; c) configure remote dial-in client. The configuration information includes (but not limited to): IP address, net mask, DNS server, etc. After reviewing several products it is clear that vendors who support the features defined above implement them in a proprietary fashion, i.e. dial-in client from vendor X has no chance of performing Radius authentication and/or client configuration with VPN gateway from vendor Y. There are 2 drafts that by introducing a number of additions to ISAKMP main mode exchange attempt to standardize the process: - Extended Authentication Within ISAKMP/Oakley and - The ISAKMP Configuration Method Date: Mon, 13 Apr 1998 07:41:13 -0700 (PDT) From: Charles Perkins Reply-To: Charles Perkins Subject: Re: IPsec re-defining IP-in-IP? (Fwd) To: John Ioannidis Cc: iesg@ietf.org, ipsec@tis.com, ben@morningstar.com, dbj@cs.cmu.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: UsYwdRvZUKr+giYNsV/aqA== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-ipsec@ex.tis.com Precedence: bulk JI, Someone forwarded me mail from you, which references a message from Dave Johnson, and discusses RFC 2003. >In <1352.892162945@ux6.sp.cs.cmu.edu> (message from Dave Johnson on >Thu, 09 Apr 1998 19:02:25 -0400), Dave Johnson writes: > > If there are > some minor revisions that can be made to 2003, please let us (the > Mobile IP Working Group, who defined 2003) know about it. I strongly support Dave's remarks. > I was surprised to notice that there were no references to any of that > work in rfc2003 (for example, my Sigcomm'91 paper (joint paper with > Maguire and Duchamp), my winter Usenix'93 paper (joint paper with > Maguire), my 4th Usenix Security symposium paper (joint paper with > Blaze), not to mention my 1993 PhD thesis!). > > This omission is particularly surprising in light of the fact that the > editor of 2003 is Charlie Perkins, who has been very familiar with > my work since at least 1990, and other members of the MobileIP working > group would also have been expected to have known about it. The omission was not intentional. And, yes, since your work with Dan and Chip formed the original nucleus from which the Mobile IP working group was developed, there were a number of people familiar with it. Unfortunately, during the months of review and even including some extraordinary commentary during IETF last call, no one noticed the omission you point out. > I'm mentioning all this because the IETF community traditionally has > been very careful to give credit where credit is due and to reference > the work upon which protocols are based (to rfc2003's credit, rfc1853 > by Bill Simpson *is* referenced (which, in turn, does reference the > Sigcomm and the swIPe papers), as is rfc1826, which references > RFC1825, which references the swIPe paper). I trust that when the > mobile-ip protocols move to the next stage of the standardization > process, care will be taken to ensure that proper references are > made. I will be happy to supply all the citations that I'm aware of. I certainly do agree with the tradition of giving credit where credit is due, and you may be aware that I have cited your papers numerous times in other publications. However, I also note that the purpose of citation in RFC is more to serve the purpose of illustration and providing fuller understanding, than to establish priority. Thanks for offering to supply the citations. Perhaps the best thing would be to post them during any review during the next stage of standardization. I already have most of the citations available online, but posting them during the review will have the additional benefit of allowing comments from other working group members about the subject. Regards, Charlie P. From owner-ipsec Mon Apr 13 14:11:32 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA12768 for ipsec-outgoing; Mon, 13 Apr 1998 14:06:31 -0400 (EDT) Date: Mon, 13 Apr 1998 14:19:37 -0400 (EDT) From: "M.C.Nelson" To: Howard Weiss cc: smb@research.att.com, skelly@redcreek.com, peterf@microsoft.com, ipsec@tis.com Subject: Re: Last Call: Security Architecture for the Internet Protocol to In-Reply-To: <9804091213.AA12346@katahdin.columbia.sparta.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Thu, 9 Apr 1998, Howard Weiss wrote: > > There is absolutely no doubt that once the IPSEC technology is > fielded, it *will* be *stress tested* ! > All the more reason to find out now whether or not it meets its objectives. Again, the only real way to do this is to set up some targets and provide motivation for breaking them. From owner-ipsec Tue Apr 14 06:45:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA19395 for ipsec-outgoing; Tue, 14 Apr 1998 06:40:24 -0400 (EDT) Date: Tue, 14 Apr 1998 13:53:47 +0300 (EET DST) Message-Id: <199804141053.NAA19986@pilari.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Ran Canetti Cc: ipsec@tis.com Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard In-Reply-To: <9804102036.AA24144@ornavella.watson.ibm.com> References: <9804102036.AA24144@ornavella.watson.ibm.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 9 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Ran Canetti writes: > > Not true. You still have to limit the nonce size from the maximum of > > 256 bytes to such that it can be encrypted using the given key. > Tero, indeed one has to limit the size of the nonce to fit within the > appropriate length, say the PKCS-allowed length. (In fact, it may be easier > to have the recipient simply truncate the nonce to the appropriate length.) The nonce must NOT be truncated in the encryption, because if only part of the nonce is encrypted and trasmitted then the authentication hashes doesn't match. Both ends need to generate nonces that is suitable for encryption for the public key of the remote end. > But this is very different than the problems that Lewis brought up. You > cannot truncate a long ID (say, an X509 ID); and you have the low exponent > problem because the ID is not random. The natural way to get around these > problems would be to use RSA to encrypt a key for a symmetric cipher, > and then encrypt the ID with this key. However, this is already done in the > revised mode... Yes, I know this is different problem, but I think that some comment about that should be added to revised encryption mode section too. I don't think this issues is a problem in the original rsa encryption mode. Most of the time the ID will be just 64 bits (IPV4 address), that can be encrypted using almost any key. For IPV6 the ID length is 160 bits and that also doesn't cause any problems. If the ID is ID_FQDN, ID_USER_FQDN, or ID_DER_ASN1_{DN,GN}, and the ID is too long, then we just don't use RSA encryption mode. -- kivinen@iki.fi Work : +358-9-4354 3207 Magnus Enckellin kuja 9 K 19, 02610, Espoo Home : +358-9-502 1573 From owner-ipsec Tue Apr 14 17:34:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA24091 for ipsec-outgoing; Tue, 14 Apr 1998 17:24:30 -0400 (EDT) Date: Tue, 14 Apr 1998 17:38:45 -0400 Message-Id: <9804142138.AA13847@kona.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ipsec@tis.com Subject: byte order X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk This may be excessively obvious to some, but I've found that it's never a bad idea to be explicit... RFC 1851 explicitly discusses byte order for (3)DES, but the current I-Ds appear not to do so. Given that there is a mix of byte orders in the various transforms (e.g., MD5 is little endian) it would seem useful to specify the byte order explicitly for all transforms. I assume the various flavors of DES are indeed still big endian. What about SHA1? Is it little endian by analogy to MD5? paul From owner-ipsec Tue Apr 14 18:05:40 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA24358 for ipsec-outgoing; Tue, 14 Apr 1998 18:02:29 -0400 (EDT) From: Dan McDonald Message-Id: <199804142215.PAA16845@kebe.eng.sun.com> Subject: Re: byte order To: pkoning@xedia.com (Paul Koning) Date: Tue, 14 Apr 1998 15:15:31 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <9804142138.AA13847@kona.xedia.com> from "Paul Koning" at Apr 14, 98 05:38:45 pm 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 Oftentime, the _algorithm_ spec itself (for example, RFC 1321 for MD5, or the appropriate FIPS document for SHA-1 and/or DES) contains this information. I'd been under the working assumption to read the algorithm spec., as well as the "using algorithm with IPsec." Just my $0.02 worth. Dan From owner-ipsec Tue Apr 14 18:31:44 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA24477 for ipsec-outgoing; Tue, 14 Apr 1998 18:27:30 -0400 (EDT) Message-Id: <98Apr14.184218edt.11683@janus.tor.securecomputing.com> To: Paul Koning cc: ipsec@tis.com Subject: Re: byte order References: <9804142138.AA13847@kona.xedia.com> In-reply-to: Your message of "Tue, 14 Apr 1998 17:38:45 -0400". <9804142138.AA13847@kona.xedia.com> From: "C. Harald Koch" Date: Tue, 14 Apr 1998 18:41:01 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <9804142138.AA13847@kona.xedia.com>, Paul Koning writes: > RFC 1851 explicitly discusses byte order for (3)DES, but the current > I-Ds appear not to do so. Yes, RFC 1851 mentions byte-order. IMHO, it is unecessary and confusing. > I assume the various flavors of DES are indeed still big endian. What > about SHA1? Is it little endian by analogy to MD5? The only real byte-order issue with MD5 and SHA1 is *internal*. The input and output are defined as bit-strings, with a well-defined byte and word ordering defined as part of the algorithms themselves. The IPsec transforms treat those objects as opaque, and simply preserve order. In the case of DES, the inputs and outputs are all octet strings, at least in every definition I've seen. (There was an implementation of MD5 in a library that output the digest in the wrong order (last byte first). This was purely an implementation error.) -- Harald Koch From owner-ipsec Tue Apr 14 19:19:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA24739 for ipsec-outgoing; Tue, 14 Apr 1998 19:14:31 -0400 (EDT) Message-Id: <199804142328.TAA18311@tecumseh.altavista-software.com> X-Sender: ljopop@ranier.altavista-software.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 14 Apr 1998 19:24:54 -0400 To: Paul Koning From: Matt Thomas Subject: Re: byte order Cc: ipsec@tis.com In-Reply-To: <9804142138.AA13847@kona.xedia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 05:38 PM 4/14/98 , Paul Koning wrote: >This may be excessively obvious to some, but I've found that it's >never a bad idea to be explicit... Usually I agress but not in this case. >I assume the various flavors of DES are indeed still big endian. What >about SHA1? Is it little endian by analogy to MD5? SHA1 (FIPS 186-1) is big-endian. I really don't see the need to state endianess since that must have been discussed in the transform definition itself. Anyways, the transforms are defined to take a byte stream and as such there is no endianess (internally they have an endianness that need not be discussed by IPsec). -- Matt Thomas Internet: matt.thomas@altavista-software.com Internet Locksmith WWW URL: AltaVista Internet Software Disclaimer: This message reflects my own Littleton, MA warped views, etc. From owner-ipsec Wed Apr 15 00:24:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA26388 for ipsec-outgoing; Wed, 15 Apr 1998 00:19:30 -0400 (EDT) Date: Wed, 15 Apr 1998 00:32:47 -0400 From: Ran Canetti Message-Id: <9804150432.AA24664@ornavella.watson.ibm.com> To: canetti@watson.ibm.com, kivinen@ssh.fi Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Tero Kivinen writes: > The nonce must NOT be truncated in the encryption, because if only > part of the nonce is encrypted and trasmitted then the authentication > hashes doesn't match. Both ends need to generate nonces that is > suitable for encryption for the public key of the remote end. Ofcourse, if the nonce is truncated, the sender has to notify the recipient of this fact. (Alternatively the parties have to decide in advance on the the appropriate size of the nonce.) I agree that a comment to this effect should be added to the IKE document. > I don't think this issues is a problem in the original rsa encryption > mode. Most of the time the ID will be just 64 bits (IPV4 address), > that can be encrypted using almost any key. For IPV6 the ID length is > 160 bits and that also doesn't cause any problems. If the ID is > ID_FQDN, ID_USER_FQDN, or ID_DER_ASN1_{DN,GN}, and the ID is too long, > then we just don't use RSA encryption mode. I agree that today the problem will probably occur quite rarely. (I suspect that IDs will get longer pretty fast, but that's a different issue.) Anyway, why not use the revised mode, where the problem NEVER appears? (Is it really that much more complicated to implement, given all the rest? I find it surprising...) Ran From owner-ipsec Wed Apr 15 00:24:22 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA26416 for ipsec-outgoing; Wed, 15 Apr 1998 00:21:29 -0400 (EDT) Message-Id: <3.0.5.32.19980415002510.009ff510@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 15 Apr 1998 00:25:10 -0400 To: "Scott G. Kelly" , Lewis McCarthy From: Robert Moskowitz Subject: Re: Last Call for IPSEC Cc: Peter Ford , iesg@ietf.org, ipsec@tis.com In-Reply-To: <352D2FF9.C3530302@redcreek.com> References: <8D8EF175E72CD111805800805F3198EE03925D67@red-msg-46.dns.microsoft.com> <352D1160.446B@cs.umass.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 01:30 PM 4/9/98 -0700, Scott G. Kelly wrote: > >ISAKMP is designed to accept key-exchange plug-ins. This makes ISAKMP a >well-designed protocol, in that if we find flaws with the key-exchange >component, it may be replaced without designing an entirely new >protocol. This seems quite reasonable to anticipate, given the relative >dearth of practical operating experience in this frontier. Note that ISAKMP is standards track. That was in recognistion of its nature. Will there be another 'IKE'? Field experience will tell. Also it is up to other wgs to see how they will embrace ISAKMP. Will they use IKE with their own DOI? Or develop 'Casidy' or 'Carson', or.... Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Wed Apr 15 00:39:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA26521 for ipsec-outgoing; Wed, 15 Apr 1998 00:36:29 -0400 (EDT) Message-Id: <3.0.5.32.19980415004133.009bbc00@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 15 Apr 1998 00:41:33 -0400 To: Leonard Schwartz , Roy Pereira , "'ipsec@tis.com'" From: Robert Moskowitz Subject: Re: Radius authentication and client configuration In-Reply-To: <35321CF9.31D9014A@xedia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:11 AM 4/13/98 -0400, Leonard Schwartz wrote: > >There are 2 drafts that by introducing a number of additions to ISAKMP >main mode exchange attempt to standardize the process: >- Extended Authentication Within ISAKMP/Oakley > and >- The ISAKMP Configuration Method > >Is IPsec working group attempts to standardize these 2 drafts to solve >the problem of Radius authentication and client configuration? Or >perhaps, there are other alternatives that must be examined? As discussed at IETF, this issue, and these documents will be part of the re-chartering of IPsec. They are important... Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Wed Apr 15 07:34:07 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA29281 for ipsec-outgoing; Wed, 15 Apr 1998 07:30:30 -0400 (EDT) Date: Wed, 15 Apr 1998 09:33:03 +0545 (NPT) From: Badri Ghimire To: Naganand Doraswamy cc: ipsec@tis.com, mpls@external.cisco.com, ietf-ppp@merit.edu, int-serv@isi.edu Subject: Re: VPN mailing list In-Reply-To: <3.0.32.19980208105656.00b7bb68@bl-mail1.corpeast.baynetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, I'm trying to implement VPDN( Virtual Private Dialup Network) with Cisco routers and having a hard time. Can anyone point me to a right resources ( Mailing list, URL etc ) for it, mailing list would be the best. Any pointer on this would be highly appreciated. Thanks. From owner-ipsec Wed Apr 15 07:37:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA29396 for ipsec-outgoing; Wed, 15 Apr 1998 07:36:30 -0400 (EDT) From: Karen Heron To: Subject: Hop Limit in Inner Header (IPv6) Message-ID: <5040300014982482000002L022*@MHS> Date: Wed, 15 Apr 1998 07:49:03 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk In draft-ietf-ipsec-arch-sec-04, 5.1.2.2 IPv6 -- Header Construction for Tunnel Mode, the inner header Hop Limit is decremented. This will cause problems for securing IPv6 NDP traffic. The hop limit is set to 255 in NDP packets and checked in the receiving node to make sure it came from the same link. If this NDP exchange is secured using tunnel mode and the hop limit is decremented before the packet is encapsulated, the receiving node will reject the NDP packet and neighbor discovery will fail, even if the two nodes are on the same link. Should the Hop Limit not be decremented for locally generated traffic? If not, I don't see how NDP traffic can be secured using tunnel mode - maybe I've missed something in the drafts that said this. If this question has already been answered, I'd appreciate a pointer to the discussion (I didn't see it in the archives). Karen Heron Router Development IBM, RTP, NC From owner-ipsec Wed Apr 15 09:02:44 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA00073 for ipsec-outgoing; Wed, 15 Apr 1998 08:58:33 -0400 (EDT) Date: Wed, 15 Apr 1998 06:07:24 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: Radius authentication and client configuration To: Robert Moskowitz Cc: Leonard Schwartz , Roy Pereira , "'ipsec@tis.com'" In-Reply-To: "Your message with ID" <3.0.5.32.19980415004133.009bbc00@homebase.htt-consult.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > At 10:11 AM 4/13/98 -0400, Leonard Schwartz wrote: > > > >There are 2 drafts that by introducing a number of additions to ISAKMP > >main mode exchange attempt to standardize the process: > >- Extended Authentication Within ISAKMP/Oakley > > and > >- The ISAKMP Configuration Method > > > > >Is IPsec working group attempts to standardize these 2 drafts to solve > >the problem of Radius authentication and client configuration? Or > >perhaps, there are other alternatives that must be examined? > > As discussed at IETF, this issue, and these documents will be part of the > re-chartering of IPsec. They are important... > > > Robert Moskowitz > ICSA > Security Interest EMail: rgm-sec@htt-consult.com Not that I mean to be difficult here, but since the RADIUS WG has shutdown, it may be more appropriate to add new functionality to the RADIUS replacement. There is work in progress on a protocol called DIAMETER. I hope to have a BOF at the Chicago IETF. PatC From owner-ipsec Wed Apr 15 09:39:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA00461 for ipsec-outgoing; Wed, 15 Apr 1998 09:37:33 -0400 (EDT) Date: Wed, 15 Apr 1998 09:51:52 -0400 Message-Id: <9804151351.AA14222@kona.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ipsec@tis.com Subject: Re: byte order References: <9804142138.AA13847@kona.xedia.com> <98Apr14.184218edt.11683@janus.tor.securecomputing.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "C" == C Harald Koch writes: C> ... C> In the case of DES, the inputs and outputs are all octet strings, C> at least in every definition I've seen. Matt Thomas said much the same thing. Part of the reason I raised the issue is that all the DES descriptions I have (such as FIPS 46, though admittedly the 1977 edition) describe DES as a BLOCK cypher, operating on 64 bit blocks. Neither FIPS 46 nor 1026 nor 1027, as far as I can find, describe any mapping of octet strings into DES blocks. Another consideration is that I couldn't readily tell the byte order of a popular DES implementation (the one by Eric Young); some of what it does suggests it might be little endian, but the way it describes the IP suggests that it may be big endian after all. Unless there is a clear statement of the octet string mapping to DES blocks in some existing document (if so, I'd appreciate a pointer) I feel very strongly that this has to be added to the (3)DES transform specs. paul From owner-ipsec Wed Apr 15 10:34:09 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA01093 for ipsec-outgoing; Wed, 15 Apr 1998 10:31:31 -0400 (EDT) Message-ID: <01BD685B.E047B3B0@BDOUD> From: Bob Doud To: "'Jackie Wilson'" Cc: "'ipsec@tis.com'" Subject: RE: ESP Pad byte changes Date: Wed, 15 Apr 1998 10:47:23 -0400 MIME-Version: 1.0 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 was just re-reading this thread and I was concerned about the original question below. The implication below is that there may be an interoperability issue. This is certainly not the case if an implementation is properly SENDING the correct specified Pad pattern. (The Pad insertion technique is a MUST in the ESP document - unless otherwise specified in the algorithm RFC.) Whether or not a receiver chooses to inspect the Pad should have no bearing on interoperability. Bob Doud IRE Secure Solutions, Inc. 100 Conifer Hill Drive, Suite 513 Danvers, MA. 01923 Voice: 978-739-4714 FAX: 978-739-5698 mailto:bdoud@ire-ma.com http://www.ire-ma.com/ -----Original Message----- From: Jackie Wilson [SMTP:jhwilson@austin.ibm.com] Sent: Thursday, April 09, 1998 1:22 AM To: ipsec@tis.com Subject: ESP Pad byte changes I was wondering how many implementations are numbering the pad bytes and checking the values as indicated in the latest ESP draft. This seems to be a problem that if you check the values, you may not be able to interoperate with many ipsec implementations. I realize this is a 'should' issue, but this is a low-level detail I don't want to surface to the user to turn on or off. In addition, it is not an attribute that can be negotiated with ISAKMP/Oakley. Is checking the pad numbering strategic, do most implementers plan on doing it? Are most people making this a configurable option? If it's not being done now, are people planning on doing it soon (ie 1998)? If it is not important from a security standpoint to have it, then why is it in the draft? For all the noise made about freezing the drafts, I question the decision to add this in the last round of changes to ESP. Just wondering what others thought. Jackie -- Jacqueline Wilson | Phn: (512) 838-2702 IBM, AIX/6000 | Fax: (512) 838-3509 11400 Burnet Road ZIP 9551 | Ext: 8-2702 Tie-Line: 678 Austin, TX 78758-3493 | inet: jhwilson@austin.ibm.com From owner-ipsec Wed Apr 15 11:57:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA01735 for ipsec-outgoing; Wed, 15 Apr 1998 11:53:37 -0400 (EDT) Message-Id: <3.0.5.32.19980415115808.00a0b7a0@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 15 Apr 1998 11:58:08 -0400 To: "pcalhoun@eng.sun.com" From: Robert Moskowitz Subject: Re: Radius authentication and client configuration Cc: Leonard Schwartz , Roy Pereira , "'ipsec@tis.com'" In-Reply-To: References: <"Your message with ID" <3.0.5.32.19980415004133.009bbc00@homebase.htt-consult.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 06:07 AM 4/15/98 -0700, pcalhoun@eng.sun.com wrote: >Not that I mean to be difficult here, but since the RADIUS WG has shutdown, it >may be more appropriate to add new functionality to the RADIUS replacement. >There is work in progress on a protocol called DIAMETER. I hope to have a BOF >at the Chicago IETF. Nor I. The IPsecers have learned that key negotiations need to be done in a totally secure method. Roy's proposals are in this light. Also, next week I and Ted will get started on the charter and the new work. Vendors need a solution by end of summer. But Ted and I are not ruling out work elsewhere. Either the Radius or Mobile stuff.... Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Wed Apr 15 12:37:06 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA02160 for ipsec-outgoing; Wed, 15 Apr 1998 12:36:35 -0400 (EDT) Date: Wed, 15 Apr 1998 09:16:31 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: Radius authentication and client configuration To: Robert Moskowitz Cc: "pcalhoun@eng.sun.com" , Leonard Schwartz , Roy Pereira , "'ipsec@tis.com'" In-Reply-To: "Your message with ID" <3.0.5.32.19980415115808.00a0b7a0@homebase.htt-consult.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > At 06:07 AM 4/15/98 -0700, pcalhoun@eng.sun.com wrote: > > >Not that I mean to be difficult here, but since the RADIUS WG has > shutdown, it > >may be more appropriate to add new functionality to the RADIUS replacement. > >There is work in progress on a protocol called DIAMETER. I hope to have a > BOF >at the Chicago IETF. > > Nor I. The IPsecers have learned that key negotiations need to be done in > a totally secure method. Roy's proposals are in this light. Also, next > week I and Ted will get started on the charter and the new work. Vendors > need a solution by end of summer. > > But Ted and I are not ruling out work elsewhere. Either the Radius or > Mobile stuff.... Robert, I am not quite sure what you meant here so I will simply expand to state that DIAMETER fixes many of the inherent problems that RADIUS has which would be critical in this application (i.e. AVP length, AVP address space allocation, etc). A DIAMETER server implementation will be made available for personal use from Merit Networks very soon. Actually, it has had support for an older version of the DIAMETER drafts for well over a year and I am in the process of cleaning it up to conform to the latest specs. I am not stating that it should be used for key negotiation, but if Policy Server support is required (which I can imagine it would for scalability purposes) I would like to propose DIAMETER. I would be happy to have someone write whatever extensions are required for the IPSEC WG and can help in this area if need be. PatC From owner-ipsec Wed Apr 15 13:54:09 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA02933 for ipsec-outgoing; Wed, 15 Apr 1998 13:52:38 -0400 (EDT) Date: Wed, 15 Apr 98 18:52:40 WET DST From: Pasvorn Boonmark To: Badri Ghimire Cc: Naganand Doraswamy , ipsec@tis.com, mpls@external.cisco.com, ietf-ppp@merit.edu, int-serv@isi.edu Subject: Re: VPN mailing list In-Reply-To: Your message of Wed, 15 Apr 1998 09:33:03 +0545 (NPT) Message-ID: Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Hi, > > I'm trying to implement VPDN( Virtual Private Dialup Network) with Cisco > routers and having a hard time. Can anyone point me to a right resources > ( Mailing list, URL etc ) for it, mailing list would be the best. Any > pointer on this would be highly appreciated. > > Thanks. > > > > Have you looked at the cco.cisco.com? You can send e-mail to "tac@cisco.com" to request for a case, or alternatively send e-mail to Cisco users mailing list "cisco@spot.colorado.edu" From owner-ipsec Wed Apr 15 18:21:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA04780 for ipsec-outgoing; Wed, 15 Apr 1998 18:16:38 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF03EDDD@exchange.timestep.com.219.168.192.in-addr.arpa> From: Roy Pereira To: "pcalhoun@eng.sun.com" , Robert Moskowitz Cc: Leonard Schwartz , "'ipsec@tis.com'" Subject: RE: Radius authentication and client configuration Date: Wed, 15 Apr 1998 18:31:27 -0400 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 The draft in question has the ability to support more than just RADIUS and adding support for DIAMETER would not be a problem. > -----Original Message----- > From: pcalhoun@eng.sun.com [mailto:Patrice.Calhoun@Eng.Sun.COM] > Sent: Wednesday, April 15, 1998 9:07 AM > To: Robert Moskowitz > Cc: Leonard Schwartz; Roy Pereira; 'ipsec@tis.com' > Subject: Re: Radius authentication and client configuration > > > > At 10:11 AM 4/13/98 -0400, Leonard Schwartz wrote: > > > > > >There are 2 drafts that by introducing a number of > additions to ISAKMP > > >main mode exchange attempt to standardize the process: > > >- Extended Authentication Within ISAKMP/Oakley > > > and > > >- The ISAKMP Configuration Method > > > > > > > >Is IPsec working group attempts to standardize these 2 > drafts to solve > > >the problem of Radius authentication and client configuration? Or > > >perhaps, there are other alternatives that must be examined? > > > > As discussed at IETF, this issue, and these documents will > be part of the > > re-chartering of IPsec. They are important... > > > > > > Robert Moskowitz > > ICSA > > Security Interest EMail: rgm-sec@htt-consult.com > Not that I mean to be difficult here, but since the RADIUS WG > has shutdown, it > may be more appropriate to add new functionality to the > RADIUS replacement. > There is work in progress on a protocol called DIAMETER. I > hope to have a BOF > at the Chicago IETF. > > PatC > From owner-ipsec Wed Apr 15 19:38:02 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA05178 for ipsec-outgoing; Wed, 15 Apr 1998 19:35:40 -0400 (EDT) Date: Wed, 15 Apr 1998 16:48:34 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: RE: Radius authentication and client configuration To: Roy Pereira Cc: "pcalhoun@eng.sun.com" , Robert Moskowitz , Leonard Schwartz , "'ipsec@tis.com'" In-Reply-To: "Your message with ID" <319A1C5F94C8D11192DE00805FBBADDF03EDDD@exchange.timestep.com.219.168.192.in-addr.arpa> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > The draft in question has the ability to support more than just RADIUS > and adding support for DIAMETER would not be a problem. Great! PatC From owner-ipsec Thu Apr 16 10:14:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA11010 for ipsec-outgoing; Thu, 16 Apr 1998 10:10:40 -0400 (EDT) Message-Id: <199804161410.KAA11010@portal.ex.tis.com> X-Sender: rgm-icsa@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 09 Apr 1998 16:09:59 -0400 To: CJ Gibson , ipsec@tis.com, ipsec@ns.ncsa.com From: Robert Moskowitz Subject: Re: [ipsec] FW: Key Recovery Cc: margaret , prashant In-Reply-To: <0171F2F8F9E5D011A4D10060B03CFB440CAF1C@scc-server3.semapho recom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 12:00 PM 4/9/98 -0700, CJ Gibson wrote: I would recommend not to touch this approach to Key recovery. It alters IKE. Vach Kompella (kompella@us.ibm.com) has a proposal to vendors to use an ICMP message to the KRC. This approach is orthogonal to IKE and thus can be delevoped on a vendor by vendor basis. >Can anybody out there help us with this issue of Key Recovery ?? Have >any of you decided to implement this ?? >Thanks in advance, > CJ > >-----Original Message----- >From: CJ Gibson [SMTP:cjgibson@semaphorecom.com] >Sent: Thursday, April 09, 1998 11:52 AM >To: Margaret Gaynes >Cc: cj; Roger Wang >Subject: RE: Key Recovery > >Reply at bottom of note.. > -----Original Message----- > From: Margaret Gaynes [SMTP:mgaynes@semaphorecom.com] > Sent: Thursday, April 09, 1998 11:11 AM > To: CJ > Cc: Roger Wang > Subject: Key Recovery > >By the end of the year we have to implement Key Recovery using >the TIS >RecoverKey tool kit. The way it works is that each encrypted >packet has >a Key Recovery Field (KRF) that travels with the encrypted data. >It is >the session key and recovery info encrypted with the public RSA >key of >the Key Recovery Center (KRC). If the key needs to be recovered, >it can >only be done with the private key of the KRC. You have to prove >to the >KRC with a subpoena or whatever that you are entitled to the data. >For FR and SMDS adding this data to the packet is no problem >because we >control the packet contents. However, how does this fit in with >IPSEC >and IKE? >Is there an IKE option that says "TIS key recovery" packet format? > > > >Not that I know of. I'll send this out on the IPSEC list to see what >others are doing... >--CJ > Robert Moskowitz International Computer Security Association (248) 968-9809 Fax: (248) 968-2824 rgm@icsa.net From owner-ipsec Thu Apr 16 10:14:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA11009 for ipsec-outgoing; Thu, 16 Apr 1998 10:10:40 -0400 (EDT) Message-Id: <199804161410.KAA11009@portal.ex.tis.com> Date: Thu, 9 Apr 1998 12:42:36 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: a simple question, I hope. Why do we need tunnel mode? To: Pyda Srisuresh Cc: Stephen Waters , ipsec@tis.com, Mark.Gillott@digital.com, kiely@marvin.reo.dec.com In-Reply-To: "Your message with ID" <199804091658.JAA11472@server.livingston.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk > > My thinking similar. > > IP-in-IP mode of transport is a solution to get around enterprise > firewall scrutiny. However, IPSec is not limited to this type of > transport alone. Specifically, L2TP tunnels are equally good candidates > for IPSec in the remote access realm of security solutions. So, I dont > see a need to categorize "IP-in-IP Tunnel Mode" as a distinct type of > security. Transport mode security does cover the Ip-in-IP tunnel mode, > as a special case. > > cheers, > suresh > You may also want to take a look at draft-ietf-mobileip-calhoun-tep-01.txt which defines Multi-Protocol extensions for Mobile IP. This has the advantage of being a multi-protocol layer 3 tunnel as opposed to layer 2. IP-in-IP is already defined in RFC2003. PatC From owner-ipsec Thu Apr 16 10:14:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA11087 for ipsec-outgoing; Thu, 16 Apr 1998 10:14:40 -0400 (EDT) Message-Id: <199804161414.KAA11087@portal.ex.tis.com> From: "Patel, Baiju V" To: "'iesg@ietf.org'" , "'ipsec@tis.com'" Cc: "Patel, Baiju V" Subject: RE: Last Call for IPSEC Date: Thu, 9 Apr 1998 14:28:21 -0700 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 Here is my analysis of why AH adds no security value over ESP with NULL encryption in case of IP v4. I do believe that similar story exists for IP v6. Therefore, unless one can clearly identify the value of using AH over ESP with NULL encryption, we MUST not define two standards with are functionally equivalent and yet are different (AH is more complex to implement and is a layering violation). Basics: 1. Any node/system/router/firewall cannot associate any IPSEC security properties to a packet unless it knows of the security association. 2. The failed integrity check does not provide any information on why it failed. All that can be determined is, did the packet pass the integrity check or not. 3. When the integrity check fails, the prudent action is to discard the packet and possibly log information. If any part of IP payload is compromised, both IPSEC AH or ESP with NULL encryption will result in failed integrity check by any entity that has knowledge of SA. Therefore, AH may have additional value when parts of IP header (non-mutable part) are modified. In the following, I am going to consider each part of the IP packet that is protected only by AH and not by ESP with NULL encryption and show that the end results are same. And therefore, establish that there is no additional value of using AH over ESP. The following analysis assumes that a packet protected with ESP using NULL encryption is being processed by a node that knows of SA. This covers all parts of IP packet that are protected by AH and not by ESP. 1. Destination address: The destination address is part of SA. Therefore, it is not possible for the recipient of the packet to correctly identify SA used to protect the packet, and thus, ESP integrity check will fail. 2. Source address: As defined in the IPSEC Arch document, SA database includes this information, and therefore, when compared with expected source address for the SA, any change in the source address will be detected (thus, integrity violation will be detected). 3. IP Version: When changed, it will be processed by non-IP v4 part of stack. So, it will be dropped because of incorrect version number, or lack of SA for that version number, or failure to process packet. 4. IP Header length: If just the length is changed, it will not be possible to find SPI and therefore, SA lookup will fails, and thus, packet will not be accepted. If options are added, (e.g., trace route, source route etc.), any router that does not know SA will process them anyway (ESP or AH) because they cannot detect. The systems that know SA will not know if these options are added when ESP is used while AH is used, only detection is that integrity cannot be verified. I do not see a security advantage here to mandate AH because of this. 5. If total length is changed, put not the packet, it will be detected because either lengths do not add up or data is changed. 6. Identification: If ID of a packet is changed, but packet is not fragmented, it has no security threat because ID has value in reassmebly. If packet is fragmented, then reassembly of packets may be flawed. In that case the integrity check on the packet will fail. 7. If protocol field is changed, SA lookup will result in the SA that was used to protect the packet. So, integrity will not be verified. 8. Immutable Options: a. Internet security options: (these are obsolete but still in use, as specified in AH document). IPSEC is designed to meets security needs at IP layer, so, what is the additional security value of using these options? Moreover, if these options are compromised, and that can result in weaker security, are they really providing security? (also note they are obsolete). In conclusion, While using IPSEC, if we still need these options, and they need to be protected, IPSEC is not meeting security requirements. I do believe that IPSEC does meet the security requirements and therefore, there is no additional value in protecting these options. (note that in tunnel mode they will be protected anyway). b. router alert: again, if a router also knows the SA for some reason, it may be able to detect that someone has modified this option. Does that improve security (frankly, look at who uses these and then determine the value. Note that protocols such RSVP use router alerts but they also define their own security protocol. c. If sender directed multidestination delivery option is modified, such that the packet is delivered to a destination that does not know of SA, SA lookup will fail and packet will be dropped. Unless technical flaws are identified with above analysis, it is my recommendation that we do not standardize two security protocols at the same time and burden the community with this legacy. We drop AH from IPSEC for IP v4 and possibly from IP v6. Baiju -------------------- PS: By the way, ESP in tunnel mode actually protects all the fields of the inner IP header. Therefore, it does protect everything that AH protects. So, there are three ways of achieving same security objectives: 1. AH 2. ESP with NULL encryption 3. ESP in tunnel mode (inner and outer headers are identical) Why so many standard but different ways to skin the cat! From owner-ipsec Thu Apr 16 10:18:57 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA11173 for ipsec-outgoing; Thu, 16 Apr 1998 10:18:40 -0400 (EDT) Message-Id: <199804161418.KAA11173@portal.ex.tis.com> From: "Patel, Baiju V" To: "'iesg@ietf.org'" , "'ipsec@tis.com'" Subject: Last Call for IPSEC (repeat post) Date: Fri, 10 Apr 1998 08:05:24 -0700 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 Sorry for sending this again (It did not make it back to me so I figured, others may not have received it). Baiju -----Original Message----- From: Patel, Baiju V Sent: Thursday, April 09, 1998 2:28 PM To: 'iesg@ietf.org'; 'ipsec@tis.com' Cc: Patel, Baiju V Subject: RE: Last Call for IPSEC Here is my analysis of why AH adds no security value over ESP with NULL encryption in case of IP v4. I do believe that similar story exists for IP v6. Therefore, unless one can clearly identify the value of using AH over ESP with NULL encryption, we MUST not define two standards with are functionally equivalent and yet are different (AH is more complex to implement and is a layering violation). Basics: 1. Any node/system/router/firewall cannot associate any IPSEC security properties to a packet unless it knows of the security association. 2. The failed integrity check does not provide any information on why it failed. All that can be determined is, did the packet pass the integrity check or not. 3. When the integrity check fails, the prudent action is to discard the packet and possibly log information. If any part of IP payload is compromised, both IPSEC AH or ESP with NULL encryption will result in failed integrity check by any entity that has knowledge of SA. Therefore, AH may have additional value when parts of IP header (non-mutable part) are modified. In the following, I am going to consider each part of the IP packet that is protected only by AH and not by ESP with NULL encryption and show that the end results are same. And therefore, establish that there is no additional value of using AH over ESP. The following analysis assumes that a packet protected with ESP using NULL encryption is being processed by a node that knows of SA. This covers all parts of IP packet that are protected by AH and not by ESP. 1. Destination address: The destination address is part of SA. Therefore, it is not possible for the recipient of the packet to correctly identify SA used to protect the packet, and thus, ESP integrity check will fail. 2. Source address: As defined in the IPSEC Arch document, SA database includes this information, and therefore, when compared with expected source address for the SA, any change in the source address will be detected (thus, integrity violation will be detected). 3. IP Version: When changed, it will be processed by non-IP v4 part of stack. So, it will be dropped because of incorrect version number, or lack of SA for that version number, or failure to process packet. 4. IP Header length: If just the length is changed, it will not be possible to find SPI and therefore, SA lookup will fails, and thus, packet will not be accepted. If options are added, (e.g., trace route, source route etc.), any router that does not know SA will process them anyway (ESP or AH) because they cannot detect. The systems that know SA will not know if these options are added when ESP is used while AH is used, only detection is that integrity cannot be verified. I do not see a security advantage here to mandate AH because of this. 5. If total length is changed, put not the packet, it will be detected because either lengths do not add up or data is changed. 6. Identification: If ID of a packet is changed, but packet is not fragmented, it has no security threat because ID has value in reassmebly. If packet is fragmented, then reassembly of packets may be flawed. In that case the integrity check on the packet will fail. 7. If protocol field is changed, SA lookup will result in the SA that was used to protect the packet. So, integrity will not be verified. 8. Immutable Options: a. Internet security options: (these are obsolete but still in use, as specified in AH document). IPSEC is designed to meets security needs at IP layer, so, what is the additional security value of using these options? Moreover, if these options are compromised, and that can result in weaker security, are they really providing security? (also note they are obsolete). In conclusion, While using IPSEC, if we still need these options, and they need to be protected, IPSEC is not meeting security requirements. I do believe that IPSEC does meet the security requirements and therefore, there is no additional value in protecting these options. (note that in tunnel mode they will be protected anyway). b. router alert: again, if a router also knows the SA for some reason, it may be able to detect that someone has modified this option. Does that improve security (frankly, look at who uses these and then determine the value. Note that protocols such RSVP use router alerts but they also define their own security protocol. c. If sender directed multidestination delivery option is modified, such that the packet is delivered to a destination that does not know of SA, SA lookup will fail and packet will be dropped. Unless technical flaws are identified with above analysis, it is my recommendation that we do not standardize two security protocols at the same time and burden the community with this legacy. We drop AH from IPSEC for IP v4 and possibly from IP v6. Baiju -------------------- PS: By the way, ESP in tunnel mode actually protects all the fields of the inner IP header. Therefore, it does protect everything that AH protects. So, there are three ways of achieving same security objectives: 1. AH 2. ESP with NULL encryption 3. ESP in tunnel mode (inner and outer headers are identical) Why so many standard but different ways to skin the cat! From owner-ipsec Thu Apr 16 10:23:49 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA11284 for ipsec-outgoing; Thu, 16 Apr 1998 10:23:41 -0400 (EDT) Message-Id: <199804161423.KAA11284@portal.ex.tis.com> Date: Wed, 15 Apr 1998 14:42:16 -0400 From: Shawn Mamros X-Mailer: Mozilla 4.0 [en] (WinNT; U) MIME-Version: 1.0 To: "pcalhoun@eng.sun.com" CC: "'ipsec@tis.com'" Subject: Re: Radius authentication and client configuration X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > I am not stating that it should be used for key negotiation, but if Policy > Server support is required (which I can imagine it would for scalability > purposes) I would like to propose DIAMETER. I would be happy to have someone > write whatever extensions are required for the IPSEC WG and can help in this > area if need be. One problem which arises in certain situations is that policy/configuration information may be needed *before* an IPSEC SA can be established. And until the IPSEC SAs are set up, it may not be possible to trust that protocols other than ISAKMP are properly secured. So, there's a bit of a Catch 22 in doing anything outside of the context of ISAKMP. By placing policy/configuration setup in ISAKMP (between Phases 1 and 2) under protection of the ISAKMP SA, Roy's proposal for an ISAKMP Configuration Method addresses the security needs quite nicely. That's not to say that one couldn't base the payload/exchange format on DIAMETER or whatever else is already out there. But the ISAKMP SA only protects ISAKMP, and until the IPSEC SAs are set up, ISAKMP may very well be all you can trust. -Shawn Mamros E-mail to: smamros@BayNetworks.com From owner-ipsec Thu Apr 16 11:45:01 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA12014 for ipsec-outgoing; Thu, 16 Apr 1998 11:43:43 -0400 (EDT) Date: Thu, 16 Apr 1998 08:50:06 -0700 (PDT) From: Gabriel Montenegro Reply-To: Gabriel Montenegro Subject: Re: Radius authentication and client configuration To: Shawn Mamros Cc: "pcalhoun@eng.sun.com" , "'ipsec@tis.com'" In-Reply-To: "Your message with ID" <199804161423.KAA11284@portal.ex.tis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > By placing policy/configuration setup in ISAKMP (between Phases 1 and 2) > under protection of the ISAKMP SA, Roy's proposal for an ISAKMP Configuration > Method addresses the security needs quite nicely. That's not to say that > one couldn't base the payload/exchange format on DIAMETER or whatever else > is already out there. But the ISAKMP SA only protects ISAKMP, and until the > IPSEC SAs are set up, ISAKMP may very well be all you can trust. Agree. It seems like the *cfg* and *xauth* drafts may just take existing payloads defined elsewhere to achieve their purposes. For example, xauth could just say: let's use EAP payloads (as I suggested in LA). EAP did start in ppp land, but has since been applied to (that is, its payloads have been reused in) SOCKS, RADIUS, DIAMETER. So yes, if a good payload exists, reuse it. -gabriel From owner-ipsec Thu Apr 16 12:47:24 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA12458 for ipsec-outgoing; Thu, 16 Apr 1998 12:43:39 -0400 (EDT) Message-Id: <3.0.5.32.19980416125215.00a66c70@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 16 Apr 1998 12:52:15 -0400 To: Shawn Mamros , "pcalhoun@eng.sun.com" From: Robert Moskowitz Subject: Re: Radius authentication and client configuration Cc: "'ipsec@tis.com'" In-Reply-To: <199804161423.KAA11284@portal.ex.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 02:42 PM 4/15/98 -0400, Shawn Mamros wrote: Shawn, thank you for re-capping part of the discussion at IETF for the list. Next week, when I get started on the new charter, words like this will be needed to scope the issues for policy/config information for IPsec. > >One problem which arises in certain situations is that policy/configuration >information may be needed *before* an IPSEC SA can be established. And >until the IPSEC SAs are set up, it may not be possible to trust that protocols >other than ISAKMP are properly secured. So, there's a bit of a Catch 22 >in doing anything outside of the context of ISAKMP. > >By placing policy/configuration setup in ISAKMP (between Phases 1 and 2) >under protection of the ISAKMP SA, Roy's proposal for an ISAKMP Configuration >Method addresses the security needs quite nicely. That's not to say that >one couldn't base the payload/exchange format on DIAMETER or whatever else >is already out there. But the ISAKMP SA only protects ISAKMP, and until >the IPSEC SAs are set up, ISAKMP may very well be all you can trust. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Thu Apr 16 14:45:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA13553 for ipsec-outgoing; Thu, 16 Apr 1998 14:43:39 -0400 (EDT) Message-Id: <3.0.5.32.19980416144543.00a6b2b0@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 16 Apr 1998 14:45:43 -0400 To: Gabriel Montenegro , Shawn Mamros From: Robert Moskowitz Subject: Re: Radius authentication and client configuration Cc: "pcalhoun@eng.sun.com" , "'ipsec@tis.com'" In-Reply-To: References: <"Your message with ID" <199804161423.KAA11284@portal.ex.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 08:50 AM 4/16/98 -0700, Gabriel Montenegro wrote: > >It seems like the *cfg* and *xauth* drafts may just take existing payloads >defined elsewhere to achieve their purposes. For example, xauth >could just say: let's use EAP payloads (as I suggested >in LA). EAP did start in ppp land, but has since been applied to >(that is, its payloads have been reused in) SOCKS, RADIUS, DIAMETER. > >So yes, if a good payload exists, reuse it. > Sounds like we are making some headway. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Thu Apr 16 16:17:52 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA14291 for ipsec-outgoing; Thu, 16 Apr 1998 16:15:39 -0400 (EDT) Date: Thu, 16 Apr 1998 13:28:41 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: Radius authentication and client configuration To: Gabriel Montenegro Cc: Shawn Mamros , "pcalhoun@eng.sun.com" , "'ipsec@tis.com'" In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > > By placing policy/configuration setup in ISAKMP (between Phases 1 and 2) > > under protection of the ISAKMP SA, Roy's proposal for an ISAKMP Configuration > > Method addresses the security needs quite nicely. That's not to say that > > one couldn't base the payload/exchange format on DIAMETER or whatever else > > is already out there. But the ISAKMP SA only protects ISAKMP, and until the > > IPSEC SAs are set up, ISAKMP may very well be all you can trust. > > Agree. > > It seems like the *cfg* and *xauth* drafts may just take existing payloads > defined elsewhere to achieve their purposes. For example, xauth > could just say: let's use EAP payloads (as I suggested > in LA). EAP did start in ppp land, but has since been applied to > (that is, its payloads have been reused in) SOCKS, RADIUS, DIAMETER. > > So yes, if a good payload exists, reuse it. > > -gabriel > I would like to second Gabriel's statement here. I also would strongly favor the use of EAP as opposed to another mechanism. If you take a look at draft-calhoun-diameter-eap-01.txt and draft-ietf-radius-eap-02.txt you will see how EAP fits into the Policy infrastructure. In addition, my draft draft-ietf-aft-socks-eap-00.txt proves that EAP is not a PPP-only protocol and can be re-used in a variety of services. I would hope that IPSEC would be a good candidate. (btw, there already exists an ISAKMP extension to EAP that you may want to take a look at - draft-ietf-pppext-eapisakmp-00.txt). PatC From owner-ipsec Thu Apr 16 16:46:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA14510 for ipsec-outgoing; Thu, 16 Apr 1998 16:45:39 -0400 (EDT) Message-Id: <199804162059.QAA21574@jekyll.piermont.com> To: "Patel, Baiju V" cc: "'iesg@ietf.org'" , "'ipsec@tis.com'" Subject: Re: Last Call for IPSEC In-reply-to: Your message of "Thu, 09 Apr 1998 14:28:21 PDT." <199804161414.KAA11087@portal.ex.tis.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, 16 Apr 1998 16:59:29 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk "Patel, Baiju V" writes: > Here is my analysis of why AH adds no security > value over ESP with NULL encryption in case of > IP v4. I do believe that similar story > exists for IP v6. Therefore, unless one can clearly > identify the value of using AH over ESP with NULL > encryption, we MUST not define two standards with are > functionally equivalent and yet are different > (AH is more complex to implement and is > a layering violation). I think it really doesn't matter at this point. Unless you can prove that AH is actually insecure, we've been at this too long not to progress the documents. We can easily reconsider the situation before we progress to draft. There is a reason we have two stages before full standardization. Perry From owner-ipsec Thu Apr 16 16:54:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA14587 for ipsec-outgoing; Thu, 16 Apr 1998 16:53:39 -0400 (EDT) Date: Thu, 16 Apr 1998 17:07:33 -0400 Message-Id: <9804162107.AA17957@kona.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ipsec@tis.com Subject: Weak keys X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk If I understand it correctly, the current IKE spec says that the keys for each of the transforms are taken from the start of the keying material, except for DES where you skip bytes until what you find isn't one of the weak or semi-weak keys listed. This doesn't seem to be complete, because it doesn't take into account the weak keys of other cryptosystems (such as 3DES, IDEA, and Blowfish). It also doesn't sound like it will interoperate if new weak keys are discovered and one side is updated to recognize those weak keys (since the two sides will extract different substrings from the keying material). After all, the listing of weak keys is subject to growth as more is learned about the systems in question. One possible interpretation: 1. the key extraction rules are exactly as specified and stay that way forever. 2. any other weak keys are handled by rekeying immediately. Is that the intent? If not, how are weak keys handled? paul -- !----------------------------------------------------------------------- ! Paul Koning, NI1D, C-24183 ! Xedia Corporation, 119 Russell Street, Littleton, MA 01460, USA ! phone: +1 978 952 6000 ext 115, fax: +1 978 952 6090 ! email: pkoning@xedia.com ! Pgp: 27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75 !----------------------------------------------------------------------- ! "The only purpose for which power can be rightfully exercised over ! any member of a civilized community, against his will, is to prevent ! harm to others. His own good, either physical or moral, is not ! a sufficient warrant." -- John Stuart Mill, "On Liberty" 1859 From owner-ipsec Thu Apr 16 17:37:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA14846 for ipsec-outgoing; Thu, 16 Apr 1998 17:36:38 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF03EFCD@exchange.timestep.com.219.168.192.in-addr.arpa> From: Roy Pereira To: Gabriel Montenegro , Shawn Mamros Cc: "pcalhoun@eng.sun.com" , "'ipsec@tis.com'" Subject: RE: Radius authentication and client configuration Date: Thu, 16 Apr 1998 17:28:37 -0400 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 Your comments are correct and what I would like to do is to generalize the Extended Authentication draft by defining how this extra authentication can happen in all applications and then include an appendix on how to use it inside ISAKMP. But, you may say, EAP already does this... After reading EAP many times now, I still believe that it is not as powerful as XAUTH (draft-ietf-ipsec-isakmp-xauth-01.txt). While it uses the same mechanisms (request/reply) as in XAUTH and some of the same authentication mechanisms, it doesn't allow for some of the flexibility of XAUTH. Here are some of my concerns with EAP: - EAP currently uses an 8-bit identifier. I believe this is too small and will lead to overlap on very busy servers. XAUTH uses 16 bits. - Only one data type may be requested/replied within one payload. XAUTH allows for multiple data types to be sent across within one payload. For example, when using RADIUS authentication, the mobile client sends back his user name and his password all in the same reply message in two data types (attributes). - EAP doesn't allow for multiple authentication requests within the same authentication. SecureID has a NextPIN mode that requests the next passcode from the card after the first passcode was verified. This adds extra confidence that the user really is in possession of the card. - EAP uses different format for each data type while XAUTH uses standard attributes formats for all data types. - Some requests/replies in EAP are not specified in great detail. Take for instance the Generic Token Card; The data isn't defined very well. You will need their user id (if you haven't gotten it from somewhere else), their password and then the token card's passcode. The current EAP document doesn't state any of this and thus prevents the use of EAP in an implementation. Let me just state that I don't care what mechanism we (IPSec working group) use to accomplish this problem, just that it is a standard mechanism and it works correctly. > -----Original Message----- > From: Gabriel Montenegro [mailto:gab@Eng.Sun.Com] > Sent: Thursday, April 16, 1998 11:50 AM > To: Shawn Mamros > Cc: pcalhoun@eng.sun.com; 'ipsec@tis.com' > Subject: Re: Radius authentication and client configuration > > > > By placing policy/configuration setup in ISAKMP (between > Phases 1 and 2) > > under protection of the ISAKMP SA, Roy's proposal for an > ISAKMP Configuration > > Method addresses the security needs quite nicely. That's > not to say that > > one couldn't base the payload/exchange format on DIAMETER > or whatever else > > is already out there. But the ISAKMP SA only protects > ISAKMP, and until the > > IPSEC SAs are set up, ISAKMP may very well be all you can trust. > > Agree. > > It seems like the *cfg* and *xauth* drafts may just take > existing payloads > defined elsewhere to achieve their purposes. For example, xauth > could just say: let's use EAP payloads (as I suggested > in LA). EAP did start in ppp land, but has since been applied to > (that is, its payloads have been reused in) SOCKS, RADIUS, DIAMETER. > > So yes, if a good payload exists, reuse it. > > -gabriel > From owner-ipsec Thu Apr 16 17:55:16 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA14990 for ipsec-outgoing; Thu, 16 Apr 1998 17:54:40 -0400 (EDT) Date: Thu, 16 Apr 1998 15:07:16 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: Radius authentication and client configuration To: Vipul Gupta Cc: Patrice.Calhoun@Eng.Sun.Com, smamros@BayNetworks.COM, gab@Eng.Sun.Com, ipsec@tis.com, periera@TimeStep.com, rgm-sec@htt-consult.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > > > > > It seems like the *cfg* and *xauth* drafts may just take existing > payloads > > defined elsewhere to achieve their purposes. For example, xauth > > > could just say: let's use EAP payloads (as I suggested > > > in LA). EAP did start in ppp land, but has since been applied to > > > (that is, its payloads have been reused in) SOCKS, RADIUS, DIAMETER. > > > > > > So yes, if a good payload exists, reuse it. > > > > > > -gabriel > > > > > I would like to second Gabriel's statement here. I also would strongly favor > > the use of EAP as opposed to another mechanism. If you take a look at > > draft-calhoun-diameter-eap-01.txt and draft-ietf-radius-eap-02.txt you will > > see how EAP fits into the Policy infrastructure. > > > > In addition, my draft draft-ietf-aft-socks-eap-00.txt proves that EAP is not a > > PPP-only protocol and can be re-used in a variety of services. I would hope > > that IPSEC would be a good candidate. (btw, there already exists an ISAKMP > > extension to EAP that you may want to take a look at - > > draft-ietf-pppext-eapisakmp-00.txt). > > > > PatC > > > > IMO, draft-ietf-pppext-eapisakmp-00.txt solves a different problem > than what Roy's *xauth* draft is addressing. With most other > EAP methods (e.g. token cards), only one of the parties is authenticated > (client to the server but not mutual authentication) and > *pppext-eapisakmp-* > and *pppext-eaptls-02.txt are attempts to fix that. > > Roy's draft, on the other hand, is trying to tie in existing > *user authentication* mechanisms (like OTPs and Token cards) with > IPSec. > > vipul Agreed. I threw out the eap-isakmp draft in order to make the list aware of it. As for Roy's intent to tie it in with existing token/smart cards I would not recommend this. The problem that we are currently faced with is that it requires vendors to include proprietary code from token/smart card vendors and ties them into a single solution. EAP will provide vendors with the ability to support ANY token/smart cards that support EAP. PatC From owner-ipsec Thu Apr 16 18:02:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA15004 for ipsec-outgoing; Thu, 16 Apr 1998 18:00:40 -0400 (EDT) Date: Thu, 16 Apr 1998 15:10:25 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: RE: Radius authentication and client configuration To: Roy Pereira Cc: Gabriel Montenegro , Shawn Mamros , "pcalhoun@eng.sun.com" , "'ipsec@tis.com'" In-Reply-To: "Your message with ID" <319A1C5F94C8D11192DE00805FBBADDF03EFCD@exchange.timestep.com.219.168.192.in-addr.arpa> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > Your comments are correct and what I would like to do is to generalize > the Extended Authentication draft by defining how this extra > authentication can happen in all applications and then include an > appendix on how to use it inside ISAKMP. > > But, you may say, EAP already does this... > > After reading EAP many times now, I still believe that it is not as > powerful as XAUTH (draft-ietf-ipsec-isakmp-xauth-01.txt). While it uses > the same mechanisms (request/reply) as in XAUTH and some of the same > authentication mechanisms, it doesn't allow for some of the flexibility > of XAUTH. > > Here are some of my concerns with EAP: > > - EAP currently uses an 8-bit identifier. I believe this is too small > and will lead to overlap on very busy servers. XAUTH uses 16 bits. > > - Only one data type may be requested/replied within one payload. > XAUTH allows for multiple data types to be sent across within one > payload. For example, when using RADIUS authentication, the mobile > client sends back his user name and his password all in the same reply > message in two data types (attributes). > > - EAP doesn't allow for multiple authentication requests within the > same authentication. SecureID has a NextPIN mode that requests the next > passcode from the card after the first passcode was verified. This adds > extra confidence that the user really is in possession of the card. > > - EAP uses different format for each data type while XAUTH uses > standard attributes formats for all data types. > > - Some requests/replies in EAP are not specified in great detail. Take > for instance the Generic Token Card; The data isn't defined very well. > You will need their user id (if you haven't gotten it from somewhere > else), their password and then the token card's passcode. The current > EAP document doesn't state any of this and thus prevents the use of EAP > in an implementation. > > Let me just state that I don't care what mechanism we (IPSec working > group) use to accomplish this problem, just that it is a standard > mechanism and it works correctly. If EAP needs to be fixed, this is the right time. It is currently sitting on the IESG's pending list and if changes are needed we need to bring them up. I personally would like to see EAP be used in a wide variety of access schemes (i.e. PPP, SOCKS, IPSEC, Voice/IP, etc). PatC From owner-ipsec Thu Apr 16 18:22:05 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA15148 for ipsec-outgoing; Thu, 16 Apr 1998 18:18:40 -0400 (EDT) Message-Id: <199804162232.PAA06688@gallium.network-alchemy.com> To: Paul Koning cc: ipsec@tis.com Subject: Re: Weak keys In-reply-to: Your message of "Thu, 16 Apr 1998 17:07:33 EDT." <9804162107.AA17957@kona.xedia.com> Date: Thu, 16 Apr 1998 15:32:21 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk >If I understand it correctly, the current IKE spec says that the keys >for each of the transforms are taken from the start of the keying >material, except for DES where you skip bytes until what you find >isn't one of the weak or semi-weak keys listed. This section applies to IKE's use of the Phase 1 ciphers defined in the IKE document. Note that the Phase 2 IPSEC architecture leaves the definition of what is a weak key to the particular cipher transform documents. In the case of a Phase 2 weak key, what happens must also be defined in the relevant transform description. >It also doesn't sound like it will interoperate if new weak keys are >discovered and one side is updated to recognize those weak keys (since >the two sides will extract different substrings from the keying >material). After all, the listing of weak keys is subject to growth >as more is learned about the systems in question. The side that's been updated could just initiate a new rekey, assuming that the other side wouldn't be smart enough to do so. In thinking about the version number in the ISAKMP header, this brings up an interesting point. The ISAKMP version number is said (in the ISAKMP document) to represent the packet and protocol versioning for the ISAKMP payloads and exchanges. Yet, it seems to me that it really needs to represent not just ISAKMP but also the IKE protocol version and maybe the DOI version as well. Derrell From owner-ipsec Thu Apr 16 18:27:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA15207 for ipsec-outgoing; Thu, 16 Apr 1998 18:25:39 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF03EFF6@exchange.timestep.com.219.168.192.in-addr.arpa> From: Roy Pereira To: "pcalhoun@eng.sun.com" , Gabriel Montenegro Cc: Shawn Mamros , "'ipsec@tis.com'" Subject: RE: Radius authentication and client configuration Date: Thu, 16 Apr 1998 18:28:30 -0400 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 > (btw, there already > exists an ISAKMP > extension to EAP that you may want to take a look at - > draft-ietf-pppext-eapisakmp-00.txt). This document describes how to use ISAKMP as the authentication mechanism and NOT as the transport mechanism. It would be very funny to use EAP with ISAKMP as the transport and the authentication. Infinite loop.... From owner-ipsec Thu Apr 16 18:35:23 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA15259 for ipsec-outgoing; Thu, 16 Apr 1998 18:33:39 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF03EFFA@exchange.timestep.com.219.168.192.in-addr.arpa> From: Roy Pereira To: "pcalhoun@eng.sun.com" , Vipul Gupta Cc: smamros@BayNetworks.COM, gab@Eng.Sun.Com, ipsec@tis.com, periera@TimeStep.com, rgm-sec@htt-consult.com Subject: RE: Radius authentication and client configuration Date: Thu, 16 Apr 1998 18:40:22 -0400 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 > As for Roy's intent to tie it in with existing > token/smart cards I would > not recommend this. The problem that we are currently faced > with is that it > requires vendors to include proprietary code from token/smart > card vendors and > ties them into a single solution. EAP will provide vendors > with the ability to > support ANY token/smart cards that support EAP. Not exactly what I meant. No proprietary code is required from token/smart card vendors in XAUTH. By establishing what type of data these authentication devices required, any card can be used. The authentication transport method that the security gateway uses might be proprietary, but that is the case with EAP as well (or any other authentication mechanism). From owner-ipsec Thu Apr 16 18:36:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA15267 for ipsec-outgoing; Thu, 16 Apr 1998 18:34:40 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF03EFFB@exchange.timestep.com.219.168.192.in-addr.arpa> From: Roy Pereira To: "pcalhoun@eng.sun.com" Cc: Gabriel Montenegro , Shawn Mamros , "'ipsec@tis.com'" Subject: RE: Radius authentication and client configuration Date: Thu, 16 Apr 1998 18:41:37 -0400 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 EAP needs to be fixed, this is the right time. It is > currently sitting on > the IESG's pending list and if changes are needed we need to > bring them up. I > personally would like to see EAP be used in a wide variety of > access schemes > (i.e. PPP, SOCKS, IPSEC, Voice/IP, etc). For a start it shouldn't be a "PPP" method if you are trying to make it available to other working groups and those working groups must have had some input before the document went out to the IESG. From owner-ipsec Thu Apr 16 21:02:32 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA16231 for ipsec-outgoing; Thu, 16 Apr 1998 20:58:40 -0400 (EDT) Date: Thu, 16 Apr 1998 21:12:17 -0400 Message-Id: <199804170112.VAA14509@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Karen Heron Cc: In-Reply-To: Karen Heron's message of Wed, 15 Apr 1998 07:49:03 -0400, <5040300014982482000002L022*@MHS> Subject: Re: Hop Limit in Inner Header (IPv6) Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk From: Karen Heron Date: Wed, 15 Apr 1998 07:49:03 -0400 In draft-ietf-ipsec-arch-sec-04, 5.1.2.2 IPv6 -- Header Construction for Tunnel Mode, the inner header Hop Limit is decremented. This will cause problems for securing IPv6 NDP traffic. The hop limit is set to 255 in NDP packets and checked in the receiving node to make sure it came from the same link. If this NDP exchange is secured using tunnel mode and the hop limit is decremented before the packet is encapsulated, the receiving node will reject the NDP packet and neighbor discovery will fail, even if the two nodes are on the same link. Should the Hop Limit not be decremented for locally generated traffic? If not, I don't see how NDP traffic can be secured using tunnel mode - maybe I've missed something in the drafts that said this. If this question has already been answered, I'd appreciate a pointer to the discussion (I didn't see it in the archives). Karen, I would think that if a packet originates at host A, and the packet then gets encapsulated by security gateway G and sent down the IPSEC tunnel to host B, that host A and host B are not on the same network. In fact, even if the packet is originated and encapsulated at host A, and sent over a IPSEC tunnel, which might send the packet halfway across the world, when it is decapsulated at host B, the hop count should be decremented, since it is extremely unlikely that they are really "neighbors". I'm not completely familiar with what exactly NDP is trying to do, but if you're using tunnel mode, you can't distinguish between whether your communications partner is on the same ethernet, or on the wrong side of MAE-EAST (you can tell that by the number of packets that get dropped, though :-). If this is what NDP is trying to do, then fundamentally you shouldn't be using tunnel mode. Whether you always decrement the hop count, as the spec currently states, or never decrement the hop count, you still don't know whether someone is next door or on the other side of the planet. - Ted From owner-ipsec Thu Apr 16 21:19:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA16377 for ipsec-outgoing; Thu, 16 Apr 1998 21:17:40 -0400 (EDT) Message-Id: <199804170127.VAA09270@postal.research.att.com> To: "Theodore Y. Ts'o" cc: Karen Heron , ipsec@tis.com Subject: Re: Hop Limit in Inner Header (IPv6) Date: Thu, 16 Apr 1998 21:27:05 -0400 From: Steve Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk From: Karen Heron Date: Wed, 15 Apr 1998 07:49:03 -0400 In draft-ietf-ipsec-arch-sec-04, 5.1.2.2 IPv6 -- Header Constructio n for Tunnel Mode, the inner header Hop Limit is decremented. This will cause problems for securing IPv6 NDP traffic. The hop limit i s set to 255 in NDP packets and checked in the receiving node to make sure it came from the same link. If this NDP exchange is secured using tunnel mode and the hop limit is decremented before the packe t is encapsulated, the receiving node will reject the NDP packet and neighbor discovery will fail, even if the two nodes are on the same link. Should the Hop Limit not be decremented for locally generate d traffic? If not, I don't see how NDP traffic can be secured using tunnel mode - maybe I've missed something in the drafts that said this. If this question has already been answered, I'd appreciate a pointer to the discussion (I didn't see it in the archives). Karen, I would think that if a packet originates at host A, and the packet then gets encapsulated by security gateway G and sent down the IPSEC tunnel to host B, that host A and host B are not on the same network. In fact, even if the packet is originated and encapsulated at host A, and sent over a IPSEC tunnel, which might send the packet halfway across the world, when it is decapsulated at host B, the hop count should be decremented, since it is extremely unlikely that they are really "neighbors". I'm not completely familiar with what exactly NDP is trying to do, but if you're using tunnel mode, you can't distinguish between whether your communications partner is on the same ethernet, or on the wrong side of MAE-EAST (you can tell that by the number of packets tha t get dropped, though :-). If this is what NDP is trying to do, then fundamentally you shouldn't be using tunnel mode. Whether you always decrement the hop count, as the spec currently states, or never decrement the hop count, you still don't know whether someone is next door or on the other side of the planet. My own view is that a tunnel is a virtual wire between two nodes. NDP should work across that tunnel only to the extent that the packet originated on one endpoint and terminated on the other. ("Neighbor" is a topological construct here, and ignores phyiscal reality.) From owner-ipsec Thu Apr 16 23:17:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA17127 for ipsec-outgoing; Thu, 16 Apr 1998 23:15:39 -0400 (EDT) Date: Thu, 16 Apr 1998 23:29:17 -0400 Message-Id: <199804170329.XAA14529@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "Patel, Baiju V" Cc: "'iesg@ietf.org'" , "'ipsec@tis.com'" , "Patel, Baiju V" In-Reply-To: Patel, Baiju V's message of Thu, 9 Apr 1998 14:28:21 -0700, <199804161414.KAA11087@portal.ex.tis.com> Subject: Re: Last Call for IPSEC Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk From: "Patel, Baiju V" Date: Thu, 9 Apr 1998 14:28:21 -0700 1. Destination address: The destination address is part of SA. Therefore, it is not possible for the recipient of the packet to correctly identify SA used to protect the packet, and thus, ESP integrity check will fail. 2. Source address: As defined in the IPSEC Arch document, SA database includes this information, and therefore, when compared with expected source address for the SA, any change in the source address will be detected (thus, integrity violation will be detected). The destination and source addresses in the SA may be a wildcard, or a range of addresses, not just a single address. Hence, changes to source and destination addresses may not be detected unless you are using something like AH to integrity protect these header values. 7. If protocol field is changed, SA lookup will result in the SA that was used to protect the packet. So, integrity will not be verified. The protocol field is not used to lookup the SA. The SPI is used to do that. a. Internet security options: (these are obsolete but still in use, as specified in AH document). IPSEC is designed to meets security needs at IP layer, so, what is the additional security value of using these options? Moreover, if these options are compromised, and that can result in weaker security, are they really providing security? (also note they are obsolete). In conclusion, While using IPSEC, if we still need these options, and they need to be protected, IPSEC is not meeting security requirements. I do believe that IPSEC does meet the security requirements and therefore, there is no additional value in protecting these options. (note that in tunnel mode they will be protected anyway). There are other security services which are orthagnonal to those which are provided by IPSEC. For example, IPSEC does not provide classification labeling. Whether or not such options are useful in general is another debate, although historically there have been a number of communities which have found such services useful. Your claim that IPSEC obsoletes all other IP Security options does not seem to make a prima facie case. Unless technical flaws are identified with above analysis, it is my recommendation that we do not standardize two security protocols at the same time and burden the community with this legacy. We drop AH from IPSEC for IP v4 and possibly from IP v6. At least a number of your arguments have very obvious flaws. In any case, this is an item which the working group has now revisited *three* times, most recently at the last IETF meeting in Los Angelos, where Jeff Schiller took a straw poll and found a clear consensus of the working group to not change the status of AH at this date. One would think that we have dealt with this issue enough at this point. It is hard, nay impossible, to make progress when we have to revisit an issue over and over again. At some point we have to say "enough" and move on. - Ted From owner-ipsec Fri Apr 17 00:31:54 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA17616 for ipsec-outgoing; Fri, 17 Apr 1998 00:30:41 -0400 (EDT) Date: Thu, 16 Apr 1998 23:45:52 -0500 (CDT) X-Sender: markham@mailhost.sctc.com Message-Id: In-Reply-To: <199804161410.KAA11010@portal.ex.tis.com> References: <0171F2F8F9E5D011A4D10060B03CFB440CAF1C@scc-server3.semapho recom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Robert Moskowitz From: Tom Markham Subject: Re: [ipsec] FW: Key Recovery Cc: CJ Gibson , ipsec@tis.com, ipsec@ns.ncsa.com, margaret , prashant Sender: owner-ipsec@ex.tis.com Precedence: bulk The key recovery alliance (www.kra.org) has developed an approach for performing key recovery in ISAKMP. The approach does not require communication with the key recovery center for each ISAKMP exchange. I expect that the key recovery alliance will be releasing the draft specification in about 1 month. Stay tuned. At 4:09 PM -0400 4/9/98, Robert Moskowitz wrote: >At 12:00 PM 4/9/98 -0700, CJ Gibson wrote: > >I would recommend not to touch this approach to Key recovery. It alters IKE. > >Vach Kompella (kompella@us.ibm.com) has a proposal to vendors to use an >ICMP message to the KRC. This approach is orthogonal to IKE and thus can >be delevoped on a vendor by vendor basis. > >>Can anybody out there help us with this issue of Key Recovery ?? Have >>any of you decided to implement this ?? >>Thanks in advance, >> CJ Tom Markham From owner-ipsec Fri Apr 17 01:02:31 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA17803 for ipsec-outgoing; Fri, 17 Apr 1998 01:01:44 -0400 (EDT) Date: Fri, 17 Apr 1998 01:15:31 -0400 Message-Id: <199804170515.BAA14572@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: Slides for the IPSEC wg meeting minutes Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk For those of you who gave presentations at the IPSEC wg meeting in LA, if you have postscript for any slides which you may have used during your presentations, and you haven't sent them to me yet, could you please do so in the near future? I am preparing the minutes for that meeting, and I like to include the postscript for slide presentations whenever possible. Many thanks!! - Ted From owner-ipsec Fri Apr 17 08:11:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA20564 for ipsec-outgoing; Fri, 17 Apr 1998 08:10:46 -0400 (EDT) Message-ID: <35368891.B4CB31CC@BayNetworks.com> Date: Thu, 16 Apr 1998 18:39:13 -0400 From: Shawn Mamros X-Mailer: Mozilla 4.0 [en] (WinNT; U) MIME-Version: 1.0 To: "pcalhoun@eng.sun.com" CC: Vipul Gupta , gab@Eng.Sun.Com, ipsec@tis.com, periera@TimeStep.com, rgm-sec@htt-consult.com Subject: Re: Radius authentication and client configuration X-Priority: 3 (Normal) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > Agreed. I threw out the eap-isakmp draft in order to make the list aware of > it. As for Roy's intent to tie it in with existing token/smart cards I would > not recommend this. The problem that we are currently faced with is that it > requires vendors to include proprietary code from token/smart card vendors and > ties them into a single solution. EAP will provide vendors with the ability to > support ANY token/smart cards that support EAP. One does not necessarily need proprietary code from the token/smart card vendors to make extended authentication work. As long as the token/smart card vendor provides a RADIUS, or EAP, or whatever front-end, one can write a matching back-end to make it work with the ISAKMP implementation. I know of at least one proof-by-existance... (One can argue whether or not such a solution is ideal from a security standpoint, but it does work.) -Shawn Mamros E-mail to: smamros@BayNetworks.com From owner-ipsec Fri Apr 17 08:11:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA20545 for ipsec-outgoing; Fri, 17 Apr 1998 08:08:46 -0400 (EDT) Date: Thu, 16 Apr 1998 14:34:07 -0700 (PDT) From: Vipul Gupta Reply-To: Vipul Gupta Subject: Re: Radius authentication and client configuration To: Patrice.Calhoun@Eng.Sun.Com Cc: smamros@BayNetworks.COM, gab@Eng.Sun.Com, ipsec@tis.com, periera@TimeStep.com, rgm-sec@htt-consult.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: p7V7t+Wo8NW+MOsXkjEUQg== X-Mailer: dtmail 1.1.0 CDE Version 1.1 SunOS 5.5.1 sun4u sparc Sender: owner-ipsec@ex.tis.com Precedence: bulk > > It seems like the *cfg* and *xauth* drafts may just take existing payloads > > defined elsewhere to achieve their purposes. For example, xauth > > could just say: let's use EAP payloads (as I suggested > > in LA). EAP did start in ppp land, but has since been applied to > > (that is, its payloads have been reused in) SOCKS, RADIUS, DIAMETER. > > > > So yes, if a good payload exists, reuse it. > > > > -gabriel > > > I would like to second Gabriel's statement here. I also would strongly favor > the use of EAP as opposed to another mechanism. If you take a look at > draft-calhoun-diameter-eap-01.txt and draft-ietf-radius-eap-02.txt you will > see how EAP fits into the Policy infrastructure. > > In addition, my draft draft-ietf-aft-socks-eap-00.txt proves that EAP is not a > PPP-only protocol and can be re-used in a variety of services. I would hope > that IPSEC would be a good candidate. (btw, there already exists an ISAKMP > extension to EAP that you may want to take a look at - > draft-ietf-pppext-eapisakmp-00.txt). > > PatC > IMO, draft-ietf-pppext-eapisakmp-00.txt solves a different problem than what Roy's *xauth* draft is addressing. With most other EAP methods (e.g. token cards), only one of the parties is authenticated (client to the server but not mutual authentication) and *pppext-eapisakmp-* and *pppext-eaptls-02.txt are attempts to fix that. Roy's draft, on the other hand, is trying to tie in existing *user authentication* mechanisms (like OTPs and Token cards) with IPSec. vipul From owner-ipsec Fri Apr 17 08:42:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA20940 for ipsec-outgoing; Fri, 17 Apr 1998 08:41:45 -0400 (EDT) Message-Id: <35375136.F94C3A95@xedia.com> Date: Fri, 17 Apr 1998 08:55:18 -0400 From: Leonard Schwartz Organization: Xedia Corp., X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.4 sun4m) Mime-Version: 1.0 To: "'ipsec@tis.com'" Subject: SA management Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk We would like to receive a clarification on one aspect of SA management. When SA's life time limit expires, a re-keying operation is initiated and another pair of SAs will be created. If however, both peers initiate re-keying operation simultaneously, in fact 2 pairs of SAs will be created. The question is what to do with extra pair of SAs? It seems that there are at least several alternatives: a) do nothing and use all 4 SAs for reception and transmission; b) select 1 outbound SA for transmission (for example, could be latest established) and remove all other outbound SAs. If the peer will perform the same operation on its side, only a pair of SAs will be in use; c) select 1 inbound SA, remove all other inbound SAs and send delete notification to the peer. If the peer will perform the same operation on its side, only a pair of SAs will be in use; There will be a problem however if one side chooses to implement scenario (b) and its peer chooses to implement scenario (c). Are there any guidelines that IPsec wants to recommend in situations like this one? Thanks, Leonard From owner-ipsec Fri Apr 17 08:59:32 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA21106 for ipsec-outgoing; Fri, 17 Apr 1998 08:58:48 -0400 (EDT) Date: Fri, 17 Apr 1998 06:08:11 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: RE: Radius authentication and client configuration To: Roy Pereira Cc: "pcalhoun@eng.sun.com" , Gabriel Montenegro , Shawn Mamros , "'ipsec@tis.com'" In-Reply-To: "Your message with ID" <319A1C5F94C8D11192DE00805FBBADDF03EFF6@exchange.timestep.com.219.168.192.in-addr.arpa> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > > (btw, there already > > exists an ISAKMP > > extension to EAP that you may want to take a look at - > > draft-ietf-pppext-eapisakmp-00.txt). > > This document describes how to use ISAKMP as the authentication > mechanism and NOT as the transport mechanism. > > It would be very funny to use EAP with ISAKMP as the transport and the > authentication. Infinite loop.... > I was simply trying to make the WG aware of the draft so that someone close to ISAKMP could review it. PatC From owner-ipsec Fri Apr 17 09:01:01 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA21153 for ipsec-outgoing; Fri, 17 Apr 1998 09:00:46 -0400 (EDT) Date: Fri, 17 Apr 1998 06:13:00 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: RE: Radius authentication and client configuration To: Roy Pereira Cc: "pcalhoun@eng.sun.com" , Gabriel Montenegro , Shawn Mamros , "'ipsec@tis.com'" In-Reply-To: "Your message with ID" <319A1C5F94C8D11192DE00805FBBADDF03EFFB@exchange.timestep.com.219.168.192.in-addr.arpa> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > > > If EAP needs to be fixed, this is the right time. It is > > currently sitting on > > the IESG's pending list and if changes are needed we need to > > bring them up. I > > personally would like to see EAP be used in a wide variety of > > access schemes > > (i.e. PPP, SOCKS, IPSEC, Voice/IP, etc). > > For a start it shouldn't be a "PPP" method if you are trying to make it > available to other working groups and those working groups must have had > some input before the document went out to the IESG. Agreed. Unfortunately I just recently started pushing harder on EAP within other WGs. I like the concept and, as an ex-router developer, the thought of not having to add proprietary code to an embedded device is really nice. It allows authentication to occur end-to-end between the user and the authentication server. As you stated in your previous mail (I believe it was you) it does require that the token/smart card vendor support the transport (RADIUS/DIAMETER) on their authentication server. As for getting input from other groups, the draft did go out for last call and did not receive any comments besides a small one regarding UTF-8. Just because it is a proposed standard does not mean that we cannot change it slightly in order to meet other WG's needs. PatC From owner-ipsec Fri Apr 17 09:04:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA21247 for ipsec-outgoing; Fri, 17 Apr 1998 09:03:45 -0400 (EDT) Date: Fri, 17 Apr 1998 06:15:36 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: RE: Radius authentication and client configuration To: Roy Pereira Cc: "pcalhoun@eng.sun.com" , Vipul Gupta , smamros@BayNetworks.COM, gab@Eng.Sun.Com, ipsec@tis.com, periera@TimeStep.com, rgm-sec@htt-consult.com In-Reply-To: "Your message with ID" <319A1C5F94C8D11192DE00805FBBADDF03EFFA@exchange.timestep.com.219.168.192.in-addr.arpa> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > > As for Roy's intent to tie it in with existing > > token/smart cards I would > > not recommend this. The problem that we are currently faced > > with is that it > > requires vendors to include proprietary code from token/smart > > card vendors and > > ties them into a single solution. EAP will provide vendors > > with the ability to > > support ANY token/smart cards that support EAP. > > Not exactly what I meant. No proprietary code is required from > token/smart card vendors in XAUTH. By establishing what type of data > these authentication devices required, any card can be used. The > authentication transport method that the security gateway uses might be > proprietary, but that is the case with EAP as well (or any other > authentication mechanism). You are right. I should have read your draft before commenting. I will do that now... PatC (So many drafts, so little time) From owner-ipsec Fri Apr 17 09:53:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA21755 for ipsec-outgoing; Fri, 17 Apr 1998 09:52:32 -0400 (EDT) Date: Fri, 17 Apr 1998 10:07:15 -0400 Message-Id: <199804171407.KAA14605@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "Derrell D. Piper" Cc: Paul Koning , ipsec@tis.com In-Reply-To: Derrell D. Piper's message of Thu, 16 Apr 1998 15:32:21 -0700, <199804162232.PAA06688@gallium.network-alchemy.com> Subject: Re: Weak keys Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Thu, 16 Apr 1998 15:32:21 -0700 From: "Derrell D. Piper" >It also doesn't sound like it will interoperate if new weak keys are >discovered and one side is updated to recognize those weak keys (since >the two sides will extract different substrings from the keying >material). After all, the listing of weak keys is subject to growth >as more is learned about the systems in question. The side that's been updated could just initiate a new rekey, assuming that the other side wouldn't be smart enough to do so. This works. I would also point out that an algorithm like DES has received enough attention from the cryptographic comminity that it is unlikely that new weak keys will be found. There may be new attacks which might make us decide not to use the algorithm at all, but weak keys tend to be relatively early in the life cycle --- ideally before the algorithm is published, if there has been sufficient prepublication review. If we're using relatively new ciphers that aren't proven, then that's much more of an issue. Currently in IKE there is no mention of needing to do anything with weak keys for anything other than DES. Given that (1) it's not clear to me that it is wise to use a relatively new algorithm, and (2) weak keys are rare enough that it's not clear it's worth it to worry about such cases anyway. (It turns out that with DES in particular, worrying about weak keys is not particularly useful, since an attacker wouldn't be able to tell if a weak key was used. All a weak key means for DES is that there is some other DES key which which if used to encrypt the ciphertext, will yield the plaintext. Even assuming the attacker knew that a weak DES key were used, I can't see how the attacker would be able to exploit this fact, especially in the context of IKE phase 1.) - Ted From owner-ipsec Fri Apr 17 10:19:48 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA21973 for ipsec-outgoing; Fri, 17 Apr 1998 10:18:33 -0400 (EDT) Message-Id: <199804171432.PAA06631@gate.ticl.co.uk> X-Sender: peter@gate (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 17 Apr 1998 15:32:50 +0100 To: Steve Bellovin From: Peter Curran Subject: Re: Hop Limit in Inner Header (IPv6) Cc: "Theodore Y. Ts'o" , Karen Heron , ipsec@tis.com In-Reply-To: <199804170127.VAA09270@postal.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk It sounds as if there is a danger of creating an illogicality here. When IPv6 automatic tunnels are used to connect two IPv6/IPv4 nodes (across an IPv4 network of any size) then the inner packet hop-limit is not decremented because both hosts are on the same logical link connecting them. As the packet is not *forwarded* into the tunnel, then the hop-limit remains unchanged. By the same logic, why should the hop-limit be decremented when the packet is being sent across an IPSEC tunnel that exists between the same two nodes? IMHO, this shouuld not happen because it is not logical. If the packet originated on a 3rd node, was passed to the 1st and then sent down a tunnel to the 2nd then I agree the hop-limit should be deceremented - the packet is forwarded from one link to another. The proposed mechanism will break NDP. Another question that should be considered relates to the scope of the IPv6 addresses. Is it illogical for an IPSEC tunnel to exist between two nodes, if the end-points of the tunnel are recognised by link local addresses and yet not on the same physical link? What if they are not on the same site? In the former case, link local addresses could be assigned to the tunnel ends - the two devices will be on the same logical link. Peter TICL At 21:27 16/04/98 -0400, Steve Bellovin wrote: > From: Karen Heron > Date: Wed, 15 Apr 1998 07:49:03 -0400 > > In draft-ietf-ipsec-arch-sec-04, 5.1.2.2 IPv6 -- Header Constructio > n > for Tunnel Mode, the inner header Hop Limit is decremented. This > will cause problems for securing IPv6 NDP traffic. The hop limit i > s > set to 255 in NDP packets and checked in the receiving node to make > sure it came from the same link. If this NDP exchange is secured > using tunnel mode and the hop limit is decremented before the packe > t > is encapsulated, the receiving node will reject the NDP packet and > neighbor discovery will fail, even if the two nodes are on the same > link. Should the Hop Limit not be decremented for locally generate > d > traffic? If not, I don't see how NDP traffic can be secured using > tunnel mode - maybe I've missed something in the drafts that said > this. If this question has already been answered, I'd appreciate a > pointer to the discussion (I didn't see it in the archives). > > Karen, > I would think that if a packet originates at host A, and the > packet then gets encapsulated by security gateway G and sent down the > IPSEC tunnel to host B, that host A and host B are not on the same > network. > > In fact, even if the packet is originated and encapsulated at > host A, and sent over a IPSEC tunnel, which might send the packet > halfway across the world, when it is decapsulated at host B, the hop > count should be decremented, since it is extremely unlikely that they > are really "neighbors". > > I'm not completely familiar with what exactly NDP is trying to > do, but if you're using tunnel mode, you can't distinguish between > whether your communications partner is on the same ethernet, or on the > wrong side of MAE-EAST (you can tell that by the number of packets tha > t > get dropped, though :-). If this is what NDP is trying to do, then > fundamentally you shouldn't be using tunnel mode. Whether you always > decrement the hop count, as the spec currently states, or never > decrement the hop count, you still don't know whether someone is next > door or on the other side of the planet. > >My own view is that a tunnel is a virtual wire between two nodes. NDP >should work across that tunnel only to the extent that the packet >originated on one endpoint and terminated on the other. ("Neighbor" is >a topological construct here, and ignores phyiscal reality.) > From owner-ipsec Mon Apr 20 07:27:07 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA14121 for ipsec-outgoing; Mon, 20 Apr 1998 07:16:07 -0400 (EDT) X-Organization: University of Dayton, School of Engineering, Dayton OH Message-Id: <199804172144.RAA24325@ensun101.UD.Engr> Subject: CFP: Arch. Prot. & QoS for Future Internet To: ipsec@ans.net Date: Fri, 17 Apr 1998 17:44:09 -0400 (EDT) Reply-To: atiq@engr.udayton.edu (Mohammed Atiquzzaman) From: atiq@engr.udayton.edu (Mohammed Atiquzzaman) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk CALL FOR PAPERS European Transactions on Telecommunications (ETT) Special Issue on ARCHITECTURES, PROTOCOLS AND QUALITY OF SERVICE FOR THE INTERNET OF THE FUTURE Guest Editors: Matteo D'Ambrosio and Mohammed Atiquzzaman Recent advances in switching and transmission technologies allow the implementation of very high speed networks that are changing the face of the Internet. In the next Telecommunication Age it will be possible to support new multimedia applications in a global environment and design new services on flexible platforms without upgrading the physical infrastrucure. In order to reach these goals many researchers are working on defining the new Network Architecture, which will be capable of offering transport and computation services to communication applications with stringent Quality of Service (QoS) requirements. New protocols and node implementations have to be envisioned with this objective in mind. The ETT Journal announces a forthcoming issue on "Architectures, Protocols and Quality of Service For The Internet Of The Future", that will be focused on (but not limited to) the following topics: - New node architectures for Switching and Routing at Gigabit Speeds - Multi-Protocol Label Switching (MPLS): design principles, network architecture and performance - Internetworking with ATM and High Speed Networks to offer QoS guarantees - Multimedia Services running on Heterogeneous Networks - Network and Transport Protocols in the Integrated Services Internet - QoS provision, multicast support and policy capabilities in Routing and Signalling Protocols - Differentiated Services Architectures - Open Control Architectures and Active Networks Prospective authors should email their manuscripts (PostScript format) or send five (5) hard copies to one of the Guest Editors listed below. The following deadlines will apply: - Submission of manuscripts June 30, 1998 - Notification of acceptance November 15, 1998 - Submission of final manuscript December 15, 1998 - Publication Date March-April, 1999 Guest Editors Matteo D'Ambrosio Mohammed Atiquzzaman Networking Department Department of Electrical & CSELT Computer Engineering v. Reiss Romoli 274 University of Dayton 10148 Torino Dayton, Ohio 45469-0226 Italy USA phone: +39 11 2285006 phone: +1 937 229-3183 fax: +39 11 2285069 fax: +1 937 229-4529 e-mail: matteo.dambrosio@cselt.it e-mail: atiq@engr.udayton.edu More information about the special issue can be obtained from http://www.engr.udayton.edu/faculty/matiquzz/ett-cfp.html Note: If a paper is not accepted for the special issue, it will be considered for publication in one of the regular issues of ETT. From owner-ipsec Mon Apr 20 15:00:23 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA17416 for ipsec-outgoing; Mon, 20 Apr 1998 14:57:43 -0400 (EDT) Message-ID: <3D33CF40366DD111AC4100A0C96B22AC015D534B@FMSMSX34> From: "Patel, Baiju V" To: "'Theodore Y. Ts'o'" , "Patel, Baiju V" Cc: "'iesg@ietf.org'" , "'ipsec@tis.com'" , "Patel, Baiju V" Subject: RE: Last Call for IPSEC Date: Mon, 20 Apr 1998 11:46:20 -0700 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 Ted, I disagree with your response to my mail messages. See my comments preceded with >>>. Specifically, are you ready to say to the working group that AH has no significant advantage over ESP and yet, we must include it in the standards as a MUST implement transform. Baiju -----Original Message----- From: Theodore Y. Ts'o [mailto:tytso@MIT.EDU] Sent: Thursday, April 16, 1998 8:29 PM To: Patel, Baiju V Cc: 'iesg@ietf.org'; 'ipsec@tis.com'; Patel, Baiju V Subject: Re: Last Call for IPSEC From: "Patel, Baiju V" Date: Thu, 9 Apr 1998 14:28:21 -0700 1. Destination address: The destination address is part of SA. Therefore, it is not possible for the recipient of the packet to correctly identify SA used to protect the packet, and thus, ESP integrity check will fail. 2. Source address: As defined in the IPSEC Arch document, SA database includes this information, and therefore, when compared with expected source address for the SA, any change in the source address will be detected (thus, integrity violation will be detected). The destination and source addresses in the SA may be a wildcard, or a range of addresses, not just a single address. Hence, changes to source and destination addresses may not be detected unless you are using something like AH to integrity protect these header values. >>> I don't get it. The wild cards are used with tunnel >>> mode for addresses where a secure network gateway >>> represents many addresses behind it. In that >>> case, those addresses are part of the inside >>> IP header of the tunnel mode packet. And, in tunnel >>> mode, the inside header is protected anyway. >>> Therefore, I strongly believe that my argument holds. 7. If protocol field is changed, SA lookup will result in the SA that was used to protect the packet. So, integrity will not be verified. The protocol field is not used to lookup the SA. The SPI is used to do that. a. Internet security options: (these are obsolete but still in use, as specified in AH document). IPSEC is designed to meets security needs at IP layer, so, what is the additional security value of using these options? Moreover, if these options are compromised, and that can result in weaker security, are they really providing security? (also note they are obsolete). In conclusion, While using IPSEC, if we still need these options, and they need to be protected, IPSEC is not meeting security requirements. I do believe that IPSEC does meet the security requirements and therefore, there is no additional value in protecting these options. (note that in tunnel mode they will be protected anyway). There are other security services which are orthagnonal to those which are provided by IPSEC. For example, IPSEC does not provide classification labeling. Whether or not such options are useful in general is another debate, although historically there have been a number of communities which have found such services useful. Your claim that IPSEC obsoletes all other IP Security options does not seem to make a prima facie case. >>> Again, I don't get it. When you negotiate keys using IKE >>> you can use a classification label (situation). From then >>> onwards, SA represents classification labels. >>> My argument is not that IPSEC solves all your security >>> problems, but it is that let us not claim that we need >>> IPSEC to secure other security solutions. Which is the argument >>> presented to me about security options in IP packet. Unless technical flaws are identified with above analysis, it is my recommendation that we do not standardize two security protocols at the same time and burden the community with this legacy. We drop AH from IPSEC for IP v4 and possibly from IP v6. At least a number of your arguments have very obvious flaws. >>> I disagree. Can you say that above are strong reasons to >>> mandate implementation of an entire transform. In any case, this is an item which the working group has now revisited *three* times, most recently at the last IETF meeting in Los Angelos, where Jeff Schiller took a straw poll and found a clear consensus of the working group to not change the status of AH at this date. One would think that we have dealt with this issue enough at this point. It is hard, nay impossible, to make progress when we have to revisit an issue over and over again. At some point we have to say "enough" and move on. >>> As a working group chair, are you ready to say that AH has to >>> significant advantage over ESP and yet, you recommend that >>> we standardize it. If I read between the lines of the paragraph >>> above, that is how I would read it. - Ted From owner-ipsec Mon Apr 20 15:58:52 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA17795 for ipsec-outgoing; Mon, 20 Apr 1998 15:57:47 -0400 (EDT) Date: Mon, 20 Apr 1998 13:11:53 -0700 From: mark@mentat.com (Marc Hasson) Message-Id: <199804202011.NAA23820@orna.mentat.com> To: tytso@MIT.EDU, ipsec@tis.com Subject: IPSEC Last Call: SA definition Cc: iesg@ietf.org X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks (in particular Theodore), I'm a little bit behind on the flood of E-mail and may have missed any true "last call" deadline but I'm concerned about a couple of notes that flew by in the last 2 weeks. I want to make sure we didn't change the definition of an SA, at least as far as how a receiver is supposed to be looking things up and conceptually managing its database of SA info. In the current arch-sec-04 we have the following from section 4.1: A security association is uniquely identified by a triple consisting of a Security Parameter Index (SPI), an IP Destination Address, and a security protocol (AH or ESP) identifier. In principle, the Destination Address may be a unicast address, an IP broadcast address, or a multicast group address. However, IPsec SA management mechanisms currently are defined only for unicast SAs. Hence, in the discussions that follow, SAs will be described in the context of point-to-point communication, even though the concept is applicable in the point-to-multipoint case as well. In both the esp-v2-04 and auth-header-05 documents we have text that mirrors each other (this one in ESP): 3.4.2 Security Association Lookup Upon receipt of a (reassembled) packet containing an ESP Header, the receiver determines the appropriate (unidirectional) SA, based on the destination IP address, security protocol (ESP), and the SPI. (This process is described in more detail in the Security Architecture document.) The above supports the arch-sec-04 definition of a unique triple but doesn't force it to be an explicit triple, it says "based on". In recent E-mails to the IPSEC list we have: on 4/7/98 in the "Re: why single value destipaddress in SA selector" thread from Karen Seo (sent soon after, but probably without seeing, a message from Michael Richardson on the same date had given what *I* thought was the correct response on how multiple flows get mapped to a single tunnel SA, without changing the definition of an SA): Padma, >>According to the Ipsec Architecture RFC, Destination address part of >>selectors can have single, range, wildcard in SPD but SA can have only >>single IP address. Why is it so? Why can't we have range or wildcard >>in SA dest ip address part of selectors as in SPD. You're right. We will change the 2nd entry in the table on page 21 from: Field Traffic Value SAD Entry SPD Entry -------- ------------- ---------------- -------------------- src addr single IP addr single,range,wild single,range,wildcard --> dst addr single IP addr single IP addr single,range,wildcard to: Field Traffic Value SAD Entry SPD Entry -------- ------------- ---------------- -------------------- src addr single IP addr single,range,wild single,range,wildcard --> dst addr single IP addr single,range,wild single,range,wildcard By the way, Karen's note goes on in well-done detail (sorry, Michael, she went much further than you) to explain the proper use of the destination address depending upon Transport vs. Tunnel mode as well as the proper mapping of policy to a Security Association in the original E-mail's tunnel example. I was left with the impression that the "triple lookup", just as in a hash lookup, would satisfy the requirements she described for the "index" usage of "dst addr". At least for the initial "lets get some info on what this inbound IPSEC packet is about" lookup and "lets get some info on selectors specific to this SA for this inbound packet". However, the above table change seems to lead to the note below, perhaps because the table doesn't/can't specify the destination clearly as being used for index/lookup vs. selector usage and whether by the sender or a receiver: on 4/16/98 from Theodore Y. Ts'o responding to Baiju: 1. Destination address: The destination address is part of SA. Therefore, it is not possible for the recipient of the packet to correctly identify SA used to protect the packet, and thus, ESP integrity check will fail. 2. Source address: As defined in the IPSEC Arch document, SA database includes this information, and therefore, when compared with expected source address for the SA, any change in the source address will be detected (thus, integrity violation will be detected). The destination and source addresses in the SA may be a wildcard, or a range of addresses, not just a single address. Hence, changes to source and destination addresses may not be detected unless you are using something like AH to integrity protect these header values. 7. If protocol field is changed, SA lookup will result in the SA that was used to protect the packet. So, integrity will not be verified. The protocol field is not used to lookup the SA. The SPI is used to do that. My belief is that Karen's full note from 4/7/98 is correct and that Theodore's note is not completely correct on the above 2 comments, without more qualifications. But either way we're left with an apparent need for more clarification in the architecture document. I wouldn't think it worthwhile to hold up "last call" for that clarification as long as someone (Theodore?) clarifies this apparent discrepancy on the mailing list. An SPI-only lookup with a wildcarded or ranged SA destination address as "index" on receiving an IPSEC packet would have some ramifacations that I'd rather we didn't introduce at this time on working implementations. I thought they'd be more appropriate for IPsecond or the NAT presentation Bellovin made at the last IETF's NAT meeting for our consideration. Thank-you. -- Marc -- From owner-ipsec Tue Apr 21 07:34:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA23317 for ipsec-outgoing; Tue, 21 Apr 1998 07:26:50 -0400 (EDT) Date: Tue, 21 Apr 98 07:36:45 EDT From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9804211136.AA09244@dolphin.ncsc.mil> To: ipsec@tis.com Subject: ISAKMP - Remaining Issues Sender: owner-ipsec@ex.tis.com Precedence: bulk All, In an attempt to finalize any remaining issues with ISAKMP, I think there are two outstanding issues. They are: > 1. ISAKMP Message Header Length field and data do not match > > (Matt Thomas - 29 Sep 97 e-mail) > What if the ISAKMP Message Header Length field indicates a > different length than the actual data? Length > Data = no > action?, but Data > Length = Data Ignored or Message Trashed? I know there was a flurry of e-mail surrounding this issue, but I don't think there was any consensus about how things should be worded in the I-D. Anybody want to give a *definitive* answer? 2. From Michael Richardson's e-mail and Roy Pereira's presentation at the L.A. IETF IPSEC meeting. > 11. Some vendors did not like ISAKMP packet to be padded to a multiple of 4 > bytes. > Q: Does the spec allow this? > A: There was some argument about whether this is REQUIRED. > {ed: It would seem to fall into the "be conservative in what > you generate and liberal in what you accept" } Currently, section 3 of ISAKMP-09 says "Additionally, all ISAKMP messages MUST be aligned at 4-octet boundaries." There has been some debate about this in the past. How do the ISAKMP implementers want this specified in the I-D so we can have interoperability? Thanks, Doug From owner-ipsec Tue Apr 21 11:33:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA25122 for ipsec-outgoing; Tue, 21 Apr 1998 11:30:53 -0400 (EDT) Date: Tue, 21 Apr 1998 11:44:16 -0400 Message-Id: <9804211544.AA22717@kona.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ipsec@tis.com Subject: Re: Weak keys References: <199804162232.PAA06688@gallium.network-alchemy.com> <199804171407.KAA14605@dcl.MIT.EDU> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Theodore" == Theodore Y Ts'o writes: Theodore> Date: Thu, 16 Apr 1998 15:32:21 -0700 From: "Derrell Theodore> D. Piper" >> It also doesn't sound like it will interoperate if new weak keys >> are discovered and one side is updated to recognize those weak >> keys (since the two sides will extract different substrings from >> the keying material). After all, the listing of weak keys is >> subject to growth as more is learned about the systems in >> question. Derrell> The side that's been updated could just initiate a new Derrell> rekey, assuming that the other side wouldn't be smart Derrell> enough to do so. Theodore> This works. I would also point out that an algorithm like Theodore> DES has received enough attention from the cryptographic Theodore> comminity that it is unlikely that new weak keys will be Theodore> found. There may be new attacks which might make us decide Theodore> not to use the algorithm at all, but weak keys tend to be Theodore> relatively early in the life cycle --- ideally before the Theodore> algorithm is published, if there has been sufficient Theodore> prepublication review. Theodore> If we're using relatively new ciphers that aren't proven, Theodore> then that's much more of an issue. Currently in IKE there Theodore> is no mention of needing to do anything with weak keys for Theodore> anything other than DES. Given that (1) it's not clear to Theodore> me that it is wise to use a relatively new algorithm, and Theodore> (2) weak keys are rare enough that it's not clear it's Theodore> worth it to worry about such cases anyway. True, but there are cases where I wouldn't use the qualifier "aren't proven". For example, the 3DES document specifically mentions checking for its weak keys (those where k1==k2 or k2==k3). Also, in the case of DES I might want to disallow the "potentially weak" keys Scheier lists, not just the weak and semi-weak keys. Then there are IDEA and Blowfish, both of which are known to have weak keys -- yet these are mature enough that they are used. I observe that in the case of IDEA, the earlier description of which keys are weak has been superseded. Theodore> (It turns out that with DES in particular, worrying about Theodore> weak keys is not particularly useful, since an attacker Theodore> wouldn't be able to tell if a weak key was used. All a Theodore> weak key means for DES is that there is some other DES key Theodore> which which if used to encrypt the ciphertext, will yield Theodore> the plaintext. Even assuming the attacker knew that a weak Theodore> DES key were used, I can't see how the attacker would be Theodore> able to exploit this fact, especially in the context of IKE Theodore> phase 1.) Well, there certainly is some argument that any kind of weak key checking is not all that useful since the probabilities are so low. The counterargument is that it's easy, so why not do it? And of course there's a specific requirement to do it for the listed set of DES weak keys in IKE phase 1. So what I get from all this is: 1. Handle the specified list of DES keys (and no others) in phase 1 as stated, i.e., skip bits. 2. Handle all other weak keys in all other cases by rekeying. paul From owner-ipsec Tue Apr 21 13:55:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA26537 for ipsec-outgoing; Tue, 21 Apr 1998 13:53:57 -0400 (EDT) Message-Id: <3.0.5.32.19980421135506.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: Tue, 21 Apr 1998 13:55:06 -0400 To: Paul Koning , ipsec@tis.com From: Robert Moskowitz Subject: Re: Weak keys In-Reply-To: <9804211544.AA22717@kona.xedia.com> References: <199804162232.PAA06688@gallium.network-alchemy.com> <199804171407.KAA14605@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 11:44 AM 4/21/98 -0400, Paul Koning wrote: > >So what I get from all this is: >1. Handle the specified list of DES keys (and no others) in phase 1 as >stated, i.e., skip bits. >2. Handle all other weak keys in all other cases by rekeying. There was an interesting comment about weak keys some time ago. Either from Sommerville or McDonald to something like: Weak keys are so rare that the code for them might never be exercised in testing and might be flawed. ERGO a developer might choose a strategy that keeps the weak key code as simple as possible. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Tue Apr 21 13:55:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA26536 for ipsec-outgoing; Tue, 21 Apr 1998 13:53:56 -0400 (EDT) Message-Id: <3.0.5.32.19980421135920.00a0b7f0@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, 21 Apr 1998 13:59:20 -0400 To: Peter Curran , Steve Bellovin From: Robert Moskowitz Subject: Re: Hop Limit in Inner Header (IPv6) Cc: "Theodore Y. Ts'o" , Karen Heron , ipsec@tis.com In-Reply-To: <199804171432.PAA06631@gate.ticl.co.uk> References: <199804170127.VAA09270@postal.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 03:32 PM 4/17/98 +0100, Peter Curran wrote: I am not familiar with NPD, but from RFC 2003 we have: When encapsulating a datagram, the TTL in the inner IP header is decremented by one if the tunneling is being done as part of forwarding the datagram; otherwise, the inner header TTL is not changed during encapsulation. If the resulting TTL in the inner IP header is 0, the datagram is discarded and an ICMP Time Exceeded message SHOULD be returned to the sender. An encapsulator MUST NOT encapsulate a datagram with TTL = 0. The TTL in the inner IP header is not changed when decapsulating. If, after decapsulation, the inner datagram has TTL = 0, the decapsulator MUST discard the datagram. If, after decapsulation, the decapsulator forwards the datagram to one of its network interfaces, it will decrement the TTL as a result of doing normal IP forwarding. See also Section 4.4. This is a little different from IPsec-arch-04: 2. The TTL in the inner header is decremented by the encapsulator prior to forwarding and by the decapsulator if it forwards the packet. (The checksum changes when the TTL changes.) but none the less, both decrement. I might point out that tunneling in ipsec-arch's parentage is the 2003 work, if not 2003 itself. It is interesting to note that 2003 does not decrement on decapsulating, though. >It sounds as if there is a danger of creating an illogicality here. > >When IPv6 automatic tunnels are used to connect two IPv6/IPv4 nodes (across >an IPv4 network of any size) then the inner packet hop-limit is not >decremented because both hosts are on the same logical link connecting >them. As the packet is not *forwarded* into the tunnel, then the hop-limit >remains unchanged. > >By the same logic, why should the hop-limit be decremented when the packet >is being sent across an IPSEC tunnel that exists between the same two nodes? > >IMHO, this shouuld not happen because it is not logical. If the packet >originated on a 3rd node, was passed to the 1st and then sent down a tunnel >to the 2nd then I agree the hop-limit should be deceremented - the packet >is forwarded from one link to another. > >The proposed mechanism will break NDP. > >Another question that should be considered relates to the scope of the IPv6 >addresses. Is it illogical for an IPSEC tunnel to exist between two nodes, >if the end-points of the tunnel are recognised by link local addresses and >yet not on the same physical link? What if they are not on the same site? > >In the former case, link local addresses could be assigned to the tunnel >ends - the two devices will be on the same logical link. > >Peter >TICL > > >At 21:27 16/04/98 -0400, Steve Bellovin wrote: >> From: Karen Heron >> Date: Wed, 15 Apr 1998 07:49:03 -0400 >> >> In draft-ietf-ipsec-arch-sec-04, 5.1.2.2 IPv6 -- Header Constructio >> n >> for Tunnel Mode, the inner header Hop Limit is decremented. This >> will cause problems for securing IPv6 NDP traffic. The hop limit i >> s >> set to 255 in NDP packets and checked in the receiving node to make >> sure it came from the same link. If this NDP exchange is secured >> using tunnel mode and the hop limit is decremented before the packe >> t >> is encapsulated, the receiving node will reject the NDP packet and >> neighbor discovery will fail, even if the two nodes are on the same >> link. Should the Hop Limit not be decremented for locally generate >> d >> traffic? If not, I don't see how NDP traffic can be secured using >> tunnel mode - maybe I've missed something in the drafts that said >> this. If this question has already been answered, I'd appreciate a >> pointer to the discussion (I didn't see it in the archives). >> >> Karen, >> I would think that if a packet originates at host A, and the >> packet then gets encapsulated by security gateway G and sent down the >> IPSEC tunnel to host B, that host A and host B are not on the same >> network. >> >> In fact, even if the packet is originated and encapsulated at >> host A, and sent over a IPSEC tunnel, which might send the packet >> halfway across the world, when it is decapsulated at host B, the hop >> count should be decremented, since it is extremely unlikely that they >> are really "neighbors". >> >> I'm not completely familiar with what exactly NDP is trying to >> do, but if you're using tunnel mode, you can't distinguish between >> whether your communications partner is on the same ethernet, or on the >> wrong side of MAE-EAST (you can tell that by the number of packets tha >> t >> get dropped, though :-). If this is what NDP is trying to do, then >> fundamentally you shouldn't be using tunnel mode. Whether you always >> decrement the hop count, as the spec currently states, or never >> decrement the hop count, you still don't know whether someone is next >> door or on the other side of the planet. >> >>My own view is that a tunnel is a virtual wire between two nodes. NDP >>should work across that tunnel only to the extent that the packet >>originated on one endpoint and terminated on the other. ("Neighbor" is >>a topological construct here, and ignores phyiscal reality.) >> > > Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Tue Apr 21 14:15:32 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA26758 for ipsec-outgoing; Tue, 21 Apr 1998 14:14:54 -0400 (EDT) From: Dan McDonald Message-Id: <199804211827.LAA29769@kebe.eng.sun.com> Subject: Re: Weak keys To: rgm-sec@htt-consult.com (Robert Moskowitz) Date: Tue, 21 Apr 1998 11:27:23 -0700 (PDT) Cc: pkoning@xedia.com, ipsec@tis.com In-Reply-To: <3.0.5.32.19980421135506.009c0100@homebase.htt-consult.com> from "Robert Moskowitz" at Apr 21, 98 01:55:06 pm 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 > >So what I get from all this is: > >1. Handle the specified list of DES keys (and no others) in phase 1 as > >stated, i.e., skip bits. > >2. Handle all other weak keys in all other cases by rekeying. > > There was an interesting comment about weak keys some time ago. Either > from Sommerville or McDonald to something like: > > Weak keys are so rare that the code for them might never be exercised in > testing and might be flawed. I didn't say it, but that makes a LOT of sense. > ERGO a developer might choose a strategy that keeps the weak key code as > simple as possible. My code rejects weak keys at the time you attempt to add them to the kernel's SADB. Any program that handles the adding of keys needs to check for errors anyway, so weak keys become just one more error case. Dan From owner-ipsec Tue Apr 21 14:39:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA26940 for ipsec-outgoing; Tue, 21 Apr 1998 14:38:57 -0400 (EDT) Message-Id: <3.0.5.32.19980421144301.00a5b450@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, 21 Apr 1998 14:43:01 -0400 To: ipsec@tis.com, Michael Richardson From: Robert Moskowitz Subject: Re: Hop Limit in Inner Header (IPv6) In-Reply-To: <199804211849.OAA10300@lox.sandelman.ottawa.on.ca> References: <3.0.5.32.19980421135920.00a0b7f0@homebase.htt-consult.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 02:49 PM 4/21/98 -0400, Michael Richardson wrote: >2003> decapsulator MUST discard the datagram. If, after decapsulation, the >2003> decapsulator forwards the datagram to one of its network interfaces, > >Bob> ipsec-arch's parentage is the 2003 work, if not 2003 itself. It is >Bob> interesting to note that 2003 does not decrement on decapsulating, though. > > If you regard a tunnel as a replacement for a physical wire, then >the wording in 2003 is far more correct. You decrement upon forwarding. >So, I'm not sure why you write the above parts. My message was incomplete. Why the difference? Is one more right than the other? Or is the need different in MobileIP than in IPsec tunnels? > Rational for decrementing was discussed awhile ago on this list. > See: > http://www.sandelman.ottawa.on.ca/ipsec/1997/07/msg00016.html > > and followup messages. > Thanks for the reference. I knew that this was discussed before. What hasn't been... Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Tue Apr 21 14:39:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA26939 for ipsec-outgoing; Tue, 21 Apr 1998 14:38:57 -0400 (EDT) Message-Id: <3.0.5.32.19980421144111.00a58100@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, 21 Apr 1998 14:41:11 -0400 To: ipsec@tis.com From: Michael Richardson (by way of Robert Moskowitz ) Subject: Re: Hop Limit in Inner Header (IPv6) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Mike asked me to forward this note to the list. 2003> decapsulator MUST discard the datagram. If, after decapsulation, the 2003> decapsulator forwards the datagram to one of its network interfaces, Bob> ipsec-arch's parentage is the 2003 work, if not 2003 itself. It is Bob> interesting to note that 2003 does not decrement on decapsulating, though. If you regard a tunnel as a replacement for a physical wire, then the wording in 2003 is far more correct. You decrement upon forwarding. So, I'm not sure why you write the above parts. I think the NDP is a silly thing for the reasons that have already been pointed out: you can't tell how your neighbours anyway, because you don't know how far the tunnels go. Maybe some NDP person can explain to us why they want to know these things, remembering that tunnels are supposed to be rare in IPv6, since everyone has AH at the least. Rational for decrementing was discussed awhile ago on this list. See: http://www.sandelman.ottawa.on.ca/ipsec/1997/07/msg00016.html and followup messages. From owner-ipsec Tue Apr 21 14:58:42 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA27050 for ipsec-outgoing; Tue, 21 Apr 1998 14:56:55 -0400 (EDT) Message-Id: <199804211910.MAA09191@gallium.network-alchemy.com> To: wdm@epoch.ncsc.mil (W. Douglas Maughan) cc: ipsec@tis.com Subject: Re: ISAKMP - Remaining Issues In-reply-to: Your message of "Tue, 21 Apr 1998 07:36:45 EDT." <9804211136.AA09244@dolphin.ncsc.mil> Date: Tue, 21 Apr 1998 12:10:31 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk RE: mismatch header/payload lengths If the message header lengths and the payload lengths are inconsistent then the message MUST be rejected. Padding issues (whatever they are) MUST be addressed in the ISAKMP, IKE, and DOI drafts so there should not be any open interpretation for things like Length > Data. That's a broken implementation. RE: padding I'm slightly confused by the question of padding on payloads. There has not been a padding requirement since Munich. Observation 1: Encypted ISAKMP exchanges will be padded to a cipher block boundary, per the IKE draft. This leaves the entire ISAKMP message padded to something like a quadword alignment, in the normal case. Observation 2: As for the individual payloads, my belief is that this isn't a particularly aligned protocol. Most of the payloads are intrinsically byte-oriented after the initial header. As you know, earlier versions of the ISAKMP drafts had stated that each payload should begin on a longword-aligned boundary. This was changed around Munich based on feedback from a number of folks to simply align the entire message, which really only aligns the unprotected exchanges. I don't feel that there's a significant processing win to aligning the individual payloads, but I don't object to that either. However, we have changed the draft already once to remove the payload alignment requirement. So, I'd prefer to keep the draft as currently written. Derrell From owner-ipsec Tue Apr 21 14:59:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA27072 for ipsec-outgoing; Tue, 21 Apr 1998 14:58:56 -0400 (EDT) To: Karen Seo Cc: skent@bbn.com, clynn@bbn.com, tytso@MIT.EDU, ipsec@tis.com, iesg@ietf.org Subject: Re: IPsec re-defining IP-in-IP References: <199804210320.XAA10547@volitans.MorningStar.Com> From: Ben Rogers Date: 21 Apr 1998 15:12:08 -0400 In-Reply-To: Karen Seo's message of Mon, 20 Apr 98 23:19:34 EDT Message-ID: Lines: 32 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-ipsec@ex.tis.com Precedence: bulk [CC'ed back out to both ipsec and iesg] Karen Seo writes: > In writing the architecture section 5.1.2 "Header Construction > for Tunnel Mode", we tried to conform to RFC 2003. I thought > we'd only added clarifications, e.g., the footnote about src and > dest addresses or the table entry saying the protocol in the > outer header could be AH, ESP, or a routing header (not just 4 > as stated in RFC 2003). Could you tell us what you are > concerned about that we've "redefin"ed? I'm not concerned that you have defined anything differently than in RFC 2003. My concern is that we are redefining (duplicating the definition of) the protocol. If the protocol is defined in two locations, anyone wishing to update RFC 2003 would also have to update the IPsec architecture draft. Twice as much opportunity for problems to arise -- AND the added confusion of (possible) differences between the IPsec Protocol 4 encapsulation and the Internet Standard IP-in-IP Protocol 4 encapsulation. I feel that Protocol 4 (IP-in-IP) encapsulation ought to be defined in only one place. If we (the IPsec community) want to use it, we should reference the standard document. If we need something different, then we should choose a different protocol number to describe it. If we merely need clarifications to RFC 2003, then they should be made in a successor to RFC 2003, and not in a completely unrelated (for non-IPsec folks) document. ben From owner-ipsec Tue Apr 21 15:07:16 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA27153 for ipsec-outgoing; Tue, 21 Apr 1998 15:06:59 -0400 (EDT) Message-Id: X-Sender: peter@gate (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 21 Apr 1998 20:20:55 +0100 To: Robert Moskowitz From: Peter Curran Subject: Re: Hop Limit in Inner Header (IPv6) Cc: Steve Bellovin , "Theodore Y. Ts'o" , Karen Heron , ipsec@tis.com, ipng@sunroof.Eng.Sun.COM In-Reply-To: <3.0.5.32.19980421135920.00a0b7f0@homebase.htt-consult.com> References: <199804171432.PAA06631@gate.ticl.co.uk> <199804170127.VAA09270@postal.research.att.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-==--==-=-===----=-=---=-=--==--=---====-=--==="; protocol="application/pgp-signature"; micalg=pgp-sha1 Sender: owner-ipsec@ex.tis.com Precedence: bulk --=-==--==-=-===----=-=---=-=--==--=---====-=--=== Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" (Sorry about retaining all the preceding in this reply, but I have copied this to the IPNG list in case the wider WG wants to make some further comments) The operation of tunneling as described in RFC2003 is in line with that used by IPv6. I have now had chance to read the stuff through again more carefully and think that the problem is one of interpretation. The ipsec-arch-sec document should make it clear that if the inner packet originates on the node that is responsible for encapsulation, then the TTL (or Hop Limit in the IPv6 case) should not be decremented as no forwarding is taking place. If the inner packet originates on a different node, then the TTL (HL) of the inner packet should be decremented prior to forwarding into the tunnel. Likewise, if the decapsulating node is not the final destination of the inner packet, then its TTL(HL) should be decremented when it is forwarded on from the decapsulating node towards its destination. (Incidentally, there is a typo. The IPv6 equivalent of the TTL field is called Hop Limit, not Hop Count) The issue raised by Karen Heron is that if this interpretation is not correct, then the NDP protocol will break. A 'built-in' security feature of the protocol design is that all NDP messages can only be received from the link to which you are fastened (physically or logically). By setting the HL to 255, an attempt to spoof an NDP message by forwarding it onto the link can be detected. *IF* IPSEC, using tunnel mode ESP, is to be used for NDP then it is essential that this behaviour is maintained. Of course, there may not be a need to use IPSEC in this mode for this purpose. Peter TICL At 13:59 21/04/98 -0400, Robert Moskowitz wrote: >At 03:32 PM 4/17/98 +0100, Peter Curran wrote: > >I am not familiar with NPD, but from RFC 2003 we have: > > When encapsulating a datagram, the TTL in the inner IP header is > decremented by one if the tunneling is being done as part of > forwarding the datagram; otherwise, the inner header TTL is not > changed during encapsulation. If the resulting TTL in the inner IP > header is 0, the datagram is discarded and an ICMP Time Exceeded > message SHOULD be returned to the sender. An encapsulator MUST NOT > encapsulate a datagram with TTL = 0. > > The TTL in the inner IP header is not changed when decapsulating. > If, after decapsulation, the inner datagram has TTL = 0, the > decapsulator MUST discard the datagram. If, after decapsulation, the > decapsulator forwards the datagram to one of its network interfaces, > it will decrement the TTL as a result of doing normal IP forwarding. > See also Section 4.4. > >This is a little different from IPsec-arch-04: > > 2. The TTL in the inner header is decremented by the > encapsulator prior to forwarding and by the decapsulator if > it forwards the packet. (The checksum changes when the TTL > changes.) > >but none the less, both decrement. I might point out that tunneling in >ipsec-arch's parentage is the 2003 work, if not 2003 itself. It is >interesting to note that 2003 does not decrement on decapsulating, though. > > >>It sounds as if there is a danger of creating an illogicality here. >> >>When IPv6 automatic tunnels are used to connect two IPv6/IPv4 nodes (across >>an IPv4 network of any size) then the inner packet hop-limit is not >>decremented because both hosts are on the same logical link connecting >>them. As the packet is not *forwarded* into the tunnel, then the hop-limit >>remains unchanged. >> >>By the same logic, why should the hop-limit be decremented when the packet >>is being sent across an IPSEC tunnel that exists between the same two nodes? >> >>IMHO, this shouuld not happen because it is not logical. If the packet >>originated on a 3rd node, was passed to the 1st and then sent down a tunnel >>to the 2nd then I agree the hop-limit should be deceremented - the packet >>is forwarded from one link to another. >> >>The proposed mechanism will break NDP. >> >>Another question that should be considered relates to the scope of the IPv6 >>addresses. Is it illogical for an IPSEC tunnel to exist between two nodes, >>if the end-points of the tunnel are recognised by link local addresses and >>yet not on the same physical link? What if they are not on the same site? >> >>In the former case, link local addresses could be assigned to the tunnel >>ends - the two devices will be on the same logical link. >> >>Peter >>TICL >> >> >>At 21:27 16/04/98 -0400, Steve Bellovin wrote: >>> From: Karen Heron >>> Date: Wed, 15 Apr 1998 07:49:03 -0400 >>> >>> In draft-ietf-ipsec-arch-sec-04, 5.1.2.2 IPv6 -- Header Constructio >>> n >>> for Tunnel Mode, the inner header Hop Limit is decremented. This >>> will cause problems for securing IPv6 NDP traffic. The hop limit i >>> s >>> set to 255 in NDP packets and checked in the receiving node to make >>> sure it came from the same link. If this NDP exchange is secured >>> using tunnel mode and the hop limit is decremented before the packe >>> t >>> is encapsulated, the receiving node will reject the NDP packet and >>> neighbor discovery will fail, even if the two nodes are on the same >>> link. Should the Hop Limit not be decremented for locally generate >>> d >>> traffic? If not, I don't see how NDP traffic can be secured using >>> tunnel mode - maybe I've missed something in the drafts that said >>> this. If this question has already been answered, I'd appreciate a >>> pointer to the discussion (I didn't see it in the archives). >>> >>> Karen, >>> I would think that if a packet originates at host A, and the >>> packet then gets encapsulated by security gateway G and sent down the >>> IPSEC tunnel to host B, that host A and host B are not on the same >>> network. >>> >>> In fact, even if the packet is originated and encapsulated at >>> host A, and sent over a IPSEC tunnel, which might send the packet >>> halfway across the world, when it is decapsulated at host B, the hop >>> count should be decremented, since it is extremely unlikely that they >>> are really "neighbors". >>> >>> I'm not completely familiar with what exactly NDP is trying to >>> do, but if you're using tunnel mode, you can't distinguish between >>> whether your communications partner is on the same ethernet, or on the >>> wrong side of MAE-EAST (you can tell that by the number of packets tha >>> t >>> get dropped, though :-). If this is what NDP is trying to do, then >>> fundamentally you shouldn't be using tunnel mode. Whether you always >>> decrement the hop count, as the spec currently states, or never >>> decrement the hop count, you still don't know whether someone is next >>> door or on the other side of the planet. >>> >>>My own view is that a tunnel is a virtual wire between two nodes. NDP >>>should work across that tunnel only to the extent that the packet >>>originated on one endpoint and terminated on the other. ("Neighbor" is >>>a topological construct here, and ignores phyiscal reality.) >>> >> >> >Robert Moskowitz >ICSA >Security Interest EMail: rgm-sec@htt-consult.com > --=-==--==-=-===----=-=---=-=--==--=---====-=--=== Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: PGP for Personal Privacy 5.5.2 iQA/AwUBNTzxl5wudNbgUX8fEQJ+6gCgj5GM00Y7z6kwkZPWh+s4eyTz6a8AoMmG aBxiw8jZVFfwUfNl8B/aRXOk =4LVw -----END PGP MESSAGE----- --=-==--==-=-===----=-=---=-=--==--=---====-=--===-- From owner-ipsec Tue Apr 21 15:27:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA27276 for ipsec-outgoing; Tue, 21 Apr 1998 15:26:55 -0400 (EDT) From: Michael Richardson Message-Id: <199804211959.PAA11421@lox.sandelman.ottawa.on.ca> Subject: Re: Hop Limit in Inner Header (IPv6) To: pcurran@ticl.co.uk (Peter Curran) Date: Tue, 21 Apr 1998 15:59:49 -0400 (EDT) Cc: ipsec@tis.com In-Reply-To: from "Peter Curran" at Apr 21, 98 08:20:55 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Peter> of the protocol design is that all NDP messages can only be received from Peter> the link to which you are fastened (physically or logically). By setting Peter> the HL to 255, an attempt to spoof an NDP message by forwarding it onto the Peter> link can be detected. *IF* IPSEC, using tunnel mode ESP, is to be used for Peter> NDP then it is essential that this behaviour is maintained. > Peter> Of course, there may not be a need to use IPSEC in this mode for this purpose. It would seem that there this is something that a v6 implementation should simply not do. My reading of the NDP document suggests that most NDP stuff is done with multicast, and is intended to be used on physical links only. I don't really see the worry. If for some reason one wanted to tunnel NDP datagrams through an ESP tunnel between two link-local machines, the HL on the ESP packet should probably be set to 255, and checked at the other end. From owner-ipsec Tue Apr 21 20:50:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA29167 for ipsec-outgoing; Tue, 21 Apr 1998 20:47:56 -0400 (EDT) Message-Id: <199804220102.VAA03449@relay.rv.tis.com> Date: 21 Apr 1998 21:00 EDT To: ipsec@tis.com From: "Amal Maalouf" Subject: IPsec 41st IEEE meeting Sender: owner-ipsec@ex.tis.com Precedence: bulk In the 41st IEEE meeting somebody gave an address to get a free IPsec implementation and discuss issues in it. Does anybody know this e-mail address? Also, does anybody know of any IPsec commercial or free implemtations? thanks for your help. Amal. From owner-ipsec Tue Apr 21 20:58:06 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA29240 for ipsec-outgoing; Tue, 21 Apr 1998 20:57:56 -0400 (EDT) Message-Id: <199804220110.VAA20482@adk.gr> To: "Amal Maalouf" Cc: ipsec@tis.com Subject: Re: IPsec 41st IEEE meeting In-reply-to: Your message of "21 Apr 1998 21:00:00 EDT." <199804220102.VAA03449@relay.rv.tis.com> Date: Tue, 21 Apr 1998 21:10:21 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- To: "Amal Maalouf" Subject: Re: IPsec 41st IEEE meeting Cc: ipsec@tis.com Date: 04/21/98, 21:10:20 In message <199804220102.VAA03449@relay.rv.tis.com>, "Amal Maalouf" writes: >In the 41st IEEE meeting somebody gave an address to get a free >IPsec implementation and discuss issues in it. Does anybody >know this e-mail address? Also, does anybody know of any IPsec >commercial or free implemtations? That person was John Ioannidis. You can get his code (which is a bit dated by now) from ftp://ftp.funet.fi/pub/unix/security/net/ip/ OpenBSD (IPsec + Photuris) http://www.openbsd.org/ FreeSWAN (for Linux) (IPsec + IKE) http://www.xs4all.nl/~freeswan WIDE Japan (FreeBSD) ?? INRIA France (FreeBSD/NetBSD ?) look around http://www.inria.fr/ It doesn't have the complete IPsec actually (French crypto laws and whatnot) but it has the hooks. Hope this helps. - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBNT1Dfb0pBjh2h1kFAQH3YwP/d/DRM1ZRmT+fyAPQWBJgBpp1yiriHM5T o5S8K3myOCN9GALo/odWKiVdoBhsgwK6EVO8lxH5aPn9Pa5FUsnLKUMvNuvdiLjs Y2FoWXGXOQcWWxLm5dniaV8Vx0hd2zuvVDyxOxuHPzqeDm1Jx3Ud6THMRTw5/q3s Bvh62hSnQR4= =vKas -----END PGP SIGNATURE----- From owner-ipsec Tue Apr 21 22:29:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA29846 for ipsec-outgoing; Tue, 21 Apr 1998 22:27:55 -0400 (EDT) To: "Angelos D. Keromytis" cc: "Amal Maalouf" , ipsec@tis.com In-reply-to: angelos's message of Tue, 21 Apr 1998 21:10:21 -0400. <199804220110.VAA20482@adk.gr> 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: IPsec 41st IEEE meeting From: Jun-ichiro itojun Itoh Date: Wed, 22 Apr 1998 11:41:34 +0900 Message-ID: <3274.893212894@coconut.itojun.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk >That person was John Ioannidis. >You can get his code (which is a bit dated by now) from (snip) >WIDE Japan (FreeBSD) >?? http://www.v6.wide.ad.jp/ ftp://ftp.itojun.org/pub/ipv6/ Thanks, itojun From owner-ipsec Wed Apr 22 08:04:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA05450 for ipsec-outgoing; Wed, 22 Apr 1998 07:57:54 -0400 (EDT) Message-Id: <199804221159.HAA13292@ghostwheel.ncsl.nist.gov> Date: Wed, 22 Apr 1998 07:59:31 -0400 (EDT) To: amalmaal@nortel.ca Cc: ipsec@tis.com From: rob.glenn@nist.gov Subject: Re: IPsec 41st IEEE meeting X-Mailer: Ishmail 1.3.2-970722-linux MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk For US and Canada consumption, you can obtain a free copy of the Cerberus Linux IPsec implementation by going to http://www.antd.nist.gov/cerberus Rob G. rob.glenn@nist.gov From owner-ipsec Wed Apr 22 09:01:48 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA00265 for ipsec-outgoing; Wed, 22 Apr 1998 08:46:56 -0400 (EDT) Message-ID: <353E11A9.2E9F@phase2net.com> Date: Wed, 22 Apr 1998 08:50:01 -0700 From: Jeff Pickering Reply-To: jpickering@phase2net.com Organization: phase2 networks X-Mailer: Mozilla 3.01 (Win16; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: isakmp sa payload Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I am confused about parsing the SA payload and was hoping someone could help enlighten me. It appears that the situation field is variable length and needs to be parsed in the context of the DOI specified in the SA header. For a phase1 payload specifying a DOI of 0, how is the situation parsed? Thanks in advance for any insight. jeff From owner-ipsec Wed Apr 22 09:15:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA00500 for ipsec-outgoing; Wed, 22 Apr 1998 09:15:01 -0400 (EDT) Date: Wed, 22 Apr 1998 16:28:38 +0300 (EET DST) Message-Id: <199804221328.QAA27222@pilari.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "Derrell D. Piper" Cc: wdm@epoch.ncsc.mil (W. Douglas Maughan), ipsec@tis.com Subject: Re: ISAKMP - Remaining Issues In-Reply-To: <199804211910.MAA09191@gallium.network-alchemy.com> References: <9804211136.AA09244@dolphin.ncsc.mil> <199804211910.MAA09191@gallium.network-alchemy.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 6 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Derrell D. Piper writes: > As you know, earlier versions of the ISAKMP drafts had stated that each > payload should begin on a longword-aligned boundary. This was changed around > Munich based on feedback from a number of folks to simply align the entire > message, which really only aligns the unprotected exchanges. The question now is what does it mean to align the entire message? The message is one udp-packet how that can be aligned? Some interpretation of that was that the length of the message should be padded so that the size of the message is 4 byte multiple. > I don't feel that there's a significant processing win to aligning the > individual payloads, but I don't object to that either. However, we have > changed the draft already once to remove the payload alignment requirement. I don't think that anybody is asking to align payloads, the current draft is ok, and it should not be changed now in that part. > So, I'd prefer to keep the draft as currently written. I would just like to remove the whole text about message alignment from the draft, so modify this: ---------------------------------------------------------------------- 3 ISAKMP Payloads ISAKMP payloads provide modular building blocks for constructing ISAKMP messages. The presence and ordering of payloads in ISAKMP is defined by and dependent upon the Exchange Type Field located in the ISAKMP Header (see Figure 2). The ISAKMP payload types are discussed in sections 3.4 through 3.15. The descriptions of the ISAKMP payloads, messages, and ex- changes (see Section 4) are shown using network octet ordering. Addition- ally, all ISAKMP messages MUST be aligned at 4-octet multiples. ---------------------------------------------------------------------- to: ---------------------------------------------------------------------- 3 ISAKMP Payloads ISAKMP payloads provide modular building blocks for constructing ISAKMP messages. The presence and ordering of payloads in ISAKMP is defined by and dependent upon the Exchange Type Field located in the ISAKMP Header (see Figure 2). The ISAKMP payload types are discussed in sections 3.4 through 3.15. The descriptions of the ISAKMP payloads, messages, and ex- changes (see Section 4) are shown using network octet ordering. ---------------------------------------------------------------------- (just remove "Additionally, all ISAKMP messages MUST be aligned at 4-octet multiples." sentence). -- kivinen@iki.fi Work : +358-9-4354 3207 Magnus Enckellin kuja 9 K 19, 02610, Espoo Home : +358-9-502 1573 From owner-ipsec Wed Apr 22 10:41:40 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA01047 for ipsec-outgoing; Wed, 22 Apr 1998 10:40:02 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01125ABF@wade.reo.dec.com> From: Tom Kiely To: "'ipsec@tis.com'" Subject: Ephemeral Diffie Hellman Date: Wed, 22 Apr 1998 15:51:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, my last two attempts at sending this seem to have got lost. Apologies if it has been received before. I'm having difficulty locating any information about "Ephemeral Diffie Hellman" for IKE. I have the blurb on Anonymous DH but there seems to be no info on the Ephemeral variant. Can anyone point me to some enlightenment ?. Thanx in advance, Tom. From owner-ipsec Wed Apr 22 11:34:40 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA01637 for ipsec-outgoing; Wed, 22 Apr 1998 11:34:04 -0400 (EDT) Message-ID: <353E2401.6F2E@phase2net.com> Date: Wed, 22 Apr 1998 10:08:17 -0700 From: Jeff Pickering Reply-To: jpickering@phase2net.com Organization: phase2 networks X-Mailer: Mozilla 3.01 (Win16; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: isakmp sa attributes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk The IKE spec states that a phase1 sa negotiation must include the DH group. It seems to me that the group description attribute would be sufficient for the 768 bit modp group. My quess would be that the group type and field size attributes are only for private groups and are therefore not required as part of the negotiation. Is this correct? If so, what should be done if, for example, these attributes are included when specifying one of the 4 standard groups? jeff From owner-ipsec Wed Apr 22 12:07:42 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA01943 for ipsec-outgoing; Wed, 22 Apr 1998 12:06:03 -0400 (EDT) Message-Id: <199804221619.JAA07986@gallium.network-alchemy.com> To: Tero Kivinen cc: wdm@epoch.ncsc.mil (W. Douglas Maughan), ipsec@tis.com Subject: Re: ISAKMP - Remaining Issues In-reply-to: Your message of "Wed, 22 Apr 1998 16:28:38 +0300." <199804221328.QAA27222@pilari.ssh.fi> Date: Wed, 22 Apr 1998 09:19:29 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk That's fine with me too. How do the rest of the folks with implementations feel about this? Derrell From owner-ipsec Wed Apr 22 13:37:19 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA02520 for ipsec-outgoing; Wed, 22 Apr 1998 13:35:11 -0400 (EDT) Message-ID: <353E2D31.5346EE3E@redcreek.com> Date: Wed, 22 Apr 1998 10:47:29 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: "Derrell D. Piper" CC: ipsec@tis.com Subject: Re: ISAKMP - Remaining Issues References: <199804221619.JAA07986@gallium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Derrell D. Piper wrote: > > That's fine with me too. How do the rest of the folks with implementations > feel about this? > I agree that the alignment MUST is unnecessary. Traditionally, processing convenience (e.g. alignment) is the overriding concern INSIDE a system, and packet overhead is the overriding concern on the wire. From owner-ipsec Wed Apr 22 14:43:01 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA02898 for ipsec-outgoing; Wed, 22 Apr 1998 14:41:26 -0400 (EDT) Message-Id: <3.0.2.32.19980422115240.006d40d4@pita.cisco.com> X-Sender: shacham@pita.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Wed, 22 Apr 1998 11:52:40 -0700 To: "'iesg@ns.ietf.org'" From: Avram Shacham Subject: RE: Last Call: IPSec DOI Proposed Standard Cc: ipsec@tis.com, ippcp@external.cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk The document is inconsistent with the IP Payload Compression Protocol (IPComp) as defined in . Regards, avram 4.4.5 IPSEC IPCOMP Transform Identifiers The IP Compression (IPCOMP) transforms define optional compression algorithms that can be negotiated to provide for IP compression before ESP encryption. ^^^^^^^^^^^^^^^^^^^^^ Is this very partial definition needed? 6.6 IPSEC IPCOMP Transform Identifiers The IPSEC IPCOMP Transform Identifier is an 8-bit value which ^^^^^I-D defines 1-63(6 bit) identifier a particular algorithm to be used to provide IP-level compression before ESP. Requests for assignments of new IPCOMP ^^^^^^^^^^^^^^^^^^^^^^ see above transform identifiers must be accompanied by a standards-track RFC which describes how to use the algorithm within the IPCOMP framework ([IPCOMP]). In addition, the requested algorithm must be published and in the public domain. If the requested algorithm is not in the public domain, the addition must be approved by an IESG action. The values 249-255 are reserved for private use amongst cooperating ^^^^^^^ 58-63? systems. === end of comments === From owner-ipsec Wed Apr 22 22:30:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA05741 for ipsec-outgoing; Wed, 22 Apr 1998 22:28:27 -0400 (EDT) Date: Wed, 22 Apr 1998 22:37:16 -0400 Message-Id: <199804230237.WAA16620@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Avram Shacham Cc: "'iesg@ns.ietf.org'" , ipsec@tis.com, ippcp@external.cisco.com In-Reply-To: Avram Shacham's message of Wed, 22 Apr 1998 11:52:40 -0700, <3.0.2.32.19980422115240.006d40d4@pita.cisco.com> Subject: Re: Last Call: IPSec DOI Proposed Standard Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Wed, 22 Apr 1998 11:52:40 -0700 From: Avram Shacham The document is inconsistent with the IP Payload Compression Protocol (IPComp) as defined in . Thanks for catching this. I think that the draft we need to change is the IPComp draft, though. It assumes that the transform identifiers are 16-bits: 16-bit index. The CPI is stored in network order. The values 0-63 define well-known compression algorithms, which require no additional information, and are used for manual setup. The values themselves are identical to IPCOMP Transform identifiers as defined in [SECDOI]. Consult [SECDOI] for an initial set of defined values and for instructions on how to assign new values. The values 64-61439 are negotiated between the two nodes in definition of an IPComp Association, as defined in section 4. Note: When negotiating one of the well-known algorithms, the nodes MAY select a CPI in the pre-defined range 0-63. The values 61440-65535 are for private use among mutually consenting parties. However, ISAKMP only supports 8 bits worth of transform id's. Hence, the text in IPComp needs fixing. In harmonizing the IPComp draft with the DOI draft, it would seem to me that the way to do this is to adopt the IANA considerations in the DOI draft. The IPCOMP draft doesn't have an IANA considerations, and as stated previously, it incorrectly assumes that transform ID's were 16-bits instead of 8 bits in ISAKMP. Comments? - Ted From owner-ipsec Thu Apr 23 00:36:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA06379 for ipsec-outgoing; Thu, 23 Apr 1998 00:35:29 -0400 (EDT) Message-Id: <3.0.2.32.19980422214828.006b0c78@pita.cisco.com> X-Sender: shacham@pita.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Wed, 22 Apr 1998 21:48:28 -0700 To: "Theodore Y. Ts'o" From: Avram Shacham Subject: Re: Last Call: IPSec DOI Proposed Standard Cc: "'iesg@ns.ietf.org'" , ipsec@tis.com, ippcp@external.cisco.com In-Reply-To: <199804230237.WAA16620@dcl.MIT.EDU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Theodore, In a simple analogy to IPSec, the 16-bit CPI of IPComp is the equivalent of the 32-bit SPI, and the 6-bit IPCOMP Transform Identifiers, which define well-known compression algorithms, are similar to the 8-bit ESP and AH Transform Identifiers. IPSec DOI provides the numeric and symbolic definitions for all those Identifiers. In IPComp, the Transform Identifiers can also serve as CPI, with the benefit of saving the receiving node the CPU cycles to locate the compression algorithm by CPI. This method is also handy for manually configured nodes. As for the numeric range of the IPComp Transform Identifiers - in Munich, the IPPCP working-group decided - given the number of existing compression algorithms - to allocate the IDs 1-63 for such known algorithms. The decision is reflected in the IPComp I-D. The DOI document did not follow this decision. In IPSec/IKE bakeoff in March 98, several vendors successfully negotiated IPComp using IKE, so I see no conflict here. Also, IANA did read and provided comments to the IPComp I-D and those comments were incorporated in the document. Therefore, the right way to go is to correct the DOI doc. Regards, avram At 10:37 PM 4/22/98 -0400, Theodore Y. Ts'o wrote: > Date: Wed, 22 Apr 1998 11:52:40 -0700 > From: Avram Shacham > > The document is inconsistent with the IP > Payload Compression Protocol (IPComp) as defined in > . > >Thanks for catching this. I think that the draft we need to change is >the IPComp draft, though. It assumes that the transform identifiers are >16-bits: > > 16-bit index. The CPI is stored in network order. The values > 0-63 define well-known compression algorithms, which require no > additional information, and are used for manual setup. The > values themselves are identical to IPCOMP Transform identifiers > as defined in [SECDOI]. Consult [SECDOI] for an initial set of > defined values and for instructions on how to assign new values. > The values 64-61439 are negotiated between the two nodes in > definition of an IPComp Association, as defined in section 4. > Note: When negotiating one of the well-known algorithms, the > nodes MAY select a CPI in the pre-defined range 0-63. The > values 61440-65535 are for private use among mutually consenting > parties. > >However, ISAKMP only supports 8 bits worth of transform id's. Hence, >the text in IPComp needs fixing. In harmonizing the IPComp draft with >the DOI draft, it would seem to me that the way to do this is to adopt >the IANA considerations in the DOI draft. The IPCOMP draft doesn't have >an IANA considerations, and as stated previously, it incorrectly assumes >that transform ID's were 16-bits instead of 8 bits in ISAKMP. > >Comments? > > - Ted > > From owner-ipsec Thu Apr 23 09:10:46 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA09334 for ipsec-outgoing; Thu, 23 Apr 1998 09:01:35 -0400 (EDT) Message-Id: <3.0.32.19980423091432.00687f3c@bl-mail1.corpeast.baynetworks.com> X-Sender: ndoraswa_pop@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 23 Apr 1998 09:14:34 -0400 To: "Theodore Y. Ts'o" , Avram Shacham From: Naganand Doraswamy Subject: Re: Last Call: IPSec DOI Proposed Standard Cc: ipsec@tis.com, ippcp@external.cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Ted, Avram's point is correct. The IPPCP working group felt that 6 bits was sufficient for the transform ID. The DOI document should reflect this. Thanks, --Naganand ----------------------------------------------------------------- Naganand Doraswamy (978)916-1323 (O) Bay Architecture Lab (978)916-0620 (Fax) 3 Federal St, Mail Stop BL3-03 Billerica, MA 01821 From owner-ipsec Thu Apr 23 13:20:52 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA11082 for ipsec-outgoing; Thu, 23 Apr 1998 13:18:34 -0400 (EDT) Message-Id: <199804231731.KAA05830@gallium.network-alchemy.com> To: "Theodore Y. Ts'o" cc: Avram Shacham , "'iesg@ns.ietf.org'" , ipsec@tis.com, ippcp@external.cisco.com Subject: Re: Last Call: IPSec DOI Proposed Standard In-reply-to: Your message of "Wed, 22 Apr 1998 22:37:16 EDT." <199804230237.WAA16620@dcl.MIT.EDU> Date: Thu, 23 Apr 1998 10:31:29 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk All, The ISAKMP protocol defines the size of its Transform ID field as one octet. The IPSEC DOI defines the legal values for this field when using IPSEC with ISAKMP (as IPPCP does). If IPPCP wants to use only six bits of the octet for the compression transform identifier, that's fine, but it's still eight bits on the wire in ISAKMP. It can also be just six bits in the IPPCP protocol. The current IPSEC DOI says that the values not defined in the IPSEC DOI are reserved to IANA and that requests to IANA must be accompanied by a standards track RFC, like IPPCP, that details the use of the requested allocation. The only potential problem I see is that the IPSEC DOI does state that "the values 249-255 are reserved for use private use amongst cooperating systems." I will correct this in the next draft. Derrell From owner-ipsec Thu Apr 23 16:43:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA12456 for ipsec-outgoing; Thu, 23 Apr 1998 16:41:35 -0400 (EDT) Date: Thu, 23 Apr 1998 16:55:03 -0400 Message-Id: <199804232055.QAA17248@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Avram Shacham Cc: "Theodore Y. Ts'o" , "'iesg@ns.ietf.org'" , ipsec@tis.com, ippcp@external.cisco.com In-Reply-To: Avram Shacham's message of Wed, 22 Apr 1998 21:48:28 -0700, <3.0.2.32.19980422214828.006b0c78@pita.cisco.com> Subject: Re: Last Call: IPSec DOI Proposed Standard Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Wed, 22 Apr 1998 21:48:28 -0700 From: Avram Shacham In a simple analogy to IPSec, the 16-bit CPI of IPComp is the equivalent of the 32-bit SPI, and the 6-bit IPCOMP Transform Identifiers, which define well-known compression algorithms, are similar to the 8-bit ESP and AH Transform Identifiers. IPSec DOI provides the numeric and symbolic definitions for all those Identifiers. Thanks for setting me straight for how the IPCOMP was used. It wasn't immediately obvious to me from reading the IPCOMP draft. Stupid question --- what was the reason why IPCOMP limited the number of transform identifiers to 6-bits? If we changed the number of transform identifiers to 8-bits, it decreases the number of CPI's available for dynamically assigned CPI's from 61,376 to 61,184. I wouldn't think that the range of dynamically assigned CPI's would be drastically decreased if we were to lower that range by 192 transforms. As for the numeric range of the IPComp Transform Identifiers - in Munich, the IPPCP working-group decided - given the number of existing compression algorithms - to allocate the IDs 1-63 for such known algorithms. The decision is reflected in the IPComp I-D. The DOI document did not follow this decision. Our apologies. Both I and the DOI editor were not aware of this decision. That being said, could you enlighten us as to why the ippcp wg made that decision? We can very easily make the DOI document state that the number of transforms is limited to the range 0-63 (despite the fact that the ISAKMP protocol has room for 8 bits), with say 0-53 to be assigned by the IANA, and 54-63 to be used by mutually consenting implementations. It would seem to me to be limiting the number space unnecessarily, though. Our other choice would be to change the IPCOMP draft to align with the DOI draft. This increases the number of static transforms from 64 to 256, and means that ISAKMP implementations should only hand out CPI's which are in the range 256 to 61439. (instead of using the range 63 to 61439). Although I'm not an expert on the issues which the ippcp group is facing, it would seem to me that increasing the number of static transforms would be a good thing. I've gotten nervous about the fact that we only have 8 bits for some of the other ISAKMP negotiated fields, which is why the IANA consideration is extremely miserly about how those numbers are handed out, lest we run out. However, if the IPPCP group feels strongly about this, we can go ahead and make the change to the DOI. (This is otherwise known as "your funeral, not mine, if we run out of ipcomp transform id's." :-) - Ted From owner-ipsec Thu Apr 23 19:32:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA13421 for ipsec-outgoing; Thu, 23 Apr 1998 19:30:34 -0400 (EDT) Date: Thu, 23 Apr 1998 20:24:24 -0400 From: Gordon Oliver Subject: Re: IPsec 41st IEEE meeting To: ipsec@tis.com Cc: amalmaal@nortel.ca Message-Id: X-Mailer: TkMail 4.0beta9 Sender: owner-ipsec@ex.tis.com Precedence: bulk Angelos D. Keromytis said... >In message <199804220102.VAA03449@relay.rv.tis.com>, "Amal Maalouf" writes: >>In the 41st IEEE meeting somebody gave an address to get a free >>IPsec implementation and discuss issues in it. Does anybody >>know this e-mail address? Also, does anybody know of any IPsec >>commercial or free implemtations? > >That person was John Ioannidis. > >You can get his code (which is a bit dated by now) from >ftp://ftp.funet.fi/pub/unix/security/net/ip/ > >OpenBSD (IPsec + Photuris) >http://www.openbsd.org/ > >FreeSWAN (for Linux) (IPsec + IKE) >http://www.xs4all.nl/~freeswan > there is also LIPsec (Linux-IPsec) at ftp://ftp.funet.fi/pub/unix/security/net/ip The version that is currently there (0.5) is very dated. but I uploaded a new version (0.7) yesterday, and hopefully it will appear soon. -gordo --------------------------------------------------------------- Gordon Oliver (gordo@telsur.cl) Independent Consultant ... Available for consulting on Linux ... From owner-ipsec Thu Apr 23 21:53:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA14232 for ipsec-outgoing; Thu, 23 Apr 1998 21:51:38 -0400 (EDT) Date: Thu, 23 Apr 1998 22:05:52 -0400 Message-Id: <199804240205.WAA17322@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Cc: "Amal Maalouf" Subject: Meeting minutes for the LA IPSEC meeting Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi all, My apologies for the last-minute of these minutes. Life got busier than I expected, and so I didn't have time to get these done until now. I'd appreciate if folks could make comments on these minutes quickly, as the IETF secretariat's deadline for submitting minutes to be published in the IETF proceedings is tomorrow (Friday). There is also an HTML version of these minutes at: http://web.mit.edu/tytso/www/ipsec/los_angelos where you will also find links to the slides for the presentations given by John Ioannidis and Ran Cannetti. If any of the other presenters have slides available, please send them to me, so I can include them in the minutes. Many thanks, - Ted Los Angelos IETF (March/April 1997) Working Group Meeting Minutes DRAFT DRAFT DRAFT The IPSEC working group met on Thursday, April 2nd, 1998, at the IETF meeting in Los Angelos, California. The Agenda was as follows: * Agenda Bashing * Final Document Edits * Whither AH? * Free IPSEC Implementation survey * Raleigh interoperability issues * CA Interoperability issues * IPsec Web-based Interoperability Tool * IPSec configuration (isakmp-cfg) * Smart card/RADIUS support in ISAKMP * IPSec policy modeling * Elliptic Curve Cryptography in IPSec * Secure Multicast Issues Final Document Edits ==================== Ted Ts'o asked the IPSEC document editors who had any final editorial changes to submit them ASAP. Whither AH? =========== Bob Moskowitz presented the question of "Whither AH?". There are a some folks who would like AH to be optional; others want to keep it. There are some technical issues with AH --- the fact that the checksum is at the beginning of the AH packet makes it hard to do AH in hardware. However, there is a real requirement for the AH mechanism for IPv6. Making AH a "should" for IPv4 and a "must" for IPv6 doesn't seem to work, since the same problems with IPV4 will be faced for IPv6. Peter Ford from Microsoft commented that the useful functionality of AH has been moved to ESP. He recommended that AH to be dropped entirely, but willing to live with a "should". Steve Bellovin noted that he had recommended removing AH 3 years ago in Stockholm. After much discussion, the working group decided to keep it. He saw no reason to re-open the discussion. Steve Kent made the following comments: ESP is fine as it is, and ESP can be used in an authentication mode with null encryption. However, there is a legitimate functionality that AH supports. Others noted that everyone in the Raleigh interoperability testing was doing AH, and we should just do it. There was a concern expressed that if we didn't get rid of it now, it would never go away. Also, that IPSEC was too complex and anything to reduce complexity would be a good thing. On the other hand, AH is a very small part of a complete IPSEC implementation, and it doesn't cost much to test. It was noted that the IPV6 router renumbering relies on AH. Peter Ford said that it was Microsoft's desire to ship a product that is 100% IETF compliant. The implementations will be much simpler and drive it to the smallest possible set of features. If AH is a "should", will Microsoft support it? Microsoft not willing to make that statement at this point. Jeff Schiller pointed out that there was a difference between "SHOULD" and "MAY", and that although folks were talking about changing AH to be a "SHOULD", their arguments and statements indicated that they were treating it as a "MAY". Jeff Schiller, as Area Director, took the floor. He pointed out that were at the proposed standard stage, the first step in the standardization process. Normally this doesn't even require working implementations, which we already have here. At the proposed standard status, whether something is a "SHOULD" or "MUST" it not that important; we can change it either way later. However, what we cannot do is NOT move forward at all. Jeff proposed compromise of making AH a "SHOULD" but that vendors would be put on notice that we might change this in the future. Vendors would be warned that this "SHOULD" would be a real "SHOULD" that they should really implement, and not just a "MAY". As we go to draft standard, this might become a "MUST". Jeff took a straw poll to determine if people wanted to make such a change, or to leave the document alone and keep AH a "MUST". Jeff declared a clear consensus to keep AH mandatory. Free IPSEC Implementation survey ================================ John Ioannidis from AT&T was interested in doing a survey of "free" IPSEC implementations. He asked those with free implementations of IPsec code to send him e-mail to: ji@research.att.com with the subject line "FREE IPSEC". He would summarize the responses to the ipsec mailing list. Raleigh interoperability issues =============================== Rodney Thayer from Sable technology presented a list of issues that were found at the Raleigh interoperability workshop. This list included: 1. ISAKMP SPI Sizes Some implementations got upset (i.e. crash) when offered different sizes of SPIs eg. 2 octets was required for IP Compression. 2. Correctly Ordered Payloads For some vendors, ISAKMP payloads had to be in the order that they are documented. Most ISAKMP payloads may be sent in any order (except for the SA, Proposal and Transform payloads) 3. IP Addresses in Certificates Some people expected strings, other expected 4 octets in ipAddress "It is never a string when encoded in subjectAltName" "... consensus was that if IP Addresses (or dns name or rfc822 name) were going to be added to an X.509 certificate then they should go into the subjectAltName extension (that is after all what it is for). This is consistent with work done in the PKIX WG" 4. No IP Address in Certificate An IP Address does not have to be within the certificate if the IPSec entity is mobile and uses a dynamic address. But, there must be some other type of identity within the certificate (rfc822name, domain name, X.500 DN) 5. Replay of Zero Some implementations were sending a replay prevention value of 0 when doing manually keying. In the discussion which followed, Steve Kent noted that this was incorrect behavior, since the replay prevention field must be incremented. 6. AH & Auth Attribute Some vendors were not sending both the AH Transform type (e.g. AH_MD5) and the Authentication Algorithm attribute (e.g. HMAC-MD5) Some vendors would not accept receiving both the Transform type and the Authentication Algorithm attribute 7. New CertReq Format Some vendors were using the old isakmp-08 certificate request format 8. Hash in RSA Encryption Some vendors did not like getting a key hash payload in rsa encryption mode 9. Unknown Notify Payloads Some vendors were discarding entire ISAKMP packet when an unknown notify payload was received (ie. INITIAL-CONTACT). Only the single Notify payload should be discarded 10. Handling CertReq Some vendors did not like receiving certificate request payloads when using pre-shared keys The isakmp draft says certificate requests payloads can exist in any message Some vendors did not like receiving certificate request payloads at any time 11. Packet Padding Some vendors did not like ISAKMP packets to be padded to a multiple of 4 byte. The ISAKMP draft states that the ISAKMP message MUST be 4-octet aligned. 12. IDui & Idur Some vendors expected to see client ID's in phase 2 (QuickMode), even though they are optional This caused QuickMode to complete, but fail to setup the correct SAs 13. IP4_ADDR_RANGE Some vendors do not accept a QuickMode ID type of IP4_ADDR_RANGE while they do accept IP4_ADDR and IP4_ADDR_SUBNET 14. Nonce Sizes Some vendors could not handle larger sized nonces (40 bytes) and would only allow 20 byte nonces The new IKE document does state: "The length of nonce payload MUST be between 8 and 256 bytes inclusive." 15. Overlapping SAs Some vendors did not support having a SA with the whole subnet at the same time as another SA with one host in that subnet 16. CONNECT Notify Message Due to QuickMode's 1.5 exchanges, the initiator might not know that the responder did not receive the 3rd message One vendor suggested we should send a Notify CONNECT message for the responder's 2nd quickmode message When this item was discussed, it was noted that this was not necessary because of the COMMIT bit in the ISAKMP header. CA Interoperability issues ========================== Rodney Thayer gave a presentation of the requirements which IPSEC places on a Public Key Infrastructure. (This presentation was also given at the PKIX working group.) Rodney has written a draft document which is currently available at: ftp://module-one.tillerman.nu/pub/draft-thayer-ipsec-pki-00.txt After Rodney finished his presentation, a developer from Microsoft noted that there were speed/performance problems with the certificate verifications; the time needed to do the certificate processing was causing TCP SYN's to get queued up and be dropped. Discussion followed, with participants noting that IPSEC implementors need to collect timing requirements and give that experience to the PKIX people. A volunteer is needed to collect this information. IPsec Web-based Interoperability Tool ===================================== Rob Glen presented a web-based interoperability testing tool developed by NIST to test the IPSEC protocols. The URL for this service is: http://IPsec-wit.antd.nist.gov/ The testing tool is semi-automated, and driven using WWW forms. There are currently 70 test cases covering AH and ESP using IPV4, and there are plans to expand the service to include test cases for IKE, PKIX, and IPv6. The tool is based on the NIST Cerberos IPsec implementation. The source code to the testing tool is available for those who would like to port the tool to be based on other IPSEC implementations. In the discussion that followed it was noted that SSH Communications Security has a web-based service to test IKE (nee ISAKMP/Oakley) implementations. This was announced at the last IETF meeting. The URL for this testing site is: http://isakmp-test.ssh.fi IPSec configuration (isakmp-cfg) ================================ Roy Pereira from Timestep presented a proposal for doing configuration under ISAKMP. This proposal was conceieved to request an internal IP address from a security gateway in a secure fashion. (Since this needs to happen before the IKE negotiation is completed, it is not possible to use protocols such as Radius or DHCP.) Instead, it uses ISAKMP for management and tranport. There is currently a draft proposal available: draft-ietf-ipsec-isakmp-mode-cfg-02.txt. This work is currently not part of the working group charter, but this is an important work item to consider for the new working group charter for futher work for this working group. During the discussion, there was a question raised of how this would impact Mobile IP, especially in light of RFC-2002. One person thought that this might be orthagonal, but more investigation into this issue is necessary. Smart card/RADIUS support in ISAKMP =================================== Roy Periera also discussed his proposal to extend IKE to accept the use of extended authentication techniques such as time-variant smart cards, two factor authentication, challenge/response and other user-based authentication schemes. An initial draft of his work is available at: draft-ietf-ipsec-isakmp-xauth-01.txt. During the discussion, the working group asked Roy why this was done inside IKE; the answer was so that it could be done securely. One person suggested that Roy look at EAP. Roy noted that more discussion was needed for his proposal, which was still in the early design phase. IPSec policy modeling ===================== Finally, Roy presented a proposed IPsec Policy Data Model. The goal is to provide implementers sufficient information on the base IPsec negotiation mechanism so that they can create a correct enterprise policy architecture. There is an initial Internet Draft describing this model: draft-ietf-ipsec-policy-model-00.txt. Elliptic Curve Cryptography in IPSec ==================================== Paul Lambert from Certicom gave a presentation of Elliptical Curve (EC) cryptography. EC systems are much faster, and so are popular in implementations driven by constrained devices (e.g., Windows CE, pagers, etc.) Certicom's web site has tutorials on the technology. Certicom has suggested that IPSEC use "better curves" based on prime fields. Discussion centered over two main issues. The first are the IPR/patent issues in the EC space, of which there are many. Certicom has a large number of patents optimizing EC cryptography. Not all patents have been issued yet, so Certicom can not disclose all of them. It was suggested that Certicom put together an internet draft that discusses or describes what portions are available for public use. More discussion also centered around the optimizations which can be applied to EC. Some optimizations only apply to hardware implementations. The current curves proposed in the Oakley draft are not prime fields and have software speedups which do not apply if the fields used are prime fields, as Certicom proposes. (There are hardware optimizations, which may be patented by Certicom, which do apply to prime fields, however.) Furthermore, there is disagreement amongst mathematicians as to whether whether prime fields are more secure than non-prime fields. Ted Ts'o observed than when comparing the speed of EC's, it is important to consider both software and hardware implementations, as well as comparing the speed with and without the use of patented optimization techniques. Secure Multicast Issues ======================= Ron Cannetti from IBM research gave a presentation sketching the scope of the Secure Multicast problem. Different applications may have very different group characteristics, security requirements, performance requirements, etc. Ran ended with a survey of existing solutions with differing properties. Bob Moskowitz observed that the working group will have to decide on a specific scope before we will be able to profitably tackle the secure multicast as a tractable problem. Ideally, some customers would ask the IETF to solve a specific problem. From owner-ipsec Fri Apr 24 00:26:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA14990 for ipsec-outgoing; Fri, 24 Apr 1998 00:24:36 -0400 (EDT) Message-Id: <3.0.1.32.19980424083553.006b3e8c@192.9.200.10> X-Sender: srinu@192.9.200.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) X-Priority: 1 (Highest) Date: Fri, 24 Apr 1998 08:35:53 +0500 To: ipsec@tis.com From: K SrinivasRao Subject: How to select SPD Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, In case of automatic key managent, when the initiator sends multiple proposals to the responder, the responder has to select one of the proposal. For this he has to check the proposals that has been sent against what he can support which are present in his SPD. But how he will select which incoming SPD entry he has to use? Where do we get the selectors to select an SPD entry? We will get src and dest IP address from the packet, but that is not sufficient for selecting an SPD entry. One more confirmation regarding SPI I want. Suppose we have two hosts H1 and H2. If H1 is the initiator and sends SPI values in the proposal to H2, will this SPI value be used for the outbound SA from H1 or inbound to H1? And vice versa for H2 when it returns the selected proposal? Thanking U All. SrinivasRao. B. Kulkarni Rendezvous On Chip Pvt Ltd. First Floor, Plot No. 14, NewVasaviNagar, Kharkhana, SECUNDERABAD - 500019. INDIA Ph : (040)7742606 email address : srinu@trinc.com From owner-ipsec Fri Apr 24 00:41:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA15150 for ipsec-outgoing; Fri, 24 Apr 1998 00:41:36 -0400 (EDT) Message-Id: <3.0.2.32.19980423215251.006d74c0@pita.cisco.com> X-Sender: shacham@pita.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Thu, 23 Apr 1998 21:52:51 -0700 To: "Theodore Y. Ts'o" From: Avram Shacham Subject: Re: Last Call: IPSec DOI Proposed Standard Cc: "'iesg@ns.ietf.org'", ipsec@tis.com, ippcp@external.cisco.com In-Reply-To: <199804232055.QAA17248@dcl.MIT.EDU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 04:55 PM 4/23/98 -0400, Theodore Y. Ts'o wrote: [...] > As for the numeric range of the IPComp Transform Identifiers - in Munich, > the IPPCP working-group decided - given the number of existing compression > algorithms - to allocate the IDs 1-63 for such known algorithms. The > decision is reflected in the IPComp I-D. The DOI document did not follow > this decision. > >Our apologies. Both I and the DOI editor were not aware of this >decision. The DOI editor _is_ a member of the IPPCP mailing list from day one, so he must have been aware of the wg decisions in Munich. Also, I pointed these inconsistencies to the DOI editor in several private email messages many weeks ago. >That being said, could you enlighten us as to why the ippcp >wg made that decision? Currently, the market offers 4 (four) compression algorithms. The IPPCP wg felt that less than 50 (fifty) new algorithms are expected in the foreseeable future. >We can very easily make the DOI document state that the number of >transforms is limited to the range 0-63 (despite the fact that the >ISAKMP protocol has room for 8 bits), with say 0-53 to be assigned by >the IANA, and 54-63 to be used by mutually consenting implementations. >It would seem to me to be limiting the number space unnecessarily, >though. Please do. After all, six weeks ago the IESG approved the publication of IP Payload Compression Protocol (IPComp) _only_ as a Proposed Standard (but waiting for two IPSec docs.) If future experience proves the IPCOMP Transform Identifiers range is too narrow, there is always room for improvements. Regards, avram From owner-ipsec Fri Apr 24 10:22:07 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA19029 for ipsec-outgoing; Fri, 24 Apr 1998 10:10:39 -0400 (EDT) Message-Id: <199804241402.KAA11095@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-mode-cfg-03.txt Date: Fri, 24 Apr 1998 10:02:02 -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 : The ISAKMP Configuration Method Author(s) : B. Patel, R. Pereira, S. Anand Filename : draft-ietf-ipsec-isakmp-mode-cfg-03.txt Pages : 12 Date : 23-Apr-98 This document describes a new ISAKMP method that allows configuration items to be exchanged securely by using both push/acknowledge or request/reply paradigms. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-isakmp-mode-cfg-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-mode-cfg-03.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-isakmp-mode-cfg-03.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: <19980423131527.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-mode-cfg-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-mode-cfg-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980423131527.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Fri Apr 24 12:08:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA19780 for ipsec-outgoing; Fri, 24 Apr 1998 12:07:05 -0400 (EDT) Message-ID: <3540BBCF.4E18286A@redcreek.com> Date: Fri, 24 Apr 1998 09:20:31 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: K SrinivasRao CC: ipsec@tis.com Subject: Re: How to select SPD References: <3.0.1.32.19980424083553.006b3e8c@192.9.200.10> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk K SrinivasRao wrote: > > Hello, > > In case of automatic key managent, when the initiator sends multiple > proposals to the responder, the responder has to select one of the > proposal. For this he has to check the proposals that has been sent against > what he can support which are present in his SPD. But how he will select > which incoming SPD entry he has to use? Where do we get the selectors to > select an SPD entry? We will get src and dest IP address from the packet, > but that is not sufficient for selecting an SPD entry. The ID payload also supports (one) protocol/port pair, and you could also include other ID types in that payload (ASN.1 {DN | GN}, Key ID). From owner-ipsec Fri Apr 24 13:32:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA20408 for ipsec-outgoing; Fri, 24 Apr 1998 13:31:11 -0400 (EDT) Message-ID: <3540CF70.937945D4@redcreek.com> Date: Fri, 24 Apr 1998 10:44:16 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: K SrinivasRao , ipsec@tis.com Subject: Re: How to select SPD References: <3.0.1.32.19980424083553.006b3e8c@192.9.200.10> <3540BBCF.4E18286A@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Scott G. Kelly wrote: > > K SrinivasRao wrote: > > Where do we get the selectors to > > select an SPD entry? We will get src and dest IP address from the packet, > > but that is not sufficient for selecting an SPD entry. > > The ID payload also supports (one) protocol/port pair, and you could > also include other ID types in that payload (ASN.1 {DN | GN}, Key ID). I should also have noted that you will only get src/dest IP out of the packet if they are not present in the ID payload... From owner-ipsec Fri Apr 24 13:33:31 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA20445 for ipsec-outgoing; Fri, 24 Apr 1998 13:33:08 -0400 (EDT) Message-ID: <3540CFF2.89123731@redcreek.com> Date: Fri, 24 Apr 1998 10:46:26 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: K SrinivasRao CC: ipsec@tis.com Subject: Re: How to select SPD References: <3.0.1.32.19980424083553.006b3e8c@192.9.200.10> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk K SrinivasRao wrote: > > One more confirmation regarding SPI I want. > Suppose we have two hosts H1 and H2. > > If H1 is the initiator and sends SPI values in the proposal to H2, will > this SPI value be used for the outbound SA from H1 or inbound to H1? And > vice versa for H2 when it returns the selected proposal? > H1 can only specify its own SPI, hence the SPI sent from H1 MUST apply to the SA which is inbound to H1 (from H2). From owner-ipsec Fri Apr 24 14:14:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA20723 for ipsec-outgoing; Fri, 24 Apr 1998 14:14:10 -0400 (EDT) Date: Fri, 24 Apr 1998 14:28:30 -0400 Message-Id: <199804241828.OAA17558@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Avram Shacham Cc: "Theodore Y. Ts'o" , "'iesg@ns.ietf.org'", ipsec@tis.com, ippcp@external.cisco.com In-Reply-To: Avram Shacham's message of Thu, 23 Apr 1998 21:52:51 -0700, <3.0.2.32.19980423215251.006d74c0@pita.cisco.com> Subject: Re: Last Call: IPSec DOI Proposed Standard Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Thu, 23 Apr 1998 21:52:51 -0700 From: Avram Shacham Please do. After all, six weeks ago the IESG approved the publication of IP Payload Compression Protocol (IPComp) _only_ as a Proposed Standard (but waiting for two IPSec docs.) If future experience proves the IPCOMP Transform Identifiers range is too narrow, there is always room for improvements. Actually, it will be much, much harder to change this in the future if there are implementations which start assigning CPI's in the range 64-255. This will prevent us from expanding the range in the future for static transforms, since they will be used for dynamically assigned values. It's clear we will need to make a change to one or the other document, both of which have been voted on and approved by the IESG (the IPSEC documents modulo some fixups, including this one). One compromise position that we might explore would involve putting text in the IPSEC documents that reserve the range 64-255 for future expansion, and so implementations MUST NOT assign CPI's in that range. This at least gives us the opportunity to allow more "well-known" transforms in the future. What do people think about this? You're right that with only four compression algorithms, this isn't a big deal either way, and shouldn't be used to delay the documents. On the other hand, I can't think of any architectural justification to artificially constrain the ability to expand the number space at this point in time. It'd be like the original IP designers saying that IP addresses should be only 28 bits, instead 32, because surely we would *never* need 2**28 addresses --- never mind that 4 bytes gives you 32 bits and the cost is the same whether you use 28 or 32 bits. Taking the analogy back to IPPCP, if we have 1 full byte available to us, why not use the whole 8 bits, instead of stopping at 6? Surely we can spare 192 dynamically assigned CPI's out of over 61,000. (Note that the compromise I suggested above reserves these 192 dynamically assigned CPI's so that we have the option in the future to expand the range.) - Ted From owner-ipsec Fri Apr 24 15:03:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA21034 for ipsec-outgoing; Fri, 24 Apr 1998 15:02:09 -0400 (EDT) Message-Id: <3.0.2.32.19980424121326.006a0da8@pita.cisco.com> X-Sender: shacham@pita.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Fri, 24 Apr 1998 12:13:26 -0700 To: "Theodore Y. Ts'o" From: Avram Shacham Subject: Re: Last Call: IPSec DOI Proposed Standard Cc: "Theodore Y. Ts'o" , "'iesg@ns.ietf.org'", ipsec@tis.com, ippcp@external.cisco.com In-Reply-To: <199804241828.OAA17558@dcl.MIT.EDU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Ted, I agree that your compromise is more flexible for future changes. Unless other members of the IPPCP wg voice objections, I suggest that both documents (DOI and IPComp) will be modified to reflect your suggestion. Also, the DOI document should be modified to correct the non-accurate wording describing the IPComp protocol: (a) deleting the words "before ESP encryption" in section 4.4.5 and "before ESP" is 6.6, and (b) the term "IP compression" should be modified to "IP payload compression." I hope this process will not delay any of our documents. Comments? avram At 02:28 PM 4/24/98 -0400, Theodore Y. Ts'o wrote: > >Actually, it will be much, much harder to change this in the future if >there are implementations which start assigning CPI's in the range >64-255. This will prevent us from expanding the range in the future for >static transforms, since they will be used for dynamically assigned >values. > >It's clear we will need to make a change to one or the other document, >both of which have been voted on and approved by the IESG (the IPSEC >documents modulo some fixups, including this one). > >One compromise position that we might explore would involve putting text >in the IPSEC documents that reserve the range 64-255 for future >expansion, and so implementations MUST NOT assign CPI's in that range. >This at least gives us the opportunity to allow more "well-known" >transforms in the future. What do people think about this? > >You're right that with only four compression algorithms, this isn't a >big deal either way, and shouldn't be used to delay the documents. On >the other hand, I can't think of any architectural justification to >artificially constrain the ability to expand the number space at this >point in time. It'd be like the original IP designers saying that IP >addresses should be only 28 bits, instead 32, because surely we would >*never* need 2**28 addresses --- never mind that 4 bytes gives you 32 >bits and the cost is the same whether you use 28 or 32 bits. > >Taking the analogy back to IPPCP, if we have 1 full byte available to >us, why not use the whole 8 bits, instead of stopping at 6? Surely we >can spare 192 dynamically assigned CPI's out of over 61,000. (Note that >the compromise I suggested above reserves these 192 dynamically assigned >CPI's so that we have the option in the future to expand the range.) > > - Ted > > From owner-ipsec Fri Apr 24 15:41:57 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA21199 for ipsec-outgoing; Fri, 24 Apr 1998 15:40:09 -0400 (EDT) From: Ronald Lee Message-Id: <199804241955.PAA17684@itd.nrl.navy.mil> Subject: Re: IPsec 41st IEEE meeting To: amalmaal@nortel.ca (Amal Maalouf) Date: Fri, 24 Apr 1998 15:55:10 -0400 (EDT) Cc: ipsec@tis.com In-Reply-To: <199804220102.VAA03449@relay.rv.tis.com> from "Amal Maalouf" at Apr 21, 98 09:00:00 pm 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 Amal For US and Canadian citizens only NRL's BSD/OS and NetBSD software can be found at http://web.mit.edu/network/isakmp/ Ron From owner-ipsec Fri Apr 24 15:42:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA21251 for ipsec-outgoing; Fri, 24 Apr 1998 15:42:08 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF063394@exchange.timestep.com.219.168.192.in-addr.arpa> From: Roy Pereira To: ipsec@tis.com Subject: AggressiveMode issue Date: Fri, 24 Apr 1998 15:57:02 -0400 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 Not to delay the documents, but I have a question about Aggressive Mode; When the Initiator sends out the third phase 1 message, how does he know that the responder received it so that he can start the Quick Mode exchange? Initiator Responder --------- --------- MainMode: 1 HDR, SA, KE, Ni, IDii --> 2 <-- HDR, SA, KE, Nr, IDir, HASH_R 3 HDR, HASH_I --> QuickMode: 1 HDR*, HASH(1), SA, Ni --> 2 <-- HDR*, HASH(2), SA, Nr 3 HDR*, HASH(3) --> The problem is that the responder might not get MM3 or that he might get QM1 before he gets MM3. From owner-ipsec Fri Apr 24 16:30:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA21473 for ipsec-outgoing; Fri, 24 Apr 1998 16:28:09 -0400 (EDT) Message-Id: <3.0.32.19980424160740.00d1c35c@bl-mail1.corpeast.baynetworks.com> X-Sender: ndoraswa_pop@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 24 Apr 1998 16:07:40 -0400 To: "Theodore Y. Ts'o" , Avram Shacham From: Naganand Doraswamy Subject: Re: Last Call: IPSec DOI Proposed Standard Cc: "Theodore Y. Ts'o" , "'iesg@ns.ietf.org'", ipsec@tis.com, ippcp@external.cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Ted, I like the compromise you suggested of reserving values 64-255 for future use. I think we should change the documents to reflect this. Thanks, --Naganand ----------------------------------------------------------------- Naganand Doraswamy (978)916-1323 (O) Bay Architecture Lab (978)916-0620 (Fax) 3 Federal St, Mail Stop BL3-03 Billerica, MA 01821 From owner-ipsec Fri Apr 24 17:35:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA21965 for ipsec-outgoing; Fri, 24 Apr 1998 17:34:08 -0400 (EDT) Message-Id: <199804242148.OAA06667@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: wdm@epoch.ncsc.mil (W. Douglas Maughan) Cc: ipsec@tis.com Subject: Re: ISAKMP - Remaining Issues In-Reply-To: Your message of "Tue, 21 Apr 1998 07:36:45 EDT." <9804211136.AA09244@dolphin.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 Apr 1998 14:48:59 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Doug, One more issue. Currently ISAKMP reserves exchanges 6-31 for future ISAKMP use and 32-255 for DOI use. Would it be possible to reserve a few for private use among consenting parties? I see situations where an Informational Exchange containing a vendor id payload could be used as a probe to discover like- minded implementations and upon discovery engage in exchanges that aren't defined in a DOI or the base ISAKMP document. Similarly, vendor id payloads gratuitously added to Main Mode exchanges could allow both parties to recognize each other and use something other than or in addition to Quick Mode as a phase 2 exchange. How about leaving 128-255 for private use. That would provide a good chunk for this purpose and also allow for things like consenting parties agreeing that 0x03=Aggressive Mode while 0x83=Aggressive Mode with their particular extension. thanks, Dan. P.S. I'm not particular wed to the aforementioned scheme. If 128-255 brings out the ire of some then how about 240-255? Basically, any block of at least 16 values. From owner-ipsec Fri Apr 24 19:54:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA22688 for ipsec-outgoing; Fri, 24 Apr 1998 19:53:09 -0400 (EDT) Message-Id: <199804250006.RAA02551@gallium.network-alchemy.com> To: Daniel Harkins cc: wdm@epoch.ncsc.mil (W. Douglas Maughan), ipsec@tis.com Subject: Re: ISAKMP - Remaining Issues In-reply-to: Your message of "Fri, 24 Apr 1998 14:48:59 PDT." <199804242148.OAA06667@dharkins-ss20.cisco.com> Date: Fri, 24 Apr 1998 17:06:43 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk >P.S. I'm not particular wed to the aforementioned scheme. If >128-255 brings out the ire of some then how about 240-255? >Basically, any block of at least 16 values. Yeah, this makes a good deal of sense. I do think a double-digit range is closer to the correct number... Derrell From owner-ipsec Sun Apr 26 12:37:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA04390 for ipsec-outgoing; Sun, 26 Apr 1998 12:29:47 -0400 (EDT) Date: Sun, 26 Apr 98 16:29:23 GMT Daylight Time From: Ran Atkinson Subject: Re: ISAKMP - Remaining Issues To: "W. Douglas Maughan" , Daniel Harkins Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199804242148.OAA06667@dharkins-ss20.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan and Doug, I like Dan's suggestion of reserving a few for "Private Use amongst consenting parties" (or whatever the correct verbage is). However, I'd really rather NOT reserve half of the total range for that purpose. How about reserving 240-255 for that use (conforming with Dan's pre-suggested compromise position) ?? Ran From owner-ipsec Sun Apr 26 20:05:12 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA06626 for ipsec-outgoing; Sun, 26 Apr 1998 20:02:56 -0400 (EDT) Message-Id: <199804190618.CAA01601@morden.sandelman.ottawa.on.ca> To: tcp-impl@cthulhu.engr.sgi.com CC: ipsec@tis.com Subject: Re: TCPIMPL: Minutes from LA Meeting In-reply-to: Your message of "Wed, 15 Apr 1998 12:47:55 EDT." <199804151647.MAA22744@guns.lerc.nasa.gov> Date: Sun, 19 Apr 1998 02:18:51 -0400 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Mark" == Mark Allman writes: Mark> question. He further noted that MTU discovery should be Mark> done without ICMP due to security concerns (and, noted that Mark> this might fall under ``security problems'' rather than Mark> ``serious problems''). Matt [Mathis] suggested that we note the Mark> problem and state that we do not yet know how to solve it. Mark> Ran Atkinson suggested that MTU discovery is not a security Mark> problem as a host must be continuously jammed with ``too Mark> small'' ICMP messages for an attack to be successful. Matt I will make a couple of comments about this. I do not wish to refute Ran's claim --- it is entirely correct. The question is what is the impact of it? Assume a TCP connection that traverses a network, and is carried with IPsec (perhaps just AH) in "transport" mode. If there is some reason to believe that AH (or ESP) is on that network path, then I would suggest that is sufficient worry about attacks or flooding with ICMP. IPsec AH around a TCP makes a lot of sense: it eliminates practically all the TCP based attacks, and converts the SYN flooding problem to an ISAKMP SA flooding problem. ISAKMP was designed from the beginning to deal with this. Except for ICMP packets. "port unreachable" would originate from the destination host, which could conceivably transit with IPsec protection, but all other useful ICMP packets relevant to TCP originate from intermediate hosts/routers: - dest unreachable (Frag Needed is the one for PMTU, but the others are also very important) - source quench (I'm told that few this is seldom used at present) - redirect (really an IP level info, but it affects TCP) - time exceeded (I think that TCP doesn't do anything with this) [are there others I've missed?] What can a "secured" TCP connection ignore, and with what effect? 1. unreach/net unreach unreach/host unreach unreach/prot unreach unreach/port unreach If we ignore these, then we retransmit a lot, and finally, after a long time, we give up. If this is the SYN packet, then no data flows. If this is after the SYN packet (a node goes down), then the connection just hangs, eventually timing out and exiting. If the node comes back up again (without its IPSEC SA's), then the corresponding node will get an ISAKMP "Initial Contact" message from the node that rebooted when the corresponding node sends another packet. One hopes eventually ISAKMP will be smart enough not to create a new IPsec SA, so that the two nodes can send enough TCP RSTs! 2. source quench If we ignore these, then we may get very poor performance when the router queues fill up. However, there are better, in-protocol ways to detect congestion and deal with it. Case closed IMHO. 3. redirect This is not exclusively a TCP issue, but an IP one. In general, they can't be trusted, so we have to ignore them. This means that packets are not routed as efficiently as they might. Are there other repercussions of ignoring them? 4. unreach/need fragment If we ignore this one, and we are setting the DF bit, we get no service. This is serious. If we disable PMTU for IPsec protected TCP sessions, then, with IPv4, we simply get inefficient TCP. On very lossy links, however, that may result in no useful throughput. (And I suspect that these kinds of links may become more and more common) On IPv6, we get no service, since DF is implicitely set. [I should note that there are some heuristics that might be used that are equivalent to "ignore ICMP", but do gain some information from it.] I wrote a draft on how to do PMTU with ICMPs from the *receiving* node. It should work with IPv4 easily. I have some ideas, and have read some other ideas on how to adapt this for IPv6. (The problem is essentially equivalent to the MTU Black Hole problem). I would therefore like to second Matt's suggestion. I would further ask the question: does IPsec make all third party ICMP's obsolete? Does IPv6 add useful new ones? Or problematic new ones? ] Network Security Consulting and Contract Programming | SSH IPsec [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |international[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ - -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQBVAwUBNTmWAB4XQavxnHg9AQGcsgH9GEaoYQ4ZcpwcSPs+8cCXogCTAUTo14ay 6UFYPCGYKlAxFO9I+OGxGlCAN/siZn5NKadYfa4lF8FYaLH5nBBniA== =u4q0 - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQBVAwUBNTmXRB4XQavxnHg9AQFCJgH/VA/yHMQ6iZEH8V2eccUlsNtPr3vXmSEE QPAfY4h42XuM9YkPcEIVk/81qjBCqCW0S+kQzPWVob15MSZk6aEZWQ== =kTaO -----END PGP SIGNATURE----- From owner-ipsec Sun Apr 26 20:45:22 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA06927 for ipsec-outgoing; Sun, 26 Apr 1998 20:44:50 -0400 (EDT) Message-Id: <199804270059.UAA02775@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com, tcp-impl@cthulhu.engr.sgi.com Subject: ICMP and TCP In-reply-to: Your message of "Sun, 19 Apr 1998 02:18:51 EDT." <199804190618.CAA01601@morden.sandelman.ottawa.on.ca> Date: Sun, 26 Apr 1998 20:59:18 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Michael" == Michael Richardson missed some words, confusing his meaning: Michael> Assume a TCP connection that traverses a network, and is carried Michael> with IPsec (perhaps just AH) in "transport" mode. If there is Michael> some reason to believe that AH (or ESP) is on that network path, ...if there is some reason to believe that AH/ESP is needed on that network path, that is if you believe that there may be an eavesdropper or active TCP spoofer, then I would suggest that there is sufficient additional reason to worry that they will simply destructive shut you down with ICMP, or perhaps even just ICMP ping floods :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON Michael Richardson | SSH IPsec: http://www.ssh.fi/. Secure, strong, international Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. From owner-ipsec Sun Apr 26 22:40:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA07548 for ipsec-outgoing; Sun, 26 Apr 1998 22:39:50 -0400 (EDT) Date: Sun, 26 Apr 1998 22:54:02 -0400 Message-Id: <199804270254.WAA18334@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: minutes@ietf.org Cc: ipsec@tis.com Subject: IPSEC meeting minutes Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Enclosed please find the minutes for the IPSEC wg meeting in LA. There are also the following slide submissions which should be included in the minutes. The URL's follow below: http://web.mit.edu/tytso/www/ipsec/los_angeles/agenda.ps http://web.mit.edu/tytso/www/ipsec/los_angeles/ji.ps http://web.mit.edu/tytso/www/ipsec/los_angeles/canetti.ps (An HTTP version of the minutes can also be found at http://web.mit.edu/tytso/www/ipsec/los_angeles/index.html) - Ted Los Angeles IETF (March/April 1998) Working Group Meeting Minutes The IPSEC working group met on Thursday, April 2nd, 1998, at the IETF meeting in Los Angeles, California. The Agenda was as follows: * Agenda Bashing * Final Document Edits * Whither AH? * Free IPSEC Implementation survey * Raleigh interoperability issues * CA Interoperability issues * IPsec Web-based Interoperability Tool * IPSec configuration (isakmp-cfg) * Smart card/RADIUS support in ISAKMP * IPSec policy modeling * Elliptic Curve Cryptography in IPSec * Secure Multicast Issues Final Document Edits ==================== Ted Ts'o asked the IPSEC document editors who had any final editorial changes to submit them ASAP. Whither AH? =========== Bob Moskowitz presented the question of "Whither AH?". There are a some folks who would like AH to be optional; others want to keep it. There are some technical issues with AH --- the fact that the checksum is at the beginning of the AH packet makes it hard to do AH in hardware. However, there is a real requirement for the AH mechanism for IPv6. Making AH a "should" for IPv4 and a "must" for IPv6 doesn't seem to work, since the same problems with IPV4 will be faced for IPv6. Peter Ford from Microsoft commented that the useful functionality of AH has been moved to ESP. He recommended that AH to be dropped entirely, but willing to live with a "should". Steve Bellovin noted that he had recommended removing AH 3 years ago in Stockholm. After much discussion, the working group decided to keep it. He saw no reason to re-open the discussion. Steve Kent made the following comments: ESP is fine as it is, and ESP can be used in an authentication mode with null encryption. However, there is a legitimate functionality that AH supports. Others noted that everyone in the Raleigh interoperability testing was doing AH, and we should just do it. There was a concern expressed that if we didn't get rid of it now, it would never go away. Also, that IPSEC was too complex and anything to reduce complexity would be a good thing. On the other hand, AH is a very small part of a complete IPSEC implementation, and it doesn't cost much to test. It was noted that the IPV6 router renumbering relies on AH. Peter Ford said that it was Microsoft's desire to ship a product that is 100% IETF compliant. The implementations will be much simpler and drive it to the smallest possible set of features. If AH is a "should", will Microsoft support it? Microsoft not willing to make that statement at this point. Jeff Schiller pointed out that there was a difference between "SHOULD" and "MAY", and that although folks were talking about changing AH to be a "SHOULD", their arguments and statements indicated that they were treating it as a "MAY". Jeff Schiller, as Area Director, took the floor. He pointed out that were at the proposed standard stage, the first step in the standardization process. Normally this doesn't even require working implementations, which we already have here. At the proposed standard status, whether something is a "SHOULD" or "MUST" it not that important; we can change it either way later. However, what we cannot do is NOT move forward at all. Jeff proposed compromise of making AH a "SHOULD" but that vendors would be put on notice that we might change this in the future. Vendors would be warned that this "SHOULD" would be a real "SHOULD" that they should really implement, and not just a "MAY". As we go to draft standard, this might become a "MUST". Jeff took a straw poll to determine if people wanted to make such a change, or to leave the document alone and keep AH a "MUST". Jeff declared a clear consensus to keep AH mandatory. Free IPSEC Implementation survey ================================ John Ioannidis from AT&T was interested in doing a survey of "free" IPSEC implementations. He asked those with free implementations of IPsec code to send him e-mail to: ji@research.att.com with the subject line "FREE IPSEC". He would summarize the responses to the ipsec mailing list. Raleigh interoperability issues =============================== Roy Pereira from TimeStep presented a list of issues that were found at the Raleigh interoperability workshop. This list included: 1. ISAKMP SPI Sizes Some implementations got upset (i.e. crash) when offered different sizes of SPIs eg. 2 octets was required for IP Compression. 2. Correctly Ordered Payloads For some vendors, ISAKMP payloads had to be in the order that they are documented. Most ISAKMP payloads may be sent in any order (except for the SA, Proposal and Transform payloads) 3. IP Addresses in Certificates Some people expected strings, other expected 4 octets in ipAddress "It is never a string when encoded in subjectAltName" "... consensus was that if IP Addresses (or dns name or rfc822 name) were going to be added to an X.509 certificate then they should go into the subjectAltName extension (that is after all what it is for). This is consistent with work done in the PKIX WG" 4. No IP Address in Certificate An IP Address does not have to be within the certificate if the IPSec entity is mobile and uses a dynamic address. But, there must be some other type of identity within the certificate (rfc822name, domain name, X.500 DN) 5. Replay of Zero Some implementations were sending a replay prevention value of 0 when doing manually keying. In the discussion which followed, Steve Kent noted that this was incorrect behavior, since the replay prevention field must be incremented. 6. AH & Auth Attribute Some vendors were not sending both the AH Transform type (e.g. AH_MD5) and the Authentication Algorithm attribute (e.g. HMAC-MD5) Some vendors would not accept receiving both the Transform type and the Authentication Algorithm attribute 7. New CertReq Format Some vendors were using the old isakmp-08 certificate request format 8. Hash in RSA Encryption Some vendors did not like getting a key hash payload in rsa encryption mode 9. Unknown Notify Payloads Some vendors were discarding entire ISAKMP packet when an unknown notify payload was received (ie. INITIAL-CONTACT). Only the single Notify payload should be discarded 10. Handling CertReq Some vendors did not like receiving certificate request payloads when using pre-shared keys The isakmp draft says certificate requests payloads can exist in any message Some vendors did not like receiving certificate request payloads at any time 11. Packet Padding Some vendors did not like ISAKMP packets to be padded to a multiple of 4 byte. The ISAKMP draft states that the ISAKMP message MUST be 4-octet aligned. 12. IDui & Idur Some vendors expected to see client ID's in phase 2 (QuickMode), even though they are optional This caused QuickMode to complete, but fail to setup the correct SAs 13. IP4_ADDR_RANGE Some vendors do not accept a QuickMode ID type of IP4_ADDR_RANGE while they do accept IP4_ADDR and IP4_ADDR_SUBNET 14. Nonce Sizes Some vendors could not handle larger sized nonces (40 bytes) and would only allow 20 byte nonces The new IKE document does state: "The length of nonce payload MUST be between 8 and 256 bytes inclusive." 15. Overlapping SAs Some vendors did not support having a SA with the whole subnet at the same time as another SA with one host in that subnet 16. CONNECT Notify Message Due to QuickMode's 1.5 exchanges, the initiator might not know that the responder did not receive the 3rd message One vendor suggested we should send a Notify CONNECT message for the responder's 2nd quickmode message When this item was discussed, it was noted that this was not necessary because of the COMMIT bit in the ISAKMP header. CA Interoperability issues ========================== Rodney Thayer gave a presentation of the requirements which IPSEC places on a Public Key Infrastructure. (This presentation was also given at the PKIX working group.) Rodney has written a draft document which is currently available at: ftp://module-one.tillerman.nu/pub/draft-thayer-ipsec-pki-00.txt After Rodney finished his presentation, a developer from Microsoft noted that there were speed/performance problems with the certificate verifications; the time needed to do the certificate processing was causing TCP SYN's to get queued up and be dropped. Discussion followed, with participants noting that IPSEC implementors need to collect timing requirements and give that experience to the PKIX people. A volunteer is needed to collect this information. IPsec Web-based Interoperability Tool ===================================== Rob Glen presented a web-based interoperability testing tool developed by NIST to test the IPSEC protocols. The URL for this service is: http://IPsec-wit.antd.nist.gov/ The testing tool is semi-automated, and driven using WWW forms. There are currently 70 test cases covering AH and ESP using IPV4, and there are plans to expand the service to include test cases for IKE, PKIX, and IPv6. The tool is based on the NIST Cerberos IPsec implementation. The source code to the testing tool is available for those who would like to port the tool to be based on other IPSEC implementations. In the discussion that followed it was noted that SSH Communications Security has a web-based service to test IKE (nee ISAKMP/Oakley) implementations. This was announced at the last IETF meeting. The URL for this testing site is: http://isakmp-test.ssh.fi IPSec configuration (isakmp-cfg) ================================ Roy Pereira from Timestep presented a proposal for doing configuration under ISAKMP. This proposal was conceieved to request an internal IP address from a security gateway in a secure fashion. (Since this needs to happen before the IKE negotiation is completed, it is not possible to use protocols such as Radius or DHCP.) Instead, it uses ISAKMP for management and tranport. There is currently a draft proposal available: draft-ietf-ipsec-isakmp-mode-cfg-02.txt. This work is currently not part of the working group charter, but this is an important work item to consider for the new working group charter for futher work for this working group. During the discussion, there was a question raised of how this would impact Mobile IP, especially in light of RFC-2002. One person thought that this might be orthagonal, but more investigation into this issue is necessary. Smart card/RADIUS support in ISAKMP =================================== Roy Periera also discussed his proposal to extend IKE to accept the use of extended authentication techniques such as time-variant smart cards, two factor authentication, challenge/response and other user-based authentication schemes. An initial draft of his work is available at: draft-ietf-ipsec-isakmp-xauth-01.txt. During the discussion, the working group asked Roy why this was done inside IKE; the answer was so that it could be done securely. One person suggested that Roy look at EAP. Roy noted that more discussion was needed for his proposal, which was still in the early design phase. IPSec policy modeling ===================== Finally, Roy presented a proposed IPsec Policy Data Model. The goal is to provide implementers sufficient information on the base IPsec negotiation mechanism so that they can create a correct enterprise policy architecture. There is an initial Internet Draft describing this model: draft-ietf-ipsec-policy-model-00.txt. Elliptic Curve Cryptography in IPSec ==================================== Paul Lambert from Certicom gave a presentation of Elliptical Curve (EC) cryptography. EC systems are much faster, and so are popular in implementations driven by constrained devices (e.g., Windows CE, pagers, etc.) Certicom's web site has tutorials on the technology. Certicom has suggested that IPSEC use "better curves" based on prime fields. Discussion centered over two main issues. The first are the IPR/patent issues in the EC space, of which there are many. Certicom has a large number of patents optimizing EC cryptography. Not all patents have been issued yet, so Certicom can not disclose all of them. It was suggested that Certicom put together an internet draft that discusses or describes what portions are available for public use. More discussion also centered around the optimizations which can be applied to EC. Some optimizations only apply to hardware implementations. The current curves proposed in the Oakley draft are not prime fields and have software speedups which do not apply if the fields used are prime fields, as Certicom proposes. (There are hardware optimizations, which may be patented by Certicom, which do apply to prime fields, however.) Furthermore, there is disagreement amongst mathematicians as to whether whether prime fields are more secure than non-prime fields. Ted Ts'o observed than when comparing the speed of EC's, it is important to consider both software and hardware implementations, as well as comparing the speed with and without the use of patented optimization techniques. Secure Multicast Issues ======================= Ron Cannetti from IBM research gave a presentation sketching the scope of the Secure Multicast problem. Different applications may have very different group characteristics, security requirements, performance requirements, etc. Ran ended with a survey of existing solutions with differing properties. Bob Moskowitz observed that the working group will have to decide on a specific scope before we will be able to profitably tackle the secure multicast as a tractable problem. Ideally, some customers would ask the IETF to solve a specific problem. From owner-ipsec Mon Apr 27 10:57:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA12273 for ipsec-outgoing; Mon, 27 Apr 1998 10:53:51 -0400 (EDT) Date: Mon, 27 Apr 1998 18:08:45 +0300 (EET DST) Message-Id: <199804271508.SAA01396@pilari.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Roy Pereira Cc: ipsec@tis.com Subject: AggressiveMode issue In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDF063394@exchange.timestep.com.219.168.192.in-addr.arpa> References: <319A1C5F94C8D11192DE00805FBBADDF063394@exchange.timestep.com.219.168.192.in-addr.arpa> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 8 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Roy Pereira writes: > Not to delay the documents, but I have a question about Aggressive Mode; > > When the Initiator sends out the third phase 1 message, how does he know > that the responder received it so that he can start the Quick Mode > exchange? > > Initiator Responder > --------- --------- > > MainMode: ^^^^^^^^ I assume this should be aggressive mode... > 1 HDR, SA, KE, Ni, IDii --> > 2 <-- HDR, SA, KE, Nr, IDir, HASH_R > 3 HDR, HASH_I --> > > QuickMode: > 1 HDR*, HASH(1), SA, Ni --> > 2 <-- HDR*, HASH(2), SA, Nr > 3 HDR*, HASH(3) --> > > The problem is that the responder might not get MM3 or that he might get > QM1 before he gets MM3. If the AG3 is lost and the initiator starts quick mode immediately, the responder will just silently drop the first quick mode packet. After some time the responder notices that it hasn't received the last aggressive mode packet and retrasmits its seconds packet (AG2), and when the initiator receives that it retrasmits its final packet (AG3). The initiator also keeps retrasmitting the QM1 packet until the responder replies. So the exchange is like this: Initiator Responder --------- --------- AG1 HDR, SA, KE, Ni, IDii --> AG2 <-- HDR, SA, KE, Nr, IDir, HASH_R AG3 HDR, HASH_I -->| (this packet is lost) QM1 HDR*, HASH(1), SA, Ni --> (responder drops this) (responder times out and retrasmits) AG2b <-- HDR, SA, KE, Nr, IDir, HASH_R (Initiator notices retransmit and retransmits its last packet AG3b HDR, HASH_I --> (aggressive mode done, phase I done). (Initiators quick mode times out and it retransmits the packet) QM1b HDR*, HASH(1), SA, Ni --> QM2 <-- HDR*, HASH(2), SA, Nr QM3 HDR*, HASH(3) --> (quick mode exchange done, phase II done). -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communication Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec Mon Apr 27 13:49:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA13574 for ipsec-outgoing; Mon, 27 Apr 1998 13:41:57 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF063636@exchange.timestep.com.219.168.192.in-addr.arpa> From: Roy Pereira To: Tero Kivinen Cc: ipsec@tis.com Subject: RE: AggressiveMode issue Date: Mon, 27 Apr 1998 13:43:00 -0400 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 The problem with this approach is that an implementation would have to hold every ISAKMP message sent in a retransmission buffer. That is quite costly for a security gateway handling thousands of connections. Perhaps a better way is to use the COMMIT bit to require a NOTIFY-CONNECT message to be sent the the responder, then proceeding with the QuickMode exchange? > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@ssh.fi] > Sent: Monday, April 27, 1998 11:09 AM > To: Roy Pereira > Cc: ipsec@tis.com > Subject: AggressiveMode issue > > > Roy Pereira writes: > > Not to delay the documents, but I have a question about > Aggressive Mode; > > > > When the Initiator sends out the third phase 1 message, how > does he know > > that the responder received it so that he can start the Quick Mode > > exchange? > > > > Initiator Responder > > --------- --------- > > > > MainMode: > ^^^^^^^^ > I assume this should be aggressive mode... > > > 1 HDR, SA, KE, Ni, IDii --> > > 2 <-- HDR, SA, KE, Nr, IDir, HASH_R > > 3 HDR, HASH_I --> > > > > QuickMode: > > 1 HDR*, HASH(1), SA, Ni --> > > 2 <-- HDR*, HASH(2), SA, Nr > > 3 HDR*, HASH(3) --> > > > > The problem is that the responder might not get MM3 or that > he might get > > QM1 before he gets MM3. > > If the AG3 is lost and the initiator starts quick mode immediately, > the responder will just silently drop the first quick mode packet. > After some time the responder notices that it hasn't received the last > aggressive mode packet and retrasmits its seconds packet (AG2), and > when the initiator receives that it retrasmits its final packet (AG3). > > The initiator also keeps retrasmitting the QM1 packet until the > responder replies. > > So the exchange is like this: > > Initiator Responder > --------- --------- > AG1 HDR, SA, KE, Ni, IDii --> > AG2 <-- HDR, SA, KE, Nr, IDir, HASH_R > AG3 HDR, HASH_I -->| (this packet is lost) > > QM1 HDR*, HASH(1), SA, Ni --> (responder drops this) > > (responder times out and retrasmits) > AG2b <-- HDR, SA, KE, Nr, IDir, HASH_R > > (Initiator notices retransmit and retransmits its last packet > > AG3b HDR, HASH_I --> > (aggressive mode done, > phase I done). > > (Initiators quick mode times out and it retransmits the packet) > QM1b HDR*, HASH(1), SA, Ni --> > QM2 <-- HDR*, HASH(2), SA, Nr > QM3 HDR*, HASH(3) --> > > (quick mode exchange done, phase II done). > -- > kivinen@iki.fi Work : +358-9-4354 3218 > SSH Communication Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > From owner-ipsec Mon Apr 27 15:14:12 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA14210 for ipsec-outgoing; Mon, 27 Apr 1998 15:10:58 -0400 (EDT) Date: Mon, 27 Apr 1998 22:24:55 +0300 (EET DST) Message-Id: <199804271924.WAA08821@pilari.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Roy Pereira Cc: ipsec@tis.com Subject: RE: AggressiveMode issue In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDF063636@exchange.timestep.com.219.168.192.in-addr.arpa> References: <319A1C5F94C8D11192DE00805FBBADDF063636@exchange.timestep.com.219.168.192.in-addr.arpa> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 31 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Roy Pereira writes: > The problem with this approach is that an implementation would have to > hold every ISAKMP message sent in a retransmission buffer. That is > quite costly for a security gateway handling thousands of connections. You have to store the last packet you sent out, not all packets in the exchange. Note that quick mode if different exchange so its packets are not part of the main mode exchange and they must not overwrite the last sent main mode packet. The last packet of the exchange (both main mode and aggressive mode) must be stored for (retransmit timer * retransmit count) seconds (so if you have 2 second retransmit timer and 3 retransmits you have to keep information needed for retransmission for 6 seconds). This last packet of the exchange needs only be kept in that end that is sending the final packet. For example the responder of the main mode must keep the last packet sent to initiator for that time, or until it receives first packet using already created isakmp sa. > Perhaps a better way is to use the COMMIT bit to require a > NOTIFY-CONNECT message to be sent the the responder, then proceeding > with the QuickMode exchange? That would help for the last packet of the aggressive mode for the initiator, but it doesn't help any other cases, so you still must be able to retransmit also that notify connect packet. Lets take an example to calculate the cost of storing last sent packet: - gateway server with hardware acceleator that can do 10 * 10 diffie-hellmans / second (100 milliseconds / diffie-hellman, 10 paralleal units). - PC-client that takes about 500 milliseconds / diffie-hellman (group 1). - round trip time 300 milliseconds. Minimum time main mode exchange takes 100 ms + 6 * 300 ms + 500 ms = 2400 ms. The retransmit timer must be more than 500 ms + 300 ms, because otherwise the PC cannot reply fast enough, so lets say it is 3 seconds (say we can have very slow clients too). Lets assume the maximum number of retransmits is 5. The server can start 100 new negotiation / second. The maximum retransmit time is 3 * 5 seconds = 15 seconds. So you have to store the last packet of the (2.4 + 15 * 100) = 1740 negotiation. Lets say you allocate 1 kB packet for that (the packet containing the certificate might take about 1 kB, so we are really assuming worst case). This means your server must allocate 1.8 MB of memory for those retransmit buffers. If you add in the scenario that 10% of all packets is dropped you get the average negotiation time for about 5 seconds, so the memory requirements goes from 1.8 MB to 2.0 MB. That is not much, if you keep in mind that, that server is able to handle 360 000 clients having 1 hour rekey time, or 2 880 000 clients having 8 hour rekey time. If your clients are using blowfish your server must be able to store 1430 MB of key schedule information (each blowfish key schedule context is about 4 kB). I think storing the last sent packet for each ongoing exchange is not too expensive. Of course you want to store also the last received packet so you immediately notice when the other end retransmits and send your previous packet back. So that doubles the memory requirements. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec Mon Apr 27 15:32:48 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA14329 for ipsec-outgoing; Mon, 27 Apr 1998 15:30:58 -0400 (EDT) From: pau@watson.ibm.com Date: Mon, 27 Apr 1998 15:42:05 -0400 Message-Id: <9804271942.AA22562@secpwr.watson.ibm.com> To: kivinen@ssh.fi, rpereira@TimeStep.com Subject: RE: AggressiveMode issue Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: t/hK921P5dU7/ZsAeAUUZg== Sender: owner-ipsec@ex.tis.com Precedence: bulk But the "NOTIFY-CONNECT message" may be lost on the way as well. I think the last msg in an aggressive mode has to be kept for retransmission, at least kep for a while. > From owner-ipsec@portal.ex.tis.com Mon Apr 27 15:26:36 1998 > Message-Id: <319A1C5F94C8D11192DE00805FBBADDF063636@exchange.timestep.com.219.168.192.in-addr.arpa> > From: Roy Pereira > To: Tero Kivinen > Cc: ipsec@tis.com > Subject: RE: AggressiveMode issue > Date: Mon, 27 Apr 1998 13:43:00 -0400 > 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 > Content-Length: 2770 > Status: RO > > The problem with this approach is that an implementation would have to > hold every ISAKMP message sent in a retransmission buffer. That is > quite costly for a security gateway handling thousands of connections. > > Perhaps a better way is to use the COMMIT bit to require a > NOTIFY-CONNECT message to be sent the the responder, then proceeding > with the QuickMode exchange? > > > > -----Original Message----- > > From: Tero Kivinen [mailto:kivinen@ssh.fi] > > Sent: Monday, April 27, 1998 11:09 AM > > To: Roy Pereira > > Cc: ipsec@tis.com > > Subject: AggressiveMode issue > > > > > > Roy Pereira writes: > > > Not to delay the documents, but I have a question about > > Aggressive Mode; > > > > > > When the Initiator sends out the third phase 1 message, how > > does he know > > > that the responder received it so that he can start the Quick Mode > > > exchange? > > > > > > Initiator Responder > > > --------- --------- > > > > > > MainMode: > > ^^^^^^^^ > > I assume this should be aggressive mode... > > > > > 1 HDR, SA, KE, Ni, IDii --> > > > 2 <-- HDR, SA, KE, Nr, IDir, HASH_R > > > 3 HDR, HASH_I --> > > > > > > QuickMode: > > > 1 HDR*, HASH(1), SA, Ni --> > > > 2 <-- HDR*, HASH(2), SA, Nr > > > 3 HDR*, HASH(3) --> > > > > > > The problem is that the responder might not get MM3 or that > > he might get > > > QM1 before he gets MM3. > > > > If the AG3 is lost and the initiator starts quick mode immediately, > > the responder will just silently drop the first quick mode packet. > > After some time the responder notices that it hasn't received the last > > aggressive mode packet and retrasmits its seconds packet (AG2), and > > when the initiator receives that it retrasmits its final packet (AG3). > > > > The initiator also keeps retrasmitting the QM1 packet until the > > responder replies. > > > > So the exchange is like this: > > > > Initiator Responder > > --------- --------- > > AG1 HDR, SA, KE, Ni, IDii --> > > AG2 <-- HDR, SA, KE, Nr, IDir, HASH_R > > AG3 HDR, HASH_I -->| (this packet is lost) > > > > QM1 HDR*, HASH(1), SA, Ni --> (responder drops this) > > > > (responder times out and retrasmits) > > AG2b <-- HDR, SA, KE, Nr, IDir, HASH_R > > > > (Initiator notices retransmit and retransmits its last packet > > > > AG3b HDR, HASH_I --> > > (aggressive mode done, > > phase I done). > > > > (Initiators quick mode times out and it retransmits the packet) > > QM1b HDR*, HASH(1), SA, Ni --> > > QM2 <-- HDR*, HASH(2), SA, Nr > > QM3 HDR*, HASH(3) --> > > > > (quick mode exchange done, phase II done). > > -- > > kivinen@iki.fi Work : +358-9-4354 3218 > > SSH Communication Security http://www.ssh.fi/ > > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > > > From owner-ipsec Tue Apr 28 07:15:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA19746 for ipsec-outgoing; Tue, 28 Apr 1998 07:11:59 -0400 (EDT) Message-Id: From: alan@lxorguk.ukuu.org.uk (Alan Cox) Subject: Re: TCPIMPL: Minutes from LA Meeting To: mcr@sandelman.ottawa.on.ca (Michael Richardson) Date: Mon, 27 Apr 1998 11:18:43 +0100 (BST) Cc: tcp-impl@cthulhu.engr.sgi.com, ipsec@tis.com In-Reply-To: <199804190618.CAA01601@morden.sandelman.ottawa.on.ca> from "Michael Richardson" at Apr 19, 98 02:18:51 am Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > I will make a couple of comments about this. > I do not wish to refute Ran's claim --- it is entirely correct. The > question is what is the impact of it? It knocks the link speed right down. I disagree with Ran btw, if you are lucky enough to be the man in the middle or on the same host as one end you hardly need any packets to cripple a link. Its only useful against long streaming connections but it'll take someones newsfeed down to crawl level > Except for ICMP packets. "port unreachable" would originate from the > destination host, which could conceivably transit with IPsec > protection, but all other useful ICMP packets relevant to TCP originate > from intermediate hosts/routers: Some firewalls send port unreachable messages because the newer administrative messages are not understood by enough people > are not routed as efficiently as they might. Are there other > repercussions of ignoring them? The packet may not arrive at all is the other repercussion. IMHO its unlikely and its preferable to attack exposure. Alan From owner-ipsec Tue Apr 28 09:51:31 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA20914 for ipsec-outgoing; Tue, 28 Apr 1998 09:50:01 -0400 (EDT) Message-ID: <35460C8D.22A4@phase2net.com> Date: Tue, 28 Apr 1998 10:06:22 -0700 From: Jeff Pickering Reply-To: jpickering@phase2net.com Organization: phase2 networks X-Mailer: Mozilla 3.01 (Win16; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: isakmp multiple SA payloads Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Section 5.5 of IKE gives an example of 2 SA payloads in the same QM exchange. My question is how the payloads are logically related if at all. For example can you accept one payload and reject the other? jeff From owner-ipsec Thu Apr 30 01:12:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA01697 for ipsec-outgoing; Thu, 30 Apr 1998 01:03:01 -0400 (EDT) Date: Thu, 30 Apr 1998 01:17:32 -0400 Message-Id: <199804300517.BAA20034@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Thomas Narten , jis@MIT.EDU Cc: ipsec@tis.com Subject: [Karen Seo: Thomas Narten -- clarification, etc.] Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Thomas, I spent quite a bit of time discussing the issue which you raised (forwarded to me by Jeff) with Karen Seo and Charlie Lynn. They believe that IPSEC architecture draft as it currently stands is consistent with the current IPV6 drafts. As it currently stands, because of how the IPV6 documents are written, the bit in the option defines whether or not the option contents is mutable, regardless of whether not the receive can predict it. As a result, the IPSEC implementation must zero all IPV6 options with the mutable bit set, regardless of whether or not the receiver can predict it. This was done so that we would be consistent with the current IPV6 specifications. Karen and Charlie point out that if the IPV6 draft were changed so that the meaning of that bit means "mutable or receiver can predict", then it would be possible to include such options in the Integrity Check Value (ICV). However, I note that if we do this, and later someone defines a new mutable-but-predictable option, IPSEC implementations which don't know about the new option won't know how to predict option value, and thus will not be able to properly calculate the ICV. It is therefore simpler to say that all mutable options are not covered by the ICV, which is the current position of the IPV6 and IPSEC documents. The tradeoff then is that existing mutable-but-predictable options will not be integrity-protected. If we would like to change this, we would need to tweak both documents. However, the introduction of a new mutable-but-predictable option will cause interoperability problems with older security gateways, so it's not clear that we will be able to introduce new mutable-but-predictable options in the future in a practical fashion anyway. Given this, do you have a strong opinion regarding change both drafts, or leaving them as they currently stand? My recommendation would be to leave them as they currently stand, on the grounds of simplifying the implementations. - Ted ------- Forwarded Message Date: Tue, 28 Apr 98 20:36:53 EDT From: Karen Seo To: tytso@MIT.EDU Cc: skent@BBN.COM, clynn@BBN.COM, kseo@BBN.COM Subject: Thomas Narten -- clarification, etc. Hi Ted, My apologies for not getting back to you yesterday. Per our conversation earlier today, here's our interpretation and comments on Thomas's message. Thanks again for your hard work and help with these documents. Please let us know if you have further questions, Karen >>Date: Fri, 24 Apr 1998 11:02:17 -0400 >>From: Thomas Narten >> >>Bob, Steve: >> >>In reviewing draft-ietf-ipsec-auth-header-05.txt, I noticed the >>following wording: >> >>> As a new extension header or IPv4 option is created, it will be >>> defined in its own RFC and SHOULD include (in the Security >>> Considerations section) directions for how it should be handled when >>> calculating the AH ICV. If the IPsec implementation encounters an >>> extension header that it does not recognize, it MUST zero the whole >>> header except for the Next Header and Hdr Ext Len fields. The length >>> of the extension header MUST be computed by 8 * Hdr Ext Len value + >>> 8. If the IPsec implementation encounters an IPv4 option that it >>> does not recognize, it should zero the whole option, using the second >>> byte of the option as the length. (IPv6 options contain a flag >>> indicating mutability, which determines appropriate processing for >>> such options.) >> >>Text regarding processing of unrecognized extension options seems >>wrong (there are bits in header saying whether field is mutable). Do >>you agree? As background... A. There are 3 cases of new IP extension headers and options: 1. new IPv4 options 2. new IPv6 extension headers (e.g., Routing (Type 0), Fragmentation, etc.) 3. new options in existing IPv6 extension headers, i.e., Hop-by-Hop, and Destination B. For case (3), a variable number of options are carried in the extension header with individual option headers which have a bit which indicates mutability/immutability (the Option Data field mentioned later in Thomas's message.) * We're not sure what Thomas is saying with regard to "unrecognized extension options". The bit for mutability/immutability is in the individual Option Header(s) not the Extension Header. Perhaps he's confusing Options with Extension Headers. C. An extension header has its own IP protocol number (e.g., AH = 51, ESP = 50) and fields like Next Header, etc. Although most folks think of them as strictly an IPv6 concept, they can in principle be used with IPv4 or IPv6. The first sentence is addressing cases 1 and 2 -- we didn't specify the "new extension header" as being "IPv6" because of point C above. The parenthetical statement at the end is addressing case 3. There isn't anything wrong with the text. We could add various clarifications if it would help. >>>>Also, in looking at the current IPv6 base document, it says on this >>>>point: >>>> >>> The third-highest-order bit of the Option Type specifies whether or >>> not the Option Data of that option can change en-route to the >>> packet's final destination. When an Authentication header is present >>> in the packet, for any option whose data may change en-route, its >>> entire Option Data field must be treated as zero-valued octets when >>> computing or verifying the packet's authenticating value. >>> >>> 0 - Option Data does not change en-route >>> >>> 1 - Option Data may change en-route >>> >>> The three high-order bits described above are to be treated as part >>> of the Option Type, not independent of the Option Type. That is, a >>> particular option is identified by a full 8-bit Option Type, not just >>> the low-order 5 bits of an Option Type. >> >>Is the above text correct? In particular, the text says "mutable" >>rather than "has predictable value at receiver". >> >>Do either or both of these drafts need tweaking? Thomas is correct in pointing out that there are really 3 cases: 1. Immutable -- Option Data does not change en-route 2. Mutable and predictable -- Option Data changes en-route; sender can predict its value at the receiver. 3. Mutable and unpredictable -- Option Data changes en-route; sender cannot predict its value at the receiver. At present, if the Option Data is "mutable", there is no way to tell whether the data is predictable or unpredictable. Hence the IPsec AH spec says that if the data is "mutable", the option data must be zero'd. If the IPv6 text above is changed to something like the following: 0 - Option Data does not change en-route or changes such that the sender can predict the value at the receiver 1 - Option Data may change en-route then case (2) is covered. And one would not need to change the IPsec AH text, but could highlight this if one wanted to by changing the paragraph in IPsec AH quoted by Thomas from: (IPv6 options contain a flag indicating mutability, which determines appropriate processing for such options.) to: (IPv6 options contain a flag indicating "immutable or mutable-predictable" vs "mutable-unpredictable", which determines appropriate processing for such options.) By the way, following up on your/Charlie's conversation re: what happens if sender understands a new extension header but the receiver does not recognize it.... Charlie says that this may not be a big problem because it will only apply if the new extension header is placed in front of the AH header. If it comes after the AH header, it will have been included verbatim in the ICV and not processed prior to the AH header being processed. ------- End Forwarded Message From owner-ipsec Thu Apr 30 01:34:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA02025 for ipsec-outgoing; Thu, 30 Apr 1998 01:32:58 -0400 (EDT) Date: Tue, 28 Apr 1998 14:17:50 -0400 Message-Id: <199804281817.OAA19304@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: IPSEC standardization status Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi all, My apologies for not sending this note out sooner. Unfortunately, there've been a number of non-IPSEC-related fires that have been burning on my desk the last few days. In any case, the IESG met last Thursday and discussed the IPSEC I-D's which we had put before them for last call. The bad news is that there were two "Discuss" votes. The good news is that they are what are called "triggered" discuss votes, so that as soon the issues which the IESG members brought up are resolved, the documents can automatically advance without needing another IESG action. The two discuss votes caused by inconsistencies between the IPSEC documents and other working groups' documents noted by IESG members. One was the inconsistency between the IP Compresion document and the DOI, for which we've since worked out a compromise which I believe is acceptable to all. The other issue is an inconsistency in section 3.3.3.1 of the authentication-header document, where the introductory comments for how mutable extension headers for IPV6 should be handled is somewhat at odds with the current IPV6 documents and the later in the auth-header spec which actually lays out the ICV calculation algorithm for IPV6. I've forwarded this on to Steve Kent and Karen Seo, and they are looking at that now. The IESG action also included some other clarifications and editorial changes to the architecture, auth-header, and ESP documents. These changes were made in response to comments made during last call --- for example, they address Marc Hasson's comments dated April 20th. In most cases these were either typographical errors (or in the case of Marc's inconsistencies) reflect places where the working group had agreed to a certain change, which was applied to the document, but other places in the documents which also needed to be changed to reflect the change weren't necessarily made, thus leaving the document confusing or self-inconsistent. Unfortunately these changes were made after the IESG ballot was mailed out to IESG members, so we weren't able to published the changed draft as I-D's. I have a copy of the changed documents at: http://web.mit.edu/tytso/www/ipsec/newvers These will go out as I-D's once the IPv6 inconsistency in the auth-header problem has been dealt with, and we can then push these out to the RFC editor. (IESG members will be watching to make sure we don't make any changes other than those which they have requested. :-) One set of on-going discussions which happened a tad bit too late to be reflected in this round of the standardization process is the ISAKMP changes. We will have an opportunity to look at some of these issues again (in particularly reserving some exchange values for use by consenting parties) at the next round of the standardization process. So, that's where we are. If anyone has any questions, please feel free to refer them to Bob or myself. - Ted From owner-ipsec Thu Apr 30 01:34:46 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA02004 for ipsec-outgoing; Thu, 30 Apr 1998 01:32:46 -0400 (EDT) Message-Id: <3.0.1.32.19980429181331.006b718c@192.9.200.10> X-Sender: srinu@192.9.200.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Wed, 29 Apr 1998 18:13:31 +0500 To: kent@bbn.com From: K SrinivasRao Subject: When we have to check ? Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, I have a small doubt, suppose the SA life time is in terms of byte counts. At which point actually we have to check this byte count against the packet size, is it after applying SA(where the size will increase) or before applying SA. Thanking U all SrinivasRao. B. Kulkarni Rendezvous On Chip Pvt Ltd. First Floor, Plot No. 14, NewVasaviNagar, Kharkhana, SECUNDERABAD - 500019. INDIA Ph : (040)7742606 email address : srinu@trinc.com From owner-ipsec Thu Apr 30 09:35:16 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA03402 for ipsec-outgoing; Thu, 30 Apr 1998 09:33:02 -0400 (EDT) Message-ID: <35489EA6.6C4F@phase2net.com> Date: Thu, 30 Apr 1998 08:54:14 -0700 From: Jeff Pickering Reply-To: jpickering@phase2net.com Organization: phase2 networks X-Mailer: Mozilla 3.01 (Win16; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: isakmp attrubute ordering question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I have some questions about parsing and constructing SA payloads that I was hoping somebody could answer: 1) The ISAKMP draft (sec 4.2) says "The responder SHOULD retain the Proposal # field in the proposal payload and the Transform # field in each Transform payload of the selected proposal". The intent appears to be making it easy for the initiator to determine what proposal the responder chose. But since the requirement is SHOULD, the intiator cant count on the # fields and therefore needs to use other mechanisms, ie compare each attribute, right? 2) The IKE draft (sec 5) states "Responders MUST NOT modify attributes...". Does this mean responders must also maintain attribute order within a transform? 3) The IKE draft (sec 5 next sentence) states "If the initiator of an exchange notices that attribute values have changed..." The term "notices" seems to be passive and not require that the initiator actually check for changes. Should this sentence be interpreted as MUST,SHOULD or MAY check? Thanks in advance to anyone who comments. regards, jeff From owner-ipsec Thu Apr 30 09:35:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA03406 for ipsec-outgoing; Thu, 30 Apr 1998 09:33:05 -0400 (EDT) Message-Id: <3.0.1.32.19980430131537.006b6188@192.9.200.10> X-Sender: srinu@192.9.200.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Thu, 30 Apr 1998 13:15:37 +0500 To: ipsec@tis.com From: K SrinivasRao Subject: Which SPD we have to use ? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, Even though the same question was asked by some one earlier, but I feel no body responded to it well. Well will any one take some time and answer for below questions. w.r.t draft-ietf-ipsec-isakmp-08.txt. When an outgoing packet does not find any SA associated with it and if IPSEC process has to be applied on it, then we have start negotiating. For this we have to send proposals (may be more than one) to the responder. * Whether the proposal to be sent are from INBOUND SPD or OUTBOUND SPD at the initiator? * How does the responder selects the SPD entry when he receives the proposals? Because selectors are not available. Whether he selects INBOUND SPD or OUTBOUND SPD? * I feel for one negotiation all together 4 SAs are created like. Initiator - Inbound and Outbound SA -- 2 SAs Responder - Inbound and Outbound SA -- 2 SAs Total 4 SAs Am I right ? And if any one of this SA timed out (hard life time), then do we need to terminate all the 4 SAs? How? * Once the negotiation is over how does the initiator and responder links the INBOUND and OUTBOUND SAs with corresponding INBOUND and OUTBOUND SPD entry. For all 4 SAs that are created. * What happens when a INBOUND SA's SoftLifeTime is timed out. Will it start renegotiation. I feel only OUTBOUND SA can initiate the renegotiation process. * If an SA is timed out (hard life time) do we need to delete all the SAs in the SA bundle to which it corresponds to. Thanking U all SrinivasRao. B. Kulkarni Rendezvous On Chip Pvt Ltd. First Floor, Plot No. 14, NewVasaviNagar, Kharkhana, SECUNDERABAD - 500019. INDIA Ph : (040)7742606 email address : srinu@trinc.com From owner-ipsec Thu Apr 30 11:01:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA03780 for ipsec-outgoing; Thu, 30 Apr 1998 10:58:25 -0400 (EDT) Message-Id: <199804301512.LAA20002@cichlid.raleigh.ibm.com> X-Authentication-Warning: cichlid.raleigh.ibm.com: Host localhost.raleigh.ibm.com [127.0.0.1] didn't use HELO protocol To: "Theodore Y. Ts'o" cc: jis@MIT.EDU, ipsec@tis.com, ipng@sunroof.eng.sun.com Subject: Re: [Karen Seo: Thomas Narten -- clarification, etc.] In-reply-to: Your message of "Thu, 30 Apr 1998 01:17:32 EDT." <199804300517.BAA20034@dcl.MIT.EDU> Date: Thu, 30 Apr 1998 11:12:27 -0400 From: Thomas Narten Sender: owner-ipsec@ex.tis.com Precedence: bulk Ted, [Sorry for the cross posting, but this is really both an IPSec and IPv6 issue.] Let me back up a little and clarify the point that caught my attention. draft-ietf-ipsec-auth-header-05.txt says: >>> As a new extension header or IPv4 option is created, it will be >>> defined in its own RFC and SHOULD include (in the Security >>> Considerations section) directions for how it should be handled when >>> calculating the AH ICV. If the IPsec implementation encounters an ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> extension header that it does not recognize, it MUST zero the whole ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> header except for the Next Header and Hdr Ext Len fields. The length >>> of the extension header MUST be computed by 8 * Hdr Ext Len value + >>> 8. If the IPsec implementation encounters an IPv4 option that it >>> does not recognize, it should zero the whole option, using the second >>> byte of the option as the length. (IPv6 options contain a flag >>> indicating mutability, which determines appropriate processing for >>> such options.) There would seem to be an potential interoperability issue here. If what the AH actually covers is determined by what the sending IPSec module understands, how does the receiver obtain that knowledge? The receiver needs to know which headers are covered in order to validate the received AH. First, let us assume that we are talking about an extension header that precedes AH or ESP. Headers that appear afterwards are considered data to the AH/ESP, so nothing special needs to be done for them. If the sender "recognizes" the option, but the receiver does not, presumably there is no issue. The receiver will not know what to do with the header and toss the packet. It doesn't really make sense for a receiver to skip/ignore an extension header it does not understand. This check will take place before IPSec processing takes place. If the sender doesn't "recognize" the option, but the receiver does, here is where the issue comes up. The receiver needs an unambiguous way of knowing whether a particular extension header (that precedes AH) is covered by the AH check. I was assuming that it wouldn't make sense for a node to be sending extension headers it *does* understand that the IPSec module *did not*. I.e., if the extension header is mutable, but its contents are predictable at the reciever, the sending IPSec module should always be able to include it in the AH computation. Couple of perspectives: 1) As you point out, on some systems IPSec may not be upgraded or otherwise stay in sync with new extension headers. I'm not sure I agree with this (or rather, I'm not sure we should explicitely encourage this), but even if it is so, it leads to the interoperability issue described above. The receiver is left guessing which extension headers are actually covered. This would seem to be a bug. 2) One might argue that there will be no need to define future extension headers that a) precede the IPSec header, b) are mutable, but in a predictable way, c) zeroing out (i.e., not including) the extension header in the AH check results in undesired behavior and d) the header needs to be defined as extension headers as opposed to a destination option (which wouldn't have this problem thanks to an explicit bit). However, we should recognize that this approach potentially limits future flexibility, something that should not be done without careful thought. 3) It's not immediately clear to me how one could signal to the receiver in a generic way whether or not an extension header is covered by the AH check. This suggests a couple of approaches: - require that IPSec and future extension headers be upgraded in sync on sending/receiving machines, so that the extension header itself can define the right semantics regarding AH coverage. Note that this may not be as onerous as first appears, since it only applies to new extension headers that *precede* AH. - declare that all extension headers (except the IPv6 headers that are already defined) - including future ones that have yet to be defined - should be zeroed and ignored for the purposes of AH. (That is, take out the text that allows the sender to choose, based on what it understands) - leave the text as is, but at least document the interoperability implications. - are there other possibilities? > Karen and Charlie point out that if the IPV6 draft were changed > so that the meaning of that bit means "mutable or receiver can predict", I think you mean (thanks Matt): "mutable and sender can not predict" > then it would be possible to include such options in the Integrity Check > Value (ICV). That is what I *thought* the bit was supposed to mean. However, the current text doesn't say that, so I'm awaiting clarification from the IPng WG. > However, I note that if we do this, and later someone > defines a new mutable-but-predictable option, IPSEC implementations > which don't know about the new option won't know how to predict option > value, and thus will not be able to properly calculate the ICV. Agreed. But I think there is already an interoperability issue here. > It is therefore simpler to say that all mutable options are not > covered by the ICV, which is the current position of the IPV6 and IPSEC > documents. The tradeoff then is that existing mutable-but-predictable > options will not be integrity-protected. If we would like to change > this, we would need to tweak both documents. However, the introduction > of a new mutable-but-predictable option will cause interoperability > problems with older security gateways, so it's not clear that we will be > able to introduce new mutable-but-predictable options in the future in a > practical fashion anyway. Isn't there a similar issue here in that it may not make sense for the security gateway to understand how to process the option yet *not* understand how to do the integrity check on that option? > Given this, do you have a strong opinion regarding change both > drafts, or leaving them as they currently stand? My recommendation > would be to leave them as they currently stand, on the grounds of > simplifying the implementations. I'd like to hear from the IPng folks regarding the mutable but predictable issue (but that is a separate issue). I'm also uncomfortable with leaving the AH text as is without better addressing the interoperability issue. Thomas From owner-ipsec Thu Apr 30 14:18:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA04503 for ipsec-outgoing; Thu, 30 Apr 1998 14:15:22 -0400 (EDT) Message-ID: <3548C2F0.894156EA@redcreek.com> Date: Thu, 30 Apr 1998 11:29:04 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: ipsec@tis.com Subject: Re: IPSEC standardization status References: <199804281817.OAA19304@dcl.MIT.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk My question is probably answered by Ted's post (which I just received), but I'll toss this out anyway: On March 9 additional ISAKMP ID payload types were referred to here - following is a trimmed portion of that discussion: Daniel Harkins wrote: > Michael Richardson wrote: > > Pertinent issues that are important to get working road > > warrior/gateway tunnels: > > 1. end client has no permanent IP address. The ID payload > > will therefore be FQDN or user@FQDN. > > Or ID_DER_ASN1_DN-- the DER encoding of the DN of the certificate. > > > 2. due to #1, and the fact that the ID payload is not sent > > until the third exchange, a road warrior can not use > > pre-shared-keys for ISAKMP using main mode. The right > > pre-shared-key can not be selected. Section 5.4 of > > isakmp-oakley-06.txt mentions this. Agressive mode can be > > used, but obviously, it does not provide identity protection. > > This is mitigated by the use of the ID_KEY_ID type. From the DOI: > > 4.6.2.12 ID_KEY_ID > > The ID_KEY_ID type specifies an opaque byte stream which may be used > to pass vendor-specific information necessary to identify which pre- > shared key should be used to authenticate Aggressive mode > negotiations. Was there consensus on these additions to the ISAKMP doc? I would like to see them added; would anyone else? From owner-ipsec Thu Apr 30 15:06:38 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA04750 for ipsec-outgoing; Thu, 30 Apr 1998 15:06:09 -0400 (EDT) Date: Thu, 30 Apr 1998 15:19:53 -0400 Message-Id: <199804301919.PAA20352@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Thomas Narten Cc: "Theodore Y. Ts'o" , jis@MIT.EDU, ipsec@tis.com, ipng@sunroof.eng.sun.com In-Reply-To: Thomas Narten's message of Thu, 30 Apr 1998 11:12:27 -0400, <199804301512.LAA20002@cichlid.raleigh.ibm.com> Subject: Re: [Karen Seo: Thomas Narten -- clarification, etc.] Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk A number of folks have pointed out that I wrongly said "receiver can predict", when it should have been "sender can predict". They are of course right. My apologies for the error, which invalidates some of my comments regarding the interoperability issues of changing the sense of the IPv6 "mutable" bit. It seems to me now that making this change is certainly doable, should we have consensus that this would be a good thing to do for IPv6 options. With regards to your observations regarding new IPv6 extension headers: >1) As you point out, on some systems IPSec may not be upgraded or >otherwise stay in sync with new extension headers. I'm not sure I >agree with this (or rather, I'm not sure we should explicitely >encourage this), but even if it is so, it leads to the >interoperability issue described above. The receiver is left guessing >which extension headers are actually covered. This would seem to be a >bug. There is the added complications that the IPSEC processing may be happening on a security gateway which is separate from the end-system which is actually generating the newly defined extension header. The security gateway may be a turnkey "black box" provided by some VPN vendor. So we can't necessarily guarantee IPSEC implementation will be upgraded. >2) One might argue that there will be no need to define future >extension headers that a) precede the IPSec header, b) are mutable, >but in a predictable way, c) zeroing out (i.e., not including) the >extension header in the AH check results in undesired behavior and d) >the header needs to be defined as extension headers as opposed to a >destination option (which wouldn't have this problem thanks to an >explicit bit). However, we should recognize that this approach >potentially limits future flexibility, something that should not be >done without careful thought. I see three primary choices: (1) is to declare that any new extension headers that preceed the IPsec MUST not be included in the ICV (i.e., are zero'ed out), regardless of their mutability status. (2) would be to always included new extension headers in the ICV --- with the net result that new extension header would not be allowed to mutate. Finally (3) we could live with the potential interoperability problem that will occur when we define such a new extension header and it passes through an IPSEC gateway that doesn't understand the new extension. There are two subcases in this last case, (a) the IPSEC gateway simply refuses to process the packet with the unknown extension header, or (b) the IPSEC gateway assumes a default behaviour of zero'ing out the unknown extension header when calculating the ICV. (2)(b) is the current draft wording, and has the property of working if the default behaviour is correct. If the default behaviour is not correct, and the sending IPSEC gateway generates the ICV with the extension header, it will cause the receiver to reject the packet because of a bad ICV value. The worst case behaviour happens if there are two security gateways involved, and both IPSEC gateways don't understand the extension header, and so zero it when the calculate the ICV. Now the ICV matches, and the packet goes through, but the extension is not protected. If the sending and receiving hosts understand the extension, they might assume that the extension has been integrity protected, when in fact it has not been. If the extension has security implications, this would be bad. None of these choices are particularly palatable. Just so I understand the IPV6 issues a little better --- how likely is it that we will want to invent new extension headers? And how likely is it that the ordering will matter and that the new extension header will have to be before the AH header, and could not be placed after the AH header? - Ted From owner-ipsec Thu Apr 30 15:15:22 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA04871 for ipsec-outgoing; Thu, 30 Apr 1998 15:15:11 -0400 (EDT) Message-Id: <199804301927.PAA17855@postal.research.att.com> To: "Theodore Y. Ts'o" cc: Thomas Narten , jis@MIT.EDU, ipsec@tis.com, ipng@sunroof.eng.sun.com Subject: Re: [Karen Seo: Thomas Narten -- clarification, etc.] Date: Thu, 30 Apr 1998 15:27:28 -0400 From: Steve Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk None of these choices are particularly palatable. Just so I understand the IPV6 issues a little better --- how likely is it that we will want to invent new extension headers? And how likely is it that the ordering will matter and that the new extension header will have to be before the AH header, and could not be placed after the AH header? Well, Vern Paxson and I are talking about a new header right now -- and it would have to be mutable. From owner-ipsec Thu Apr 30 16:02:54 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA05105 for ipsec-outgoing; Thu, 30 Apr 1998 16:01:09 -0400 (EDT) Message-Id: <199804302015.NAA07852@gallium.network-alchemy.com> To: "Scott G. Kelly" cc: ipsec@tis.com Subject: Re: IPSEC standardization status In-reply-to: Your message of "Thu, 30 Apr 1998 11:29:04 PDT." <3548C2F0.894156EA@redcreek.com> Date: Thu, 30 Apr 1998 13:15:19 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk >Was there consensus on these additions to the ISAKMP doc? I would like >to see them added; would anyone else? I do not want to see the ISAKMP document ammended at this time. I think this is a great topic for the next revision. Derrell From owner-ipsec Thu Apr 30 16:10:16 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA05215 for ipsec-outgoing; Thu, 30 Apr 1998 16:10:09 -0400 (EDT) Message-ID: <3548DDC1.C73D3ABF@redcreek.com> Date: Thu, 30 Apr 1998 13:23:29 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: "Derrell D. Piper" , ipsec@tis.com Subject: Re: IPSEC standardization status References: <199804302015.NAA07852@gallium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Derrell D. Piper wrote: > > >Was there consensus on these additions to the ISAKMP doc? I would like > >to see them added; would anyone else? > > I do not want to see the ISAKMP document ammended at this time. I think this > is a great topic for the next revision. > > Derrell Obviously, any changes to any of the docs will go into the next revision(s). We have the notice that the docs have moved forward. Many of us (implementors) are discovering oversights, unforseen developments, etc. Should we assume that just because the documents are moving to proposed standard that the work is finished, and that no improvements will be addes? Are we not to continue discussing such suggested improvements on this list? Scott From owner-ipsec Thu Apr 30 16:26:48 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA05320 for ipsec-outgoing; Thu, 30 Apr 1998 16:26:08 -0400 (EDT) Message-Id: <199804302040.NAA07953@gallium.network-alchemy.com> To: "Scott G. Kelly" cc: ipsec@tis.com Subject: Re: IPSEC standardization status In-reply-to: Your message of "Thu, 30 Apr 1998 13:23:29 PDT." <3548DDC1.C73D3ABF@redcreek.com> Date: Thu, 30 Apr 1998 13:40:04 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk Scott, Perhaps I'm just gun shy from the various last call's... By all means, let's continue discussing improvements, including your suggestions for additions to the Phase 2 ID list... I'd also like to start discussions of a new Policy Payload, which I suppose means I should write something up... :-) Derrell From owner-ipsec Thu Apr 30 16:33:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA05367 for ipsec-outgoing; Thu, 30 Apr 1998 16:33:08 -0400 (EDT) Message-ID: <3548E323.F014912B@redcreek.com> Date: Thu, 30 Apr 1998 13:46:27 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: "Derrell D. Piper" CC: ipsec@tis.com Subject: Re: IPSEC standardization status References: <199804302040.NAA07953@gallium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Derrell, Derrell D. Piper wrote: > > I'd also like to start discussions of a new Policy Payload, which I suppose > means I should write something up... :-) Yes, I'm also anxious to see forward movement in this area, and will do whatever I can to contribute. I think we're pretty much all in agreement that we want everything to move along, as the market is demanding solutions yesterday. I also think (agree?) that we need to be careful about changes, insuring that we don't muck up the agreed-upon design. From owner-ipsec Thu Apr 30 16:58:02 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA05481 for ipsec-outgoing; Thu, 30 Apr 1998 16:57:12 -0400 (EDT) Message-Id: <199804230207.WAA00554@morden.sandelman.ottawa.on.ca> To: Thomas Narten CC: ipsec@tis.com Subject: Re: [Karen Seo: Thomas Narten -- clarification, etc.] In-reply-to: Your message of "Thu, 30 Apr 1998 11:12:27 EDT." <199804301512.LAA20002@cichlid.raleigh.ibm.com> Date: Wed, 22 Apr 1998 22:07:55 -0400 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Thomas" == Thomas Narten writes: Thomas> First, let us assume that we are talking about an Thomas> extension header that precedes AH or ESP. Headers that Thomas> appear afterwards are considered data to the AH/ESP, so Thomas> nothing special needs to be done for them. ESP, yes, agreed. AH? I thought that all headers are processed in IPv6. Clearly, AH is not going be a hop-by-hop option, and the end-node options are not going to be mutable, so what you say is probably true in practice. ] Network Security Consulting and Contract Programming | SSH IPsec [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |international[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec Thu Apr 30 16:58:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA05480 for ipsec-outgoing; Thu, 30 Apr 1998 16:57:11 -0400 (EDT) Message-Id: <199804230212.WAA00570@morden.sandelman.ottawa.on.ca> To: Thomas Narten CC: ipsec@tis.com Subject: Re: [Karen Seo: Thomas Narten -- clarification, etc.] In-reply-to: Your message of "Thu, 30 Apr 1998 11:12:27 EDT." <199804301512.LAA20002@cichlid.raleigh.ibm.com> Date: Wed, 22 Apr 1998 22:12:43 -0400 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Thomas" == Thomas Narten writes: Thomas> If the sender "recognizes" the option, but the receiver Thomas> does not, presumably there is no issue. The receiver will Thomas> not know what to do with the header and toss the Thomas> packet. It doesn't really make sense for a receiver to Maybe. Or, maybe some headers are designed to be passed to some (unknown to IPsec) upper layer. Second, you have to do AH checking first. If not, then the bad guy just changes headers to bad values, and the receiver discards them. If the header was covered by AH, then it should really cause an authentication fail, (which should mean to some user that something bad is happening) rather than an "invalid option" header. Thomas> skip/ignore an extension header it does not Thomas> understand. This check will take place before IPSec Thomas> processing takes place. Third, I'm not even sure that this is true. I think that a robust implementation will need to liberal in what it accepts. Thomas> If the sender doesn't "recognize" the option, but the Thomas> receiver does, here is where the issue comes up. The If the sender doesn't recognize the option, why would it put the option in? ] Network Security Consulting and Contract Programming | SSH IPsec [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |international[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec Thu Apr 30 21:42:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA06233 for ipsec-outgoing; Thu, 30 Apr 1998 21:41:12 -0400 (EDT) Date: Thu, 30 Apr 1998 21:54:57 -0400 Message-Id: <199805010154.VAA20482@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Robert Elz Cc: Thomas Narten , "Theodore Y. Ts'o" , jis@MIT.EDU, ipsec@tis.com, ipng@sunroof.Eng.Sun.COM In-Reply-To: Robert Elz's message of Fri, 01 May 1998 07:46:34 +1000, <17976.893972794@munnari.OZ.AU> Subject: Re: (IPng 5744) Re: [Karen Seo: Thomas Narten -- clarification, etc.] Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Fri, 01 May 1998 07:46:34 +1000 From: Robert Elz | Let me back up a little and clarify the point that caught my | attention. draft-ietf-ipsec-auth-header-05.txt says: | | >>> If the IPsec implementation encounters an | >>> extension header that it does not recognize, it MUST zero the whole | >>> header except for the Next Header and Hdr Ext Len fields. To me, that reads like nonsense. If the implementation doesn't recognise the header, what would be the basis upon which it would locate the Next Header or Hdr Ext len fields? Is there some (incorrect) implicit assumption here that all headers for all time will have such fields, and that they'll always be in the same place? I had the exact same reaction, and when I rasied the question, someone who is much more versed in the ways IPv6 told me this was really how extension headers were supposed to work --- and in fact that IPv6 implementations were supposed to ("SHOULD") assume that the Next Header field was in a fixed location, and skip the unknown extension header. Given that extension headers are defined by new IP protocol numbers, this seemed rather (OK, *very*) unclean to me. (Presumably if we were to define a new IP protocol number that wasn't an extension header, the IPV6 protocol would try to process it as an extension header and get a parse error... eventually.) Fortunately, I hadn't eaten recently when this was explained to me, or I probably would have lost my lunch. However, I just checked draft-ietf-ipngwg-ipv6-spec-v2-01.txt, and this doesn't appear to be the case. The IPV6 specification now appears to say that if there is an unknown next-header field, an ICMP code 1 is supposed to be returned. (See the second full paragraph on page 6 of ipv6-spec-v2-01.) If this is the case, this simplifies things significantly. This way, if there is an unknown extension header before the AH header, the IPSEC host (or security gateway) will have already rejected the packet and have sent an ICMP packet back at the sender. So we don't need to have any words about handling unknown extension headers; they will just be rejected. Can someone in the IPNG working group confirm my reading of IPV6 spec? I'm curious --- was it ever the case that the extension header processing worked the way I described them in the first paragraph? The IPV6 expert whom I talked to was pretty definitive that this was the way things worked; I was pretty surprised, since I thought it was incredibly ugly and unclean, but I wasn't the IPv6 expert. - Ted From owner-ipsec Thu Apr 30 22:01:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA06259 for ipsec-outgoing; Thu, 30 Apr 1998 22:01:11 -0400 (EDT) Date: Thu, 30 Apr 1998 19:18:29 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199805010218.TAA02371@death.mentat.com> To: tytso@MIT.EDU Subject: Re: (IPng 5744) Re: [Karen Seo: Thomas Narten -- clarification, etc.] Cc: ipsec@tis.com, ipng@sunroof.Eng.Sun.COM X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Ted, > > If this is the case, this simplifies things significantly. This way, if > there is an unknown extension header before the AH header, the IPSEC > host (or security gateway) will have already rejected the packet and > have sent an ICMP packet back at the sender. So we don't need to have > any words about handling unknown extension headers; they will just be > rejected. Can someone in the IPNG working group confirm my reading of > IPV6 spec? > Your reading is correct. The UNH Interoperability Lab folks have had tests for this case for quite some time. > I'm curious --- was it ever the case that the extension header > processing worked the way I described them in the first paragraph? The > IPV6 expert whom I talked to was pretty definitive that this was the way > things worked; I was pretty surprised, since I thought it was incredibly > ugly and unclean, but I wasn't the IPv6 expert. > Given that the ESP header itself does not conform to this rule regarding extension header structure I don't see how one could require that every other extension header obey this rule. I don't recall it ever being stated or implied that there was a required structure that extension headers had to follow other than they had to have a next header field somewhere and they needed to be a multiple of eight bytes in length to preserve alignment. tim From owner-ipsec Thu Apr 30 22:17:31 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA06292 for ipsec-outgoing; Thu, 30 Apr 1998 22:16:11 -0400 (EDT) Date: Thu, 30 Apr 1998 19:32:58 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199805010232.TAA02379@death.mentat.com> To: tytso@MIT.EDU Subject: Re: (IPng 5744) Re: [Karen Seo: Thomas Narten -- clarification, etc.] Cc: ipsec@tis.com, ipng@sunroof.Eng.Sun.COM X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Ted, > > Given that the ESP header itself does not conform to this rule regarding > extension header structure I don't see how one could require that every > other extension header obey this rule. > Obviously, this is not a real good counter. The ESP header is not really an extension header. It is a "terminal" header similar to TCP, UDP and ICMPv6. tim