From owner-ipsec Mon Mar 3 07:58:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA00818 for ipsec-outgoing; Mon, 3 Mar 1997 07:48:21 -0500 (EST) Message-Id: <199703031252.HAA10181@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: Phil Karn cc: kent@bbn.com, ipsec@tis.com Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) In-reply-to: Your message of "Sun, 02 Mar 1997 23:40:48 PST." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 03 Mar 1997 07:52:54 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Phil Karn writes: > I used the term "transport layer security" to refer to SSL and SSH > because that's the term in common IETF usage. Perhaps we should rename > them to "presentation layer security", because that's what it really > is. And the Internet may even have a true presentation layer for the > first time. :-) > > Your other point about being able to sabotage TCP connections when the > security is layered on top is also quite true. It all depends on your threat > model -- are you more worried about active attacks or passive eavesdropping? One has to worry about both in certain circumstances. The most canonical example is, of course, disrupting BGP connections between routers. Perry From owner-ipsec Mon Mar 3 07:58:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA00929 for ipsec-outgoing; Mon, 3 Mar 1997 07:54:50 -0500 (EST) Message-Id: <199703031254.HAA00929@portal.ex.tis.com> Date: Sun, 2 Mar 1997 23:40:48 -0800 (PST) From: Phil Karn To: kent@bbn.com CC: perry@piermont.com, rmonsour@earthlink.net, ipsec@tis.com Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, I used the term "transport layer security" to refer to SSL and SSH because that's the term in common IETF usage. Perhaps we should rename them to "presentation layer security", because that's what it really is. And the Internet may even have a true presentation layer for the first time. :-) Your other point about being able to sabotage TCP connections when the security is layered on top is also quite true. It all depends on your threat model -- are you more worried about active attacks or passive eavesdropping? Phil From owner-ipsec Mon Mar 3 08:07:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA01003 for ipsec-outgoing; Mon, 3 Mar 1997 08:03:52 -0500 (EST) Message-Id: <199703031217.OAA06263@morden.ssh.fi> To: ipsec@tis.com CC: parkosar@pb.com Subject: Re: transport vs network and ipsec syn In-reply-to: Your message of "Fri, 28 Feb 1997 13:15:23 EST." <9701288571.AA857165346@smtppc.ct.pb.com> Date: Mon, 03 Mar 1997 14:16:09 +0200 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Arthur" == Arthur Parkos writes: Arthur> - it's not guaranteed that all connections will be Arthur> attempted with ipsec authentication Arthur> instantiated. therefore a host will still need to respond Arthur> to the request for a connection. or will a host refuse all Refusing non-authenticated connections is a matter of local policy. I expect many sites to start doing this. One way would that authenticated connections would get priority over non-authenticated connections when it comes to resource allocations. Or there would be seperate pools. Arthur> connect attempts from non-ipsec host. - if ipsec is Arthur> implemented, the host will still need to perform an Arthur> authentication on the potential partner which would eat The key management protocols have been carefully designed to deal with this. Arthur> cpu cycles. - if ipsec is there, the host receives the Arthur> connect attempt and retrieves the address, so what if it Arthur> was signed. couldn't a bad entity sign fake ip addresses Arthur> and then send them on to a potential host to be attacked? Yes, it might cost CPU cycles. Denial of service attacks are very difficult to prevent. The best that I think we can do is to assure that existing connections will still get their fair share of CPU. Arthur> - when will the infrastructure be in place so that a host Arthur> can authenticate a connection attempt from the myriad Arthur> potential connectees where certificates may have been Arthur> issued by different certificate authorities Different CA's? This sounds like a certificate management problem, and I suggest we take this to SPKI or PKIX. ] Temporarily located in balmy Helsinki, Finland, at SSH | one quark [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON | two quark [ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | red q blue q[ ] 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 iQB1AwUBMxrA/MmxxiPyUBAxAQGbyAL8DqhCtS6COfjUW7IUPEKuXKUHNs0OUL60 qCyTQb4QCbgKaNqFi5MeChsBz0oOAUO+jOKlh29Dz6vhXKK/aMEpNN3Dzb453QXP N0wNrw+5AfROqxkn4cMnXHgsi0yZk7vc =ser4 -----END PGP SIGNATURE----- From owner-ipsec Mon Mar 3 17:05:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA04467 for ipsec-outgoing; Mon, 3 Mar 1997 17:01:58 -0500 (EST) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199703032206.OAA29233@kebe.eng.sun.com> Subject: How many algorithms per SA/Transform? To: ipsec@tis.com Date: Mon, 3 Mar 1997 14:06:22 -0800 (PST) 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 Hi folks! I've a question about algorithms per transform/SA. The question is: Will there realistically be more than one algorithm of a given type (i.e. 2 or more ENCRYPTION algorithms or 2 or more AUTHENTICATION algorithms) in a single security association? I don't mean more than one algorithm, period. The Hughes DES/HMAC-MD5 transform proves that we need at least one encryption AND one authentication algorithm in a single security association. What I'm talking about is if there will ever be: DES,Blowfish,Rot13/HMAC-MD5,HMAC-SHA,cksum in a SINGLE SECURITY ASSOCIATION or a SINGLE TRANSFORM? It's a question that I personally think the answer to is, "no". I can't think of any good case (save perhaps protecting headers with one algorithm, and the data with another...) where you'd need more than one algorithm of each type in a single association. Any comments, opinions, etc. are welcome. -- Daniel L. McDonald - Solaris Internet Engineering || MY OPINIONS ARE NOT Mail: danmcd@eng.sun.com, danmcd@kebe.com <*> || NOT NECESSARILY SUN'S! Phone: (415) 786-6815 |"rising falling at force ten WWW: http://www.kebe.com/~danmcd | we twist the world and ride the wind" - Rush From owner-ipsec Mon Mar 3 17:05:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA04488 for ipsec-outgoing; Mon, 3 Mar 1997 17:03:28 -0500 (EST) Message-ID: <01BC27DC.7D4CBA00@Tastid.cisco.com> From: adams@cisco.com (Rob Adams) To: ipsec@tis.com ('ipsec@tis.com') Subject: truncation Date: Mon, 3 Mar 1997 14:08:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Did we ever decide definitively on truncating MD5 and SHA hash's to 96 bits? I think we did but I just want to be clear. Also, how does this apply to the Hughes Combined transform? Do we truncate the MD5 hash there also? I hope so for uniformity's sake. -Rob From owner-ipsec Mon Mar 3 18:23:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA04901 for ipsec-outgoing; Mon, 3 Mar 1997 18:20:03 -0500 (EST) Posted-Date: Mon, 03 Mar 1997 18:18:30 +0000 Message-Id: <9703032324.AA89891@aurora.cis.upenn.edu> To: Dan.McDonald@Eng.sun.com (Dan McDonald) Cc: ipsec@tis.com Subject: Re: How many algorithms per SA/Transform? In-Reply-To: Your message of "Mon, 03 Mar 1997 14:06:22 PST." <199703032206.OAA29233@kebe.eng.sun.com> Date: Mon, 03 Mar 1997 18:18:30 +0000 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In message <199703032206.OAA29233@kebe.eng.sun.com>, Dan McDonald writes: > >It's a question that I personally think the answer to is, "no". I can't >think of any good case (save perhaps protecting headers with one algorithm, >and the data with another...) where you'd need more than one algorithm of >each type in a single association. > One could also have a mixed algorithm; instead of 3-DES, use DES for first round, blowfish for second, etc...i can see this used for 2 reasons: a) DES/Blowfish would be faster than 3-DES, more secure than 2-DES, and prevent the DES keysearch problem (Blowfish/DES wouldn't prevent that however - assuming the same key was used for both algorithms). b) Use a stream cipher and then DES (or the other way around) to obscure known-plaintext analysis. - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBMxtcRb0pBjh2h1kFAQEiCgQAjFgD5vxqdmK2ffDUTI8Lv9R86SY4pFbR PoDjUH2gNAMrg1p5q1PvU3hF49yFbxY8TfNvKo5n9xo46OFOC2Z6RHIdUOKMVBPN WiiMCZ4VR482vkzzfp7/apOnE8PmJTbcxEtS4PejmBhZ/xvYn+nIXkZmeP4jObnL 1rpxCEkh2Rk= =yeYy -----END PGP SIGNATURE----- From owner-ipsec Mon Mar 3 18:53:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA05095 for ipsec-outgoing; Mon, 3 Mar 1997 18:51:49 -0500 (EST) Date: Mon, 3 Mar 1997 18:54:14 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199703032354.SAA24987@earth.hpc.org> To: ipsec@tis.com In-reply-to: Yourmessage <199703032336.QAA14832@baskerville.CS.Arizona.EDU> Subject: Re: How many algorithms per SA/Transform? Sender: owner-ipsec@ex.tis.com Precedence: bulk I think that the more creative uses of multiple algorithms should await a future "active ipsec" architecture, where packets carry authenticated applets that describe their crypto processing. The applet might be the crypto routine(s) itself (themselves). For the IETF here and now, one algorithm at a time. Hey, I never liked putting the encryption and authentication algorithms into one transform in the first place. Hilarie From owner-ipsec Mon Mar 3 21:20:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA05765 for ipsec-outgoing; Mon, 3 Mar 1997 21:17:45 -0500 (EST) Date: Mon, 3 Mar 1997 21:21:54 -0500 From: Norman Shulman X-Sender: norm@rafael.rnd.border.com To: Dan McDonald cc: ipsec@tis.com Subject: Re: How many algorithms per SA/Transform? In-Reply-To: <199703032206.OAA29233@kebe.eng.sun.com> Message-Id: <97Mar3.212302est.11650@elgreco.rnd.border.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Mon, 3 Mar 1997, Dan McDonald wrote: > I've a question about algorithms per transform/SA. The question is: > > Will there realistically be more than one algorithm of a given > type (i.e. 2 or more ENCRYPTION algorithms or 2 or more > AUTHENTICATION algorithms) in a single security association? > > I don't mean more than one algorithm, period. The Hughes DES/HMAC-MD5 > transform proves that we need at least one encryption AND one authentication > algorithm in a single security association. What I'm talking about is if > there will ever be: > > DES,Blowfish,Rot13/HMAC-MD5,HMAC-SHA,cksum > > in a SINGLE SECURITY ASSOCIATION or a SINGLE TRANSFORM? > > It's a question that I personally think the answer to is, "no". I can't > think of any good case (save perhaps protecting headers with one algorithm, > and the data with another...) where you'd need more than one algorithm of > each type in a single association. > > Any comments, opinions, etc. are welcome. Recent relaxation of US export controls make DES more readily available internationally. Someone who wants more security than DES provides might well consider using AH-DES-DES-DES. Norm Norman Shulman Secure Computing Canada Systems Developer Tel 1 416 813 2075 norm@border.com Fax 1 416 813 2001 From owner-ipsec Mon Mar 3 21:53:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA06014 for ipsec-outgoing; Mon, 3 Mar 1997 21:52:22 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <97Mar3.212302est.11650@elgreco.rnd.border.com> References: <199703032206.OAA29233@kebe.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 3 Mar 1997 21:57:47 -0500 To: Norman Shulman From: Stephen Kent Subject: Re: How many algorithms per SA/Transform? Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Norm, I'm confused by your example, specifically "AH-DES-DES-DES." We don't use DES with AH; we use keyed hash functions, e.g., HMAC. AH does not offer encryption, ESP does. But, in the broader context of this discussion, I agree with Hilarie. Let's not make this even more complex than it already is. Steve From owner-ipsec Tue Mar 4 09:50:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA10113 for ipsec-outgoing; Tue, 4 Mar 1997 09:35:22 -0500 (EST) Date: Tue, 4 Mar 1997 09:40:04 -0500 From: Norman Shulman X-Sender: norm@rafael.rnd.border.com To: Stephen Kent cc: ipsec@tis.com Subject: Re: How many algorithms per SA/Transform? In-Reply-To: Message-Id: <97Mar4.094043est.11649@elgreco.rnd.border.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Mon, 3 Mar 1997, Stephen Kent wrote: > I'm confused by your example, specifically "AH-DES-DES-DES." We > don't use DES with AH; we use keyed hash functions, e.g., HMAC. AH does > not offer encryption, ESP does. Sorry for the confusing notation. My point is that someone who has DES but not triple DES might want to use three DES transforms to achieve the effect of triple DES. Norm Norman Shulman Secure Computing Canada Systems Developer Tel 1 416 813 2075 norm@border.com Fax 1 416 813 2001 From owner-ipsec Tue Mar 4 10:20:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA10322 for ipsec-outgoing; Tue, 4 Mar 1997 10:10:40 -0500 (EST) Message-Id: <01BC2884.F8D2F420@erussell-2.ftp.com> From: "Edward A. Russell" To: "'angelos@aurora.cis.upenn.edu'" , "'Dan.McDonald@Eng.sun.com'" Cc: "'ipsec@tis.com'" Subject: RE: How many algorithms per SA/Transform? Date: Tue, 4 Mar 1997 10:15:22 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk >>Angelos D. Keromytis (angelos@aurora.cis.upenn.edu) said on 3/3/97 6:44 PM about Re: How many algorithms per SA/Transform? -----BEGIN PGP SIGNED MESSAGE----- >One could also have a mixed algorithm; instead of 3-DES, use DES for >first round, blowfish for second, etc.. My guess is that would be labelled as a new singular transform with a definition of how it should be applied (e.g. first do DES, them blowfish, etc.) Just throwing a bunch of transforms into an SA does not give enough information for interoperability. So even if the imaginary example you give were to come into existance, it would be a single transform called the DES-BLOWS transform or something like that and have its own draft for standard implementation. Edward Russell erussell@ftp.com From owner-ipsec Tue Mar 4 11:12:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA10743 for ipsec-outgoing; Tue, 4 Mar 1997 11:07:34 -0500 (EST) 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-ipsec-doi-02.txt Date: Tue, 04 Mar 1997 09:49:49 -0500 Message-ID: <9703040949.aa18612@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Internet IP Security Domain of Interpretation for ISAKMP Author(s) : D. Piper Filename : draft-ietf-ipsec-ipsec-doi-02.txt Pages : 20 Date : 03/03/1997 The Internet Security Association and Key Management Protocol (ISAKMP) defines a framework for security association management and cryptographic key establishment for the Internet. This framework consists of defined exchanges and processing guidelines that occur within a given Domain of Interpretation (DOI). This document details the Internet IP Security DOI, which is defined to cover the IP security protocols that use ISAKMP to negotiate their security associations. 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-ipsec-doi-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ipsec-doi-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ipsec-doi-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970303120116.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ipsec-doi-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ipsec-doi-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970303120116.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Mar 4 14:00:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA11844 for ipsec-outgoing; Tue, 4 Mar 1997 13:55:59 -0500 (EST) Message-Id: <199703041900.LAA02411@fluffy.cisco.com> To: Dan.McDonald@Eng.sun.com (Dan McDonald) Cc: ipsec@tis.com Subject: Re: How many algorithms per SA/Transform? In-reply-to: Your message of "Mon, 03 Mar 1997 14:06:22 PST." <199703032206.OAA29233@kebe.eng.sun.com> Date: Tue, 04 Mar 1997 11:00:34 -0800 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, While there's probably not a strong technical argument for something like this, it's not forbidden by the architecture. It would require a base Transform ID in the IPSEC DOI, some defined set (possibly null) of associated attributes, and a draft describing the encapsulation format. (For something this "unique", I'd strongly recommend a self-describing Transform ID and a null attribute set.) FWIW, I really don't expect anyone to propose anything like this... Derrell From owner-ipsec Wed Mar 5 18:44:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA21097 for ipsec-outgoing; Wed, 5 Mar 1997 18:36:06 -0500 (EST) Message-Id: <3.0.32.19970305154052.009a5100@ibeam.jf.intel.com> X-Sender: baiju@ibeam.jf.intel.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 05 Mar 1997 15:40:52 -0800 To: ipsec@tis.com From: "Baiju V. Patel" Subject: To compress or not to compress. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I vote against including compression as part of IPSEC protocol for the following reasons. If each packet is compressed individually, and the dictionary is refreshed for each and every packet, the gain in performance is not clear at all (because there are many small packets on the Internet, and there is lot of compressed content). The only gain is in compressing large data packets which are not previously compressed by the applications. So, I don't see how this will improve the performance significantly. The efficiency of compression improves with increasing data size. Therefore, one can argue for compressing many packets using a single dictionary. If such a scheme is deployed at network layer, it can lead to significant problems for TCP because loss of single packet can lead to loss of many TCP packets and timeouts. Here is an example (Assume that dictionary is updated every 10 packets.) - Host A is sending packets to B (these are TCP packets). - Host A transmits packet 1, 2 and 3 in that order to host B. - Host B receives packet 1 and decompresses it, updates its dictionary. - Packet 2 is lost and packet 3 is received successfully. The packet three cannot be correctly decompressed at B because 2 is lost. It also gets dictionary out of sinc. - After TCP timeout, host A retransmits packet 2 and 3 to B (note that these packets are compressed again because at IP layer, the compression algorithm has no knowledge that it is indeed a retransmitted packet). - since the dictionary is out of sink, the packets are incorrectly decompressed and hence discarded. - This goes on until the dictionary is updated. In conclusion, loss of single packet (or out of order delivery), can lead to serious problems for TCP traffic. Therefore, I vote ``no'' for including compression at IPSEC layer. I am all for applications compressing. Note that this not the situation with SSL where the TCP transmits compressed stream. Therefore, the compressed data is reliably received prior to decompression. (It is no different from transmitting a compressed file). So, just because it is true for SSL does not guarantee that it will work for IPSEC (as efficiently). From owner-ipsec Thu Mar 6 12:30:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA26327 for ipsec-outgoing; Thu, 6 Mar 1997 12:25:30 -0500 (EST) Message-Id: <2.2.32.19970305191238.00b439bc@mailserv-H.ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 05 Mar 1997 14:12:38 -0500 To: Dan.McDonald@Eng.sun.com (Dan McDonald) From: Naganand Doraswamy Subject: Re: How many algorithms per SA/Transform? Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk At 02:06 PM 3/3/97 -0800, Dan McDonald wrote: >Hi folks! > >I've a question about algorithms per transform/SA. The question is: > > Will there realistically be more than one algorithm of a given > type (i.e. 2 or more ENCRYPTION algorithms or 2 or more > AUTHENTICATION algorithms) in a single security association? > >I don't mean more than one algorithm, period. The Hughes DES/HMAC-MD5 >transform proves that we need at least one encryption AND one authentication >algorithm in a single security association. What I'm talking about is if >there will ever be: > > DES,Blowfish,Rot13/HMAC-MD5,HMAC-SHA,cksum > >in a SINGLE SECURITY ASSOCIATION or a SINGLE TRANSFORM? > >It's a question that I personally think the answer to is, "no". I can't >think of any good case (save perhaps protecting headers with one algorithm, >and the data with another...) where you'd need more than one algorithm of >each type in a single association. > >Any comments, opinions, etc. are welcome. > I would also say NO. --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) From owner-ipsec Thu Mar 6 13:05:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA26637 for ipsec-outgoing; Thu, 6 Mar 1997 13:03:21 -0500 (EST) Date: Thu, 6 Mar 1997 12:58:25 -0500 (EST) Message-Id: <199703061758.MAA09960@carp.morningstar.com> From: Ben Rogers To: Naganand Doraswamy Cc: Dan.McDonald@Eng.sun.com (Dan McDonald), ipsec@tis.com Subject: Re: How many algorithms per SA/Transform? In-Reply-To: <2.2.32.19970305191238.00b439bc@mailserv-H.ftp.com> References: <2.2.32.19970305191238.00b439bc@mailserv-H.ftp.com> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Naganand Doraswamy writes: > At 02:06 PM 3/3/97 -0800, Dan McDonald wrote: > >Hi folks! > > > >I've a question about algorithms per transform/SA. The question is: > > > > Will there realistically be more than one algorithm of a given > > type (i.e. 2 or more ENCRYPTION algorithms or 2 or more > > AUTHENTICATION algorithms) in a single security association? >From the latest draft (draft-ietf-ipsec-arch-sec-01.txt), I understand that that you should never have more than one transform per SA: 1.5 Security Association Management ... A single IPsec Security Association is a simplex (unidirectional) connection with which either AH or ESP (but not both) is employed. If both AH and ESP protection is to be applied to a traffic stream, then two (or more) security associations are created to control processing of the traffic stream. To me, this seems to be a clarifcation of RFC1825, and not a change in intent. Is this not the case? ben From owner-ipsec Thu Mar 6 13:39:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA26888 for ipsec-outgoing; Thu, 6 Mar 1997 13:37:08 -0500 (EST) Message-Id: <3.0.16.19970306133925.1d1f5ae8@pop3.pn.com> X-Pgp-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Thu, 06 Mar 1997 13:41:52 -0500 To: ipsec@tis.com From: Rodney Thayer Subject: Re: How many algorithms per SA/Transform? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Please remind me we don't ever want to be in a situation where we both encrypt and sign each packet, thus using an encryption algorithm, a signing algorithm, and an authentication algorithm.... At 02:12 PM 3/5/97 -0500, you wrote: >At 02:06 PM 3/3/97 -0800, Dan McDonald wrote: >>Hi folks! >> >>I've a question about algorithms per transform/SA. The question is: >> >> Will there realistically be more than one algorithm of a given >> type (i.e. 2 or more ENCRYPTION algorithms or 2 or more >> AUTHENTICATION algorithms) in a single security association? >> >>I don't mean more than one algorithm, period. The Hughes DES/HMAC-MD5 >>transform proves that we need at least one encryption AND one authentication >>algorithm in a single security association. What I'm talking about is if >>there will ever be: >> >> DES,Blowfish,Rot13/HMAC-MD5,HMAC-SHA,cksum >> >>in a SINGLE SECURITY ASSOCIATION or a SINGLE TRANSFORM? >> >>It's a question that I personally think the answer to is, "no". I can't >>think of any good case (save perhaps protecting headers with one algorithm, >>and the data with another...) where you'd need more than one algorithm of >>each type in a single association. >> >>Any comments, opinions, etc. are welcome. >> >I would also say NO. > >--Naganand >---------------------------------------------------------------- >naganand@ftp.com >Tel #: (508)684-6743 (O) > > > -------- Rodney Thayer PGP Fingerprint: BB1B6428 409129AC 076B9DE1 4C250DD8 From owner-ipsec Thu Mar 6 14:21:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA27139 for ipsec-outgoing; Thu, 6 Mar 1997 14:19:35 -0500 (EST) Message-Id: <97Mar6.142500est.11651@elgreco.rnd.border.com> To: ipsec@tis.com Subject: Grouping SAs (was Re: How many algorithms per SA/Transform?) References: <2.2.32.19970305191238.00b439bc@mailserv-H.ftp.com> <199703061758.MAA09960@carp.morningstar.com> In-reply-to: ben's message of "Thu, 06 Mar 1997 12:58:25 -0500". <199703061758.MAA09960@carp.morningstar.com> From: "C. Harald Koch" X-uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Thu, 6 Mar 1997 14:24:07 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199703061758.MAA09960@carp.morningstar.com>, Ben Rogers writes: > > A single IPsec Security Association is a simplex (unidirectional) > connection with which either AH or ESP (but not both) is employed. If both > AH and ESP protection is to be applied to a traffic stream, then two (or > more) security associations are created to control processing of the > traffic stream. > > To me, this seems to be a clarifcation of RFC1825, and not a change in > intent. Is this not the case? Which brings us back to an old question: what do you call the set of Security Associations that describe the actual desired results, as in "use AH(HMAC-ND5) for authentication, ESP(DES)(tunnel mode) for encryption, ------------------------------- ------------------------------------ SA 1 SA 2 and only accept traffic that has AH(HMAC-MD5) , ESP(DES)(tunnel mode)." ----------- --------------------- SA 3 SA 4 Is this perhaps a "Security Association Bundle"? Anyone got a better name? -- Harald Koch chk@utcc.utoronto.ca From owner-ipsec Thu Mar 6 15:14:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA27486 for ipsec-outgoing; Thu, 6 Mar 1997 15:12:29 -0500 (EST) Date: Thu, 6 Mar 1997 15:17:05 -0500 From: Norman Shulman X-Sender: norm@rafael.rnd.border.com To: "C. Harald Koch" cc: ipsec@tis.com Subject: Re: Grouping SAs (was Re: How many algorithms per SA/Transform?) In-Reply-To: <97Mar6.142500est.11651@elgreco.rnd.border.com> Message-Id: <97Mar6.151803est.11650@elgreco.rnd.border.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Thu, 6 Mar 1997, C. Harald Koch wrote: > Which brings us back to an old question: what do you call the set of > Security Associations that describe the actual desired results, as in > > "use AH(HMAC-ND5) for authentication, ESP(DES)(tunnel mode) for encryption, > ------------------------------- ------------------------------------ > SA 1 SA 2 > > and only accept traffic that has AH(HMAC-MD5) , ESP(DES)(tunnel mode)." > ----------- --------------------- > SA 3 SA 4 > > > Is this perhaps a "Security Association Bundle"? Anyone got a better name? How about just "Security Bundle" or "Security Package"? Norm Norman Shulman Secure Computing Canada Systems Developer Tel 1 416 813 2075 norm@border.com Fax 1 416 813 2001 From owner-ipsec Thu Mar 6 15:36:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA27640 for ipsec-outgoing; Thu, 6 Mar 1997 15:34:41 -0500 (EST) Message-Id: <199703062034.PAA27640@portal.ex.tis.com> Date: Thu, 06 Mar 1997 15:10:49 -0500 From: Rob & Rachel Glenn Reply-To: rrglenn@erols.com X-Mailer: Mozilla 3.0Gold (Win95; I) MIME-Version: 1.0 To: Rob Adams CC: ipsec@tis.com Subject: Re: truncation References: <01BC27DC.7D4CBA00@Tastid.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Yes, the HMAC hash's will be truncated to 96 bits. I hope to have the "new" AH-HMAC drafts out sometime next week. I can't speak for Jim Hughes draft. Rob G. Rob Adams wrote: > > Did we ever decide definitively on truncating MD5 and SHA hash's to 96 bits? > I think we did but I just want to be clear. > > Also, how does this apply to the Hughes Combined transform? Do we truncate > the MD5 hash there also? I hope so for uniformity's sake. > > -Rob From owner-ipsec Thu Mar 6 15:37:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA27656 for ipsec-outgoing; Thu, 6 Mar 1997 15:36:11 -0500 (EST) From: owner-ipsec@ex.tis.com Message-Id: <199703062036.PAA27656@portal.ex.tis.com> Subject: question about draft semantics To: ipsec@tis.com Date: Thu, 6 Mar 1997 22:18:27 +0200 (EET) Organization: Helsinki University of Technology, TCM-laboratory X-Mailer: ELM [version 2.4 PL21] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Best ipsec mailing list members, The following text is from draft-ietf-ipsec-arch-sec-01.txt: > 1.4 Minimal Essential Support > ...... > > The following sequences of combinations of AH and ESP, each > represented by a separate security association, must be supported by an > IPsec-compliant host: AH, ESP (tunnel), ESP(transport), AH-ESP(transport), > AH-ESP(tunnel), ESP(tunnel)-AH, AH-ESP(tunnel)-ESP(transport), and > ESP(tunnel)-ESP(transport). > ...... >Atkinson [Page 5] > >Internet Draft Security Architecture for IP 10 November 1996 To me, this part of the text seems a bit unclear. I would interpret it so, that the word "each" would refer to the word "combinations". Then this text would in my opinion mean that e.g. the combination AH-ESP(transport) would have one SPI value, not one SPI value for AH and one SPI for ESP(transport). Am I misinterpreting the text? Will always all transforms have an SPI of their own? Kindly, Bengt Sahlin From owner-ipsec Thu Mar 6 17:20:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA28204 for ipsec-outgoing; Thu, 6 Mar 1997 17:17:51 -0500 (EST) Date: 6 Mar 97 16:20:54 -0600 Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) From: "James Hughes" To: dharkins@cisco.com Cc: rmonsour@earthlink.net, ipsec@tis.com X-Mailer: Cyberdog/2.0b1 Mime-Version: 1.0 Message-Id: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I have been hesitant to reply to this. Network Systems presented compression as a feature for an ESP to the IETF IPSEc group in san jose in 1994. NSC has since productized the proprietary ESP that includes compression and pays royalties to IBM for this privilege. We also have numbers on the compression ratios in real world, long run time situations, and even clearing the dictionary on every packet, we average 2:1 compression of data. Even on most small packets, the overhead of the encapsulationis removed by what compression there is. (Sarcasm on) Frankly it is in our best interest that the status quo of the IPSEC group's inability to converge on a compression standard continue (Sarcasm off). After igniting this issue, I would also suggest that this is not very easy issue to resolve. Even if there is someone willing to claim that their compression is unencumbered by patent, are they willing to indemnify you if someone claims it is not? Our contract with IBM includes a statement that they would defend us if their code violates someone else's patent. NSC made a conscious decision to buy because our parent (StorageTek) has deep pockets and would be deeply vulnerable if a claimed public domain compression algorithm was not. I do not know how to handle this. jim On Thu, Feb 27, 1997 7:57 PM, Phil Karn wrote: > >I support the use of compression but not in IPsec. It should be done up > >higher, perhaps the transport level. It's better to compress the stream > >of data before it's divided into packets than to wait and compress each > >packet. I'd rather see 50 packets then 100 smaller ones. > > I feel exactly the same way. I've seen nothing that can beat the > performance of gzip-style compress up above TCP, e.g., in SSH with the > -C option. The fact that gzip is widely distributed GNUware, free of > patent concerns, is just icing on the cake. > > Phil > > From owner-ipsec Thu Mar 6 17:56:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA28487 for ipsec-outgoing; Thu, 6 Mar 1997 17:54:37 -0500 (EST) Message-ID: From: Raul Olaya To: "'ipsec@ex.tis.com'" Subject: IP packet fragmentation Date: Thu, 6 Mar 1997 18:07:08 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk How are IP security transforms applied to fragmented packets (for example a 2000 byte PING which is fragmented into a 1500 byte fragment (header+data) and 548 byte fragment (header+data))?. Is the packet reassembled in the outbound direction and then the security transform applied to the entire reassembled packet?, or is the security transform applied to the first 1500 byte fragment, and 548 byte fragment independently? Raul Olaya From owner-ipsec Thu Mar 6 18:18:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA28625 for ipsec-outgoing; Thu, 6 Mar 1997 18:16:37 -0500 (EST) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199703062319.PAA08906@kebe.eng.sun.com> Subject: Re: IP packet fragmentation To: rolaya@ire.com (Raul Olaya) Date: Thu, 6 Mar 1997 15:19:33 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: from "Raul Olaya" at Mar 6, 97 06:07:08 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 > How are IP security transforms applied to fragmented packets (for > example a 2000 byte PING which is fragmented into a 1500 byte fragment > (header+data) and 548 byte fragment (header+data))?. Is the packet > reassembled in the outbound direction and then the security transform > applied to the entire reassembled packet? IPsec _must_ be done before fragmentation. This is specified in RFC 1825, and why this is a good idea is documented in Bellovin's USENIX Security paper from last summer. Bump-in-the-stack encryptors are a nice short-term fix, but in the long term, IPsec NEEDS to dig its meathooks into the general IP code. Basically, outbound processing is: 1.) create IP headers 2.) Fill in headers 3.) Apply IPsec 4.) Do I fragment? If so, fragment. 5.) Send out the wire. On inbound packets... 1.) Get off the wire, check if for me. If not, forward. 2.) Reassemble 3.) Apply IPsec 4.) Determine HLP/endpoint/etc. > or is the security transform applied to the first 1500 byte fragment, and > 548 byte fragment independently? NO NO NO! This is bad. I'm sure lots of implementations currently do this, but it's bad because either: 1.) You have to keep security information per reassembly queue ** OR ** 2.) The bad guy can inject fragments of his choosing. IMPORTANT SAFETY TIP: IPsec, THEN fragment. -- Daniel L. McDonald - Solaris Internet Engineering || MY OPINIONS ARE NOT Mail: danmcd@eng.sun.com, danmcd@kebe.com <*> || NOT NECESSARILY SUN'S! Phone: (415) 786-6815 |"rising falling at force ten WWW: http://www.kebe.com/~danmcd | we twist the world and ride the wind" - Rush From owner-ipsec Thu Mar 6 19:13:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA28901 for ipsec-outgoing; Thu, 6 Mar 1997 19:09:02 -0500 (EST) Date: Thu, 6 Mar 1997 16:13:30 -0800 Message-Id: <199703070013.QAA26923@gump.eng.ascend.com> From: Karl Fox To: Dan.McDonald@Eng.sun.com (Dan McDonald) Cc: rolaya@ire.com (Raul Olaya), ipsec@tis.com Subject: Re: IP packet fragmentation In-Reply-To: <199703062319.PAA08906@kebe.eng.sun.com> References: <199703062319.PAA08906@kebe.eng.sun.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ipsec@ex.tis.com Precedence: bulk > > How are IP security transforms applied to fragmented packets (for > > example a 2000 byte PING which is fragmented into a 1500 byte fragment > > (header+data) and 548 byte fragment (header+data))?. Is the packet > > reassembled in the outbound direction and then the security transform > > applied to the entire reassembled packet? > > IPsec _must_ be done before fragmentation. This is specified in RFC 1825, > and why this is a good idea is documented in Bellovin's USENIX Security paper > from last summer. If you're running on a host, yes. If you're running on an encrypting gateway, you wrap each fragment in a tunnel mode packet. Of course, you might fragment the resulting encrypted datagram if it's too big. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 From owner-ipsec Thu Mar 6 19:15:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA28952 for ipsec-outgoing; Thu, 6 Mar 1997 19:14:33 -0500 (EST) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199703070019.QAA09101@kebe.eng.sun.com> Subject: Re: IP packet fragmentation To: karl@Ascend.COM Date: Thu, 6 Mar 1997 16:19:18 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: <199703070013.QAA26923@gump.eng.ascend.com> from "Karl Fox" at Mar 6, 97 04:13:30 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 > If you're running on a host, yes. If you're running on an encrypting > gateway, you wrap each fragment in a tunnel mode packet. Good point, but those aren't YOUR fragments. Before YOU fragment, you encrypt. And let's not forget IPv6, where you aren't supposed to have intermediate fragmentation, but it _technically_ happens when you encapsulate. The same analogy applies to IPv4 datagrams with the "don't fragment" bit set. You don't fragment the packet to be forwarded, but if you encapsulate in a tunnel, the tunnel source/dst addresses are of the tunnel endpoints. The end-to-end is tunnel-end to tunnel-end in this case. > Of course, you might fragment the resulting encrypted datagram if it's too > big. See above. Good call, Karl. Dan From owner-ipsec Fri Mar 7 03:07:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA01202 for ipsec-outgoing; Fri, 7 Mar 1997 03:03:31 -0500 (EST) Message-Id: <199703070756.JAA04190@morden.ssh.fi> To: ipsec@tis.com Subject: Re: Grouping SAs (was Re: How many algorithms per SA/Transform?) In-reply-to: Your message of "Thu, 06 Mar 1997 15:17:05 EST." <97Mar6.151803est.11650@elgreco.rnd.border.com> Date: Fri, 07 Mar 1997 09:55:35 +0200 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Norman" == Norman Shulman writes: >> Is this perhaps a "Security Association Bundle"? Anyone got a >> better name? Norman> How about just "Security Bundle" or "Security Package"? Uh... "policy" ?? ] Temporarily located in balmy Helsinki, Finland, at SSH | one quark [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON | two quark [ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | red q blue q[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec Fri Mar 7 11:26:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA03952 for ipsec-outgoing; Fri, 7 Mar 1997 11:21:23 -0500 (EST) Date: Fri, 7 Mar 1997 10:53:40 -0500 (EST) Message-Id: <199703071553.KAA03840@carp.morningstar.com> From: Ben Rogers To: "C. Harald Koch" Cc: ipsec@tis.com Subject: Grouping SAs (was Re: How many algorithms per SA/Transform?) In-Reply-To: <97Mar6.142500est.11651@elgreco.rnd.border.com> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk C. Harald Koch writes: > Which brings us back to an old question: what do you call the set of > Security Associations that describe the actual desired results, as in > > "use AH(HMAC-ND5) for authentication, ESP(DES)(tunnel mode) for encryption, > ------------------------------- ------------------------------------ > SA 1 SA 2 > > and only accept traffic that has AH(HMAC-MD5) , ESP(DES)(tunnel mode)." > ----------- --------------------- > SA 3 SA 4 > > > Is this perhaps a "Security Association Bundle"? Anyone got a better name? We use the term "Security Scheme" which is nice because it is relatively simple, accurately portrays it's own contents, and doesn't sound like a stilted computer geek term. Of course, if the IETF needs to acronym-ize the term (as it seems to do with everything in the whole world), you might end up with a bit of a negative connotation. ben From owner-ipsec Fri Mar 7 13:33:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA04720 for ipsec-outgoing; Fri, 7 Mar 1997 13:30:49 -0500 (EST) Message-Id: <199703071835.AA275259711@relay.hp.com> To: Michael Richardson Cc: ipsec@tis.com Subject: Re: Grouping SAs (was Re: How many algorithms per SA/Transform?) In-Reply-To: mcr's message of Fri, 07 Mar 1997 09:55:35 +0200. <199703070756.JAA04190@morden.ssh.fi> Date: Fri, 07 Mar 1997 13:35:10 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > Norman> How about just "Security Bundle" or "Security Package"? > > Uh... "policy" ?? Too high level; in my mind, "policy" would cover things like "I need to encrypt all packets sent outside the LAN and authenticated all packets inbound from outside the LAN..". 'SA bundle' sounds good to me since "security association" has been defined to be something more low level.. - Bill From owner-ipsec Fri Mar 7 14:00:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA04915 for ipsec-outgoing; Fri, 7 Mar 1997 13:58:58 -0500 (EST) Date: Fri, 7 Mar 1997 13:59:58 -0500 From: John Lowry Message-Id: <199703071859.NAA06697@dave.bbn.com> To: mcr@sandelman.ottawa.on.ca, sommerfeld@apollo.hp.com Subject: Re: Grouping SAs (was Re: How many algorithms per SA/Transform?) Cc: ipsec@tis.com X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Microsoft has frequently been using the word BLOB go cover an aggregation of "stuff" that mere mortals shouldn't play with. How about SA BLOB ? :-) > From owner-ipsec@portal.ex.tis.com Fri Mar 7 13:50:29 1997 > To: Michael Richardson > Cc: ipsec@tis.com > Subject: Re: Grouping SAs (was Re: How many algorithms per SA/Transform?) > Date: Fri, 07 Mar 1997 13:35:10 -0500 > From: Bill Sommerfeld > > > Norman> How about just "Security Bundle" or "Security Package"? > > > > Uh... "policy" ?? > > Too high level; in my mind, "policy" would cover things like "I need > to encrypt all packets sent outside the LAN and authenticated all > packets inbound from outside the LAN..". > > 'SA bundle' sounds good to me since "security association" has been > defined to be something more low level.. > > - Bill > From owner-ipsec Fri Mar 7 15:00:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA05298 for ipsec-outgoing; Fri, 7 Mar 1997 14:56:31 -0500 (EST) Date: Fri, 7 Mar 1997 21:02:30 +0100 From: saiz@gc.ssr.upm.es ("LUIS SAIZ GIMENO") Message-Id: <199703072002.AA04809@orfeo.gc.ssr.upm.es> To: ipsec@tis.com Subject: Re: Grouping SAs (was Re: How many algorithms per SA/Transform?) Sender: owner-ipsec@ex.tis.com Precedence: bulk > From owner-ipsec@portal.ex.tis.com Fri Mar 7 20:51:56 1997 > Date: Fri, 7 Mar 1997 13:59:58 -0500 > From: John Lowry > To: mcr@sandelman.ottawa.on.ca, sommerfeld@apollo.hp.com > Subject: Re: Grouping SAs (was Re: How many algorithms per SA/Transform?) > Cc: ipsec@tis.com > X-Sun-Charset: US-ASCII > Sender: owner-ipsec@ex.tis.com > Content-Length: 881 > > Microsoft has frequently been using the word BLOB go cover an > aggregation of "stuff" that mere mortals shouldn't play with. > How about SA BLOB ? I'm not an english native but *BLOB* is used in crypto too, can this confuse people?? Luis Saiz From owner-ipsec Fri Mar 7 15:18:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA05434 for ipsec-outgoing; Fri, 7 Mar 1997 15:15:09 -0500 (EST) From: bmanning@isi.edu Posted-Date: Fri, 7 Mar 1997 12:19:15 -0800 (PST) Message-Id: <199703072019.AA08777@zed.isi.edu> Subject: Re: Grouping SAs (was Re: How many algorithms per SA/Transform?) To: saiz@gc.ssr.upm.es (LUIS SAIZ GIMENO) Date: Fri, 7 Mar 1997 12:19:15 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: <199703072002.AA04809@orfeo.gc.ssr.upm.es> from "LUIS SAIZ GIMENO" at Mar 7, 97 09:02:30 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 > > Microsoft has frequently been using the word BLOB go cover an > > aggregation of "stuff" that mere mortals shouldn't play with. > > How about SA BLOB ? > > I'm not an english native but *BLOB* is used in crypto too, can this confuse people?? > > Luis Saiz Its also used in database work for very large, undifferentiated datasets. -- --bill From owner-ipsec Sat Mar 8 09:58:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA10221 for ipsec-outgoing; Sat, 8 Mar 1997 09:51:14 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199703062036.PAA27656@portal.ex.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 7 Mar 1997 11:29:57 -0500 To: owner-ipsec@ex.tis.com From: Stephen Kent Subject: Re: question about draft semantics Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bengt, I'm sorry that the text is not clear. It was contributed by me and I'll make sure the ambiguity is removed in the next draft. The intent is that each AH or ESP use require a separate SA, as has been the case for some time. Each combination of AH and ESP applied to a class of traffic might be called an "SA bundle" as suggested in a recent message, but there is no codified nomenclature for such aggregates yet. Steve From owner-ipsec Sat Mar 8 12:28:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA10905 for ipsec-outgoing; Sat, 8 Mar 1997 12:25:51 -0500 (EST) Date: Sat, 8 Mar 97 17:17:15 GMT Standard Time From: Ran Atkinson Subject: Re: transport vs network and ipsec syn To: Arthur Parkos , ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <9701288571.AA857165346@smtppc.ct.pb.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Fri, 28 Feb 97 13:15:23 EST Arthur Parkos wrote: > one question (multipart), i was not sure how ipsec addresses the syn attack: > > - it's not guaranteed that all connections will be attempted with ipsec > authentication instantiated. therefore a host will still need to respond to the > request for a connection. or will a host refuse all connect attempts from > non-ipsec host. The NRL IPsec code that I wrote actually permits the system administrator to configure the node such that connection requests arriving without IPsec are simply dropped and not passed up to TCP. In such a configuration, the node is fully protected against TCP session stealing attacks. The node is also protected from hosts that it has no IPSEC Security Association with. Since the IPSEC Security Association creation requires at least one new round-trip, the current form of TCP SYN flooding attacks (which use a bogus source IP address in the SYN packets) are precluded. If the attacker uses a real source IP address to attack another node, then the attacker's identity is known and provable -- in which case one can add packet filters to one's router/node and/or call the Police. > - if ipsec is implemented, the host will still need to perform an > authentication on the potential partner which would eat cpu cycles. Experience with the cisco ISAKMP/Oakley daemon and NRL IPsec code on a BSD Pentium/90 box with 16 MB of RAM indicates this is not a significant operational issue. > - if ipsec is there, the host receives the connect attempt and retrieves the > address, so what if it was signed. couldn't a bad entity sign fake ip addresses > and then send them on to a potential host to be attacked? I can't parse the above. > - when will the infrastructure be in place so that a host can authenticate > a connection attempt from the myriad potential connectees where > certificates may have been issued by different certificate authorities Not clear how you are defining "infrastructure". If one considers the potential use of DNSSEC to distribute signed public key values, deployment could happen fairly quickly after the next version of BIND (which reportedly will include DNSSEC extensions) is released. TIS has already obtained US Export Licensing for BIND with DNSSEC, so that shouldn't be an obstacle. Ran rja@Inet.org From owner-ipsec Sat Mar 8 12:38:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA10967 for ipsec-outgoing; Sat, 8 Mar 1997 12:37:22 -0500 (EST) Date: Sat, 8 Mar 97 17:32:11 GMT Standard Time From: Ran Atkinson Subject: Re: How many algorithms per SA/Transform? To: Ben Rogers , Naganand Doraswamy Cc: Dan McDonald , ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199703061758.MAA09960@carp.morningstar.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Thu, 6 Mar 1997 12:58:25 -0500 (EST) Ben Rogers wrote: > >From the latest draft (draft-ietf-ipsec-arch-sec-01.txt), I understand > that that you should never have more than one transform per SA: > > 1.5 Security Association Management > > ... > > A single IPsec Security Association is a simplex (unidirectional) > connection with which either AH or ESP (but not both) is employed. If both > AH and ESP protection is to be applied to a traffic stream, then two (or > more) security associations are created to control processing of the > traffic stream. > > To me, this seems to be a clarifcation of RFC1825, and not a change in > intent. Is this not the case? What you say makes sense to me, as the editor of RFC-1825. I will note, however, that with the Combined ESP transform one somewhat obviates the need for end-to-end AH+ESP that existed when RFC-1828/RFC-1829 were the only standards-track transforms. There might be legitimate situations where ESP were used from H1 to H2 and a tunnel-mode AH were in use from R1 to R2, where H1,H2 are IPsec- capable hosts and R1,R2 are IPsec-capable encrypting routers (aka security gateways), and the topology were loosely described as: H1----R1---[IP cloud]---R2---H2 This situation would cause the packets on the wire between R1 and R2 to look something like this: [IP, R1->R2][AH][IP, H1->H2][ESP[user data]] Ran rja@inet.org From owner-ipsec Sat Mar 8 12:47:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA11024 for ipsec-outgoing; Sat, 8 Mar 1997 12:45:53 -0500 (EST) Date: Sat, 8 Mar 97 17:41:51 GMT Standard Time From: Ran Atkinson Subject: Re: question about draft semantics To: ipsec@tis.com, owner-ipsec@ex.tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199703062036.PAA27656@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 --- On Thu, 6 Mar 1997 22:18:27 +0200 (EET) owner-ipsec@ex.tis.com wrote: > To me, this part of the text seems a bit unclear. Mea culpa. I'm sure it will become more clear after Steve Kent edits the text. :-) The correct interpretation is thus: AH and ESP have separate and distinct SPI spaces. When processing a packet, one always knows whether the header being processed is AH or ESP -- hence one knows whether it is an AH SPI or an ESP SPI. Correspondingly, a single Security Association includes only either ESP or AH. No single Security Association contains both ESP and AH. If ESP and AH are used together, there are two distinct SAs -- one for ESP and another for AH. If I'm still not being clear, please post a followup question and I'll try again. :-) Ran rja@inet.org From owner-ipsec Sun Mar 9 20:24:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA18157 for ipsec-outgoing; Sun, 9 Mar 1997 20:16:33 -0500 (EST) Date: Sun, 9 Mar 1997 20:19:15 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199703100119.UAA10857@earth.hpc.org> To: rrglenn@erols.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199703062049.NAA10706@baskerville.CS.Arizona.EDU> Subject: Re: truncation Sender: owner-ipsec@ex.tis.com Precedence: bulk > Yes, the HMAC hash's will be truncated to 96 bits. I hope to have the > "new" AH-HMAC drafts out sometime next week. I can't speak for > Jim Hughes draft. > Rob G. > Rob Adams wrote: > > > > Did we ever decide definitively on truncating MD5 and SHA hash's to 96 bits? > > I think we did but I just want to be clear. > > > > Also, how does this apply to the Hughes Combined transform? Do we truncate > > the MD5 hash there also? I hope so for uniformity's sake. > > > > -Rob The MD5 truncation is not recommended. Hilarie From owner-ipsec Sun Mar 9 23:39:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA19111 for ipsec-outgoing; Sun, 9 Mar 1997 23:37:46 -0500 (EST) From: HUGO@watson.ibm.com Message-Id: <199703100442.XAA33606@mailhub1.watson.ibm.com> Date: Sun, 9 Mar 97 23:42:06 EST To: ho@earth.hpc.org, rrglenn@erols.com cc: ipsec@tis.com Subject: truncation Sender: owner-ipsec@ex.tis.com Precedence: bulk Ref: Your note of Sun, 9 Mar 1997 20:19:15 -0500 Hilarie, you say: > The MD5 truncation is not recommended. we are talking here about truncating HMAC-MD5. Is there any reason why is that "not recommended"? we're finally close to settling this issue so any recommendation against needs to be clearly justified. Hugo From owner-ipsec Mon Mar 10 08:01:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA21527 for ipsec-outgoing; Mon, 10 Mar 1997 07:57:51 -0500 (EST) Message-Id: <3.0.16.19970310075404.1e477788@pop3.pn.com> X-Pgp-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Mon, 10 Mar 1997 08:02:58 -0500 To: ipsec@tis.com From: Rodney Thayer Subject: Re: truncation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Could someone remind us where the justification is for truncation? I remember in San Jose, Hugo stood up and said it was a good idea. I don't remember where it got discussed or what papers were referenced/etc. I realize this probably went by sometime in the past two months but I don't recall when. At 08:19 PM 3/9/97 -0500, you wrote: >> Yes, the HMAC hash's will be truncated to 96 bits. I hope to have the >> "new" AH-HMAC drafts out sometime next week. I can't speak for >> Jim Hughes draft. > >> Rob G. > >> Rob Adams wrote: >> > >> > Did we ever decide definitively on truncating MD5 and SHA hash's to 96 bits? >> > I think we did but I just want to be clear. >> > >> > Also, how does this apply to the Hughes Combined transform? Do we truncate >> > the MD5 hash there also? I hope so for uniformity's sake. >> > >> > -Rob > >The MD5 truncation is not recommended. > >Hilarie > > > -------- Rodney Thayer PGP Fingerprint: BB1B6428 409129AC 076B9DE1 4C250DD8 From owner-ipsec Mon Mar 10 10:12:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA22220 for ipsec-outgoing; Mon, 10 Mar 1997 10:07:58 -0500 (EST) Date: Mon, 10 Mar 1997 10:10:07 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199703101510.KAA05281@earth.hpc.org> To: HUGO@watson.ibm.com Cc: rrglenn@erols.com, ipsec@tis.com In-reply-to: Yourmessage <199703100442.XAA33606@mailhub1.watson.ibm.com> Subject: Re: truncation Sender: owner-ipsec@ex.tis.com Precedence: bulk MD5 is already borderline, and the removal of that much of the output seems way too risky, an invitation to doom. If you only have to match 96 bits, the possibility of taking one message+HMAC and turning it into a legal message'+HMAC, even without knowing the key, seems not impossible, given that only 96 bits have to match. In fact, it seems to me that you might be able to use such a technique to test for individual key bits, using the receiver as a verifier. Hilarie From owner-ipsec Mon Mar 10 12:41:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA23491 for ipsec-outgoing; Mon, 10 Mar 1997 12:37:28 -0500 (EST) Organization: ESAT, K.U.Leuven, Belgium Date: Mon, 10 Mar 1997 18:41:37 +0100 (MET) From: Bart Preneel To: Hilarie Orman cc: HUGO@watson.ibm.com, rrglenn@erols.com, ipsec@tis.com Subject: Re: truncation In-Reply-To: <199703101510.KAA05281@earth.hpc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk I repeat briefly the main points of my post of February 16th: - MD5 is probably not a strong cryptographic primitive. - The most dangerous attacks on HMAC constructions based on MD5 seem to be the _key recovery_ attacks. These attacks become more difficult if truncation is applied. (just as DES in 16-bit CFB is harder to break than DES). Forgery attacks seem to be less realistic, and also not as dangerous as key recovery attacks. Bart Preneel ------------------------------------------------------------------------------- On Mon, 10 Mar 1997, Hilarie Orman wrote: > MD5 is already borderline, and the removal of that much of the output > seems way too risky, an invitation to doom. If you only have to match > 96 bits, the possibility of taking one message+HMAC and turning it > into a legal message'+HMAC, even without knowing the key, seems not > impossible, given that only 96 bits have to match. In fact, it seems > to me that you might be able to use such a technique to test for > individual key bits, using the receiver as a verifier. > > Hilarie > From owner-ipsec Mon Mar 10 13:37:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA23884 for ipsec-outgoing; Mon, 10 Mar 1997 13:35:58 -0500 (EST) Date: Mon, 10 Mar 1997 13:38:19 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199703101838.NAA11494@earth.hpc.org> To: Bart.Preneel@esat.kuleuven.ac.be Cc: ipsec@tis.com, rrglenn@erols.com, HUGO@watson.ibm.com In-reply-to: Yourmessage Subject: Re: truncation Sender: owner-ipsec@ex.tis.com Precedence: bulk Oh, OK, make it 96 bits. Sorry for the diversion. Hilarie From owner-ipsec Tue Mar 11 03:22:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA27928 for ipsec-outgoing; Tue, 11 Mar 1997 03:16:38 -0500 (EST) Message-Id: <9703110820.AA03690@elgamal.radguard.com> Comments: Authenticated sender is From: "Yael Dayan" To: rgm3@chrysler.com Date: Tue, 11 Mar 1997 10:23:14 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: IPSec Interoperability Cc: ipsec@tis.com X-Mailer: Pegasus Mail for Windows (v2.23) Sender: owner-ipsec@ex.tis.com Precedence: bulk Dear Mr. Moskowitz, Our company (Radguard) would like to join the IPSec + ISAKMP/Oakley interoperability effort. If this is possible, we would like some information about the testing schedule and the implementation requirements. Thank You, Yael Dayan Radguard From owner-ipsec Wed Mar 12 13:21:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA11398 for ipsec-outgoing; Wed, 12 Mar 1997 13:10:07 -0500 (EST) Date: Wed, 12 Mar 1997 13:12:43 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199703121812.NAA05496@earth.hpc.org> To: ipsec@tis.com Subject: DIMACS Workshop on Cryptographic Protocol Design and Verification, Sept. 3-5, 1997 Sender: owner-ipsec@ex.tis.com Precedence: bulk The following workshop might be of interest to some of you; it's a chance to tell the formalists what the real problems in crypto protocol correctness are, or to find out what tools are available for determining correctness. Hilarie ===================================================================== From: Barbara Quigley Subject: DIMACS Workshop on Cryptographic Protocol Design and Verification, Sept. 3-5, 1997 -------------------------------------------------------------------------- | DIMACS: Center for Discrete Mathematics & Theoretical Computer Science | | A National Science Foundation Science and Technology Center | -------------------------------------------------------------------------- DIMACS Special Year on Networks Workshop on Cryptographic Protocol Design and Verification September 3-5, 1997 DIMACS Center, CoRE Building, Rutgers University ORGANIZERS: Hilarie Orman, orman@darpa.mil Catherine Meadows, meadows@itd.nrl.navy.mil The purpose of the workshop is to bring together those who design and implement cryptographic protocols with those who formally analyze them, in order to develop a community that can routinely produce secure protocols for use in protecting organizational data and facilitating commerce. The two groups will have opportunities to share ideas about the current state of the art, directions to pursue, and the motivation for their work. Participants will be encouraged to bring demonstration software with them, and part of the workshop organization will involve determining the needs for Internetwork access and local networking. The demonstrations will be of secure protocols in action and of interactive specification and verification techniques. In addition to examining the current state, participants will attempt to quantify the factors that they expect to be significant contributors to scaling the current techniques for future problems. For example, the ability to perform proofs new protocols within a day might be significant. What are the prospects for doing this for a mobile internetwork protocol, for example. Ideally the conclusion of the workshop would be a set of published guidelines for how to design and verify secure cryptographic protocols in reasonable time. --------------------------------------------------------------------- The Special Year program is made possible by long term funding from the National Science Foundation, the New Jersey Commission on Science and Technology and DIMACS university and industry partners. DIMACS Center; Rutgers University; P.O. Box 1179; Piscataway, NJ 08855-1179 TEL: 908-445-5928 FAX: 908-445-5932 ** EMAIL: center@dimacs.rutgers.edu WWW: http://dimacs.rutgers.edu ** TELNET: telnet info.rutgers.edu DIMACS is a partnership of Rutgers University, Princeton University, AT&T Labs, Bellcore, and Bell Laboratories. From owner-ipsec Wed Mar 12 14:08:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA11967 for ipsec-outgoing; Wed, 12 Mar 1997 14:04:44 -0500 (EST) Message-Id: <3.0.1.32.19970312140629.00a14470@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 12 Mar 1997 14:06:29 -0500 To: ipsec@tis.com From: Robert Moskowitz Subject: Round 2, IPsec - Oakley/ISAKMP interop testing Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk The AIAG (Automotive Industry Action Group) will again be hosting an interop test session. Thanks to the kind offer of FTP/Software for a facility, we will be in Andover MA March 24-27th. I am finishing roughing out a interop check list based on the Glenn AH, Hughes Combined, Oakley v6, ISAKMP v2, and X.509v3 documents. I will be posting some details by tomorrow evening. We are interested in both gateway and workstation implementations. Vendors that are ready to test in this time frame, please contact me directly. We are also planning for activities at Interop in May. The AIAG's Automotive Network eXchange (ANX) will be in pilot this summer with controled rollout in the fall. IPsec technology will be required for ANX subscribers. We will give a status report at the wg session, and are working with the IPsec chairs for an implementors session at Memphis. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Wed Mar 12 14:12:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA11986 for ipsec-outgoing; Wed, 12 Mar 1997 14:08:48 -0500 (EST) Date: Wed, 12 Mar 1997 14:11:04 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199703121911.OAA07282@earth.hpc.org> To: ipsec@tis.com Subject: DIMACS Workshop on Cryptographic Protocol Design and Verification, Sept. 3-5, 1997 Sender: owner-ipsec@ex.tis.com Precedence: bulk Here's a more complete announcement for the workshop. Hilarie ============================================================================= DIMACS Workshop on Formal Verification of Security Protocols Sept. 3-5, 1997 Organizers: Hilarie Orman, DARPA and Catherine Meadows, Naval Research Laboratory As we come to rely more and more upon computer networks to perform vital functions, the need for cryptographic protocols that can enforce a variety of security properties has become more and more important. Thus it is no surprise that in recent years a number of new protocols have been proposed for such applications as electronic credit card transactions, Web browsing, and so forth. Since it is notoriously difficult to design cryptographic protocols correctly, this increased reliance on them to provide security has become cause for some concern. This is especially the case since many of the new protocols are extremely complex. In answer to these needs, research has been intensifying in the application of formal methods to cryptographic protocol verification. Recently this work has matured enough so that it is starting to see application to real-life protocols. The goal of this workshop is to facilitate this process by bringing together those were are involved in the design and standardization of cryptographic protocols, and those who are developing and using formal methods techniques for the verification of such protocols. To this end we plan to alternate papers with panels soliciting new paths for research. We are particularly interested in paper and panel proposals addressing new protocols with respect to their formal and informal analysis. Other topics of interest include, but are not limited to - Progress in belief logics - Use of theorem provers and model checkers in verifying crypto protocols - Interaction between protocols and cryptographic modes of operation - Methods for unifying documentation and formal, verifiable specification - Methods for incorporating formal methods into crypto protocol design - Verification of cryptographic API systems - Formal definition of correctness of a cryptographic protocol - Arithmetic capability required for proofs of security for number theoretic systems - Formal definitions of cryptographic protocol requirements - Design methodologies - Emerging needs and new uses for cryptographic protocols - Multiparty protocols, in particular design and verification methods We encourage attendees to bring tools for demonstration. Information about availability of facilities for demonstration will be posted later. To submit a paper to the workshop, submit a one or two page abstract, in Postscript or ASCII to both organizers at the email addresses given below by June 16, 1997. Authors will be notified of acceptance or rejection of abstracts by July 1. Full papers will be due by August 1. Copies of papers will be distributed at the workshop. We also plan to publish a proceedings. Participation in the workshop is *not* limited to those giving presentations. If you would like to attend the workshop, a registration form is available at http://dimacs.rutgers.edu/Workshops/Cryptographic/reg_form.html. Information on accommodations and travel arrangements is available at http://dimacs.rutgers.edu/Workshops/general/accommodations.html and http://dimacs.rutgers.edu/Workshops/general/travel.html. Information on the workshop in general is at http://dimacs.rutgers.edu/Workshops/Cryptographic. Organizers Hilarie Orman Catherine Meadows DARPA ITO Naval Research Laboratory 3701 N. Fairfax Drive Code 5543 Arlington VA 22203-1714 Washington, DC 20375 phone: (703)696-2234 phone: (202)-767-3490 email: horman@darpa.mil email:meadows@itd.nrl.navy.mil From owner-ipsec Wed Mar 12 21:21:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA14775 for ipsec-outgoing; Wed, 12 Mar 1997 21:16:36 -0500 (EST) Message-Id: <199703130221.SAA14356@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: ipsec@tis.com Cc: anx-sec@dot.netrex.net, isakmp-oakley@cisco.com, rlfs@cisco.com Subject: free ISAKMP reference implementation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Mar 1997 18:21:05 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Cisco Systems is pleased to announce the availability of their free ISAKMP+Oakley reference implementation. This is based on ISAKMP version 6 and the ISAKMP+Oakley Resolution document version 2. New features from the previous release include all mandatory and optional authentication methods. Authentication with RSA signatures and RSA encryption is accomplished by compiling the ISAKMP distribution with RSAREF. (Note: RSAREF is *not* included in the distribution). This ISAKMP+Oakley implementation has successfully interoperated with other independent implementations at the ANX IPsec bake-off and in independent testing. And it is fully compliant with the relevant drafts. This distribution uses the PF_KEY Key Management API to register security associations with a PF_KEY aware kernel. The NRL IPsec software distribution contains an implementation of PF_KEY for 4.4-BSD systems. As with all cryptographic utilites this code is export controlled and all applicable (U.S) laws will be obeyed in its distribution. Apologies to all who cannot obtain it. To obtain a copy of the ISAKMP+Oakley distribution (and also a copy of the NRL IPsec distribution) point your favorite browser to: http://www.cisco.com/public/library/isakmp scroll down to "Cisco Systems Implementation" and follow the hot links. Please send all comments, opinions, bug reports and suggestions to the isakmp-oakley mailing list (isakmp-oakley@cisco.com). To join this list send a message to majordomo@cisco.com with "subscribe isakmp-oakley" in the *body* of the message. regards, Dan Harkins From owner-ipsec Thu Mar 13 11:06:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA21122 for ipsec-outgoing; Thu, 13 Mar 1997 11:00:47 -0500 (EST) From: svakil@usr.com Mime-Version: 1.0 Date: Thu, 13 Mar 1997 10:00:42 -0600 Message-ID: <32823C30.3000@usr.com> Subject: Questions on the Security Arch. draft 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 Hi. I had a question on section 1.4 of the Security Architecture draft (draft-ietf-ipsec-arch-sec-01.txt). Specifically, the draft says : "A security gateway which receives a datagram containing a recognised sensitivity label, for example IPSO [Ken91], from a trusted host MUST take that label's value into consideration when creating/selecting an Security Association for use with AH between the gateway and the external destination. In such an environment, a gateway which receives a IP packet containing the IP Encapsulating Security Payload (ESP) should add appropriate authentication, including implicit (i.e. contained in the Security Association used) or explicit label information (e.g. IPSO), for the decrypted packet that it forwards to the trusted host that is the ultimate destination." I don't get the last part about the gateway adding authentication information for the decrypted packet. Does this mean that the gateway uses the SA that it used to decrypt the packet, to generate the authentication info? That really doesn't make sense to me since AH and ESP have separate SAs and also since any given security association is for use with one peer only. Or, is it that the gateway has a security association with the trusted host and tunnels all the packets for that host using this SA? Thanks, Sumit A. Vakil Software Engineer US Robotics, Access Corp. From owner-ipsec Thu Mar 13 14:23:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA22761 for ipsec-outgoing; Thu, 13 Mar 1997 14:14:43 -0500 (EST) Message-Id: <3.0.16.19970313141636.297f94d8@pop3.pn.com> X-Pgp-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Thu, 13 Mar 1997 14:19:43 -0500 To: ipsec@tis.com From: Rodney Thayer Subject: PKI Signature format in ISAKMP -- proposal Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In preparing for the ANX bakeoff there has been some discussion of exactly what a "signature" should look like for ISAKMP. Some people have interpreted this to mean the signature output was in PKCS#1 format. Others have not. In this message I have described what I interpreted this to mean. Note this DOES NOT use PKCS#1. At the end I have listed my reasons for not using PKCS#1 and what I think would have to change to use it. The Oakley resolution draft, in section 5.1, describes the use of "signatures" for authentication. The signature consists of data formed by applying the signature algorithm to a hash and transmitting the signature. In the case of RSA signatures, this means you create a hash and encrypt the hash with the RSA private key. At the receiving end, the process is reversed -- the encrypted data is decrypted using the RSA public key, then the result is compared to the locally calculated hash. [someone else can augment this with proper prose for DSA...] In ISAKMP, this hash which is used in the signature process has specific meaning related to ISAKMP. The draft specifies it to be the HMAC form, and the hash algorithms that may be used are specified explicitly. The procedure used to produce the signature is described here for the RSA signature algorithm case. Note the terms are from draft-ietf-ipsec-isakmp-oakley-03.txt. - ISAKMP produces HASH_I/HASH_R however it wishes - the hash is used as input data for encryption with the RSA private key, with padding as required by the RSA algorithm (see PKCS#1 or the BSAFE documentation) - the (key bits) of encryption output is passed over the wire as the signature - the other side calculates the hash value HASH_I/HASH_R independantly - the other side decrypts the signature data using the public key retrieved from the cert we are sending over the wire - the other side compares the decrypted signature against it's locally calculated hash and if they match you're all set. Note that the 'signature' data passed over the wire is the of data as generated by the RSA algorithm. The normal ISAKMP payload processing allows the receiving side to determine how much data is present. The 'signature', that is, the encoded hash, must be padded as required by the RSA algorithm, so when the data is encrypted it consists of: one byte of zero hash bytes padding of zero bytes up to DIFFERENCE FROM PKCS#1. In PKCS#1 an ASN.1 structure encoded in BER would be transmitted over the wire. I don't think this can be used because: a. PKCS#1 can't be referenced in IETF documents b. PKCS#1 does not define hmac-md5 or hmac-sha1 or Tiger Note also this would add an implementation burden in that the ISAKMP code would be responsible for generating BER encoded information. In my opinion, we should use the 'raw' signature for now. If we could obtain an IETF-compliant defininition of an enhanced PKCS#1 format I would be willing to convert. The fact the PKCS#1 format contains the length and the algorithm is appealing. -----BEGIN PGP SIGNATURE----- Version: 4.0 Business Edition Comment: PGP by ViaCrypt iQCVAgUBMyhSfsKmlvJNktGxAQHJagP/WgKnRWF4IVX92kPlJU9juPacB0fwYNEO slRCKLQcUatueyuSTvar+I23X6tOO/aNGndGsZfwrAss0cPI271TkCwVd4cOkRnY EKRxZEVWS9ieAj9Oh7IwqDAeM2Lun9sDzuUUOJxGXZjuj+rVUaXqa9Gt9GljI2cW SPxfHdkakKI= =22vj -----END PGP SIGNATURE----- Rodney Thayer +1 617 332 7292 Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA Fax: +1 617 332 7970 http://www.shore.net/~sable "Developers of communications software" From owner-ipsec Thu Mar 13 16:48:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA24035 for ipsec-outgoing; Thu, 13 Mar 1997 16:42:15 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <32823C30.3000@usr.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Mar 1997 16:43:21 -0500 To: svakil@usr.com From: Stephen Kent Subject: Re: Questions on the Security Arch. draft Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Sumit, We are in the process of re-writing the architecture document and will address this question in the revised version. If one is using security labels and these labels are implicitly bound to an SA, then it might be appropriate for a gateway terminating a (tunnel mode) SA to introduce such labels into the decapsulated IP header. However, this could backfire if this header were covered by transport mode AH! So, we need to be careful in describing under what circumstances this intermediate system processing is appropriate. I'm not sure that there is other authentication data that ought to be addressed here, in a general fashion, and so we may tighen this part of the spec to focus only on security labels, to the extent appropriate. Ran, as the author of this version of the architecture document, is there anything else you'd like to add to this reply? Steve From owner-ipsec Thu Mar 13 20:21:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA25382 for ipsec-outgoing; Thu, 13 Mar 1997 20:18:39 -0500 (EST) Date: Fri, 14 Mar 97 01:11:19 GMT Standard Time From: Ran Atkinson Subject: Re: Questions on the Security Arch. draft To: ipsec@tis.com, svakil@usr.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <32823C30.3000@usr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Thu, 13 Mar 1997 10:00:42 -0600 svakil@usr.com wrote: > Hi. I had a question on section 1.4 of the Security Architecture > draft (draft-ietf-ipsec-arch-sec-01.txt). Specifically, the draft > says : > > "A security gateway which receives a datagram containing a > recognised sensitivity label, for example IPSO [Ken91], from a trusted > host MUST take that label's value into consideration when > creating/selecting an Security Association for use with AH between the > gateway and the external destination. In such an environment, a > gateway which receives a IP packet containing the IP Encapsulating > Security Payload (ESP) should add appropriate authentication, > including implicit (i.e. contained in the Security Association used) > or explicit label information (e.g. IPSO), for the decrypted packet > that it forwards to the trusted host that is the ultimate > destination." > > I don't get the last part about the gateway adding authentication > information for the decrypted packet. Does this mean that the gateway > uses the SA that it used to decrypt the packet, to generate the > authentication info? That really doesn't make sense to me since AH > and ESP have separate SAs and also since any given security > association is for use with one peer only. Or, is it that the gateway > has a security association with the trusted host and tunnels all the > packets for that host using this SA? If your system does not implement CIPSO and does not implement RFC-1038 or RFC-1108, then the above doesn't apply since those are just about the only known sensitivity labels used with IPv4. If your gateway implements one of those label systems (or is B1 or higher), then the gateway SHOULD use AH (or ESP) when transmitting the packet along to its final destination. The IPsec SA used for transmitting the packet along to its final destination MUST have a sensitivity label value consistent with the sensitivity label associated with that packet when it was received. The goal here is to accurately maintain end-to-end integrity on the sensitivity label of the data. If this is still confusing, send private email. This is not a general interest topic... Ran rja@inet.org From owner-ipsec Fri Mar 14 02:37:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA27133 for ipsec-outgoing; Fri, 14 Mar 1997 02:33:45 -0500 (EST) Message-Id: <199703140707.XAA15976@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Rodney Thayer Cc: ipsec@tis.com Subject: Re: PKI Signature format in ISAKMP -- proposal In-Reply-To: Your message of "Thu, 13 Mar 1997 14:19:43 EST." <3.0.16.19970313141636.297f94d8@pop3.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Mar 1997 23:07:08 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk > In preparing for the ANX bakeoff there has been some discussion > of exactly what a "signature" should look like for ISAKMP. Some > people have interpreted this to mean the signature output was in > PKCS#1 format. Others have not. The fact that it is open to interpretation means it needs clarification. But, regardless of people's interpretation, the intent of the draft is to not do "PKCS#1 Signatures" for RSA-SIG authentication. The intent was to do "PKCS#1 Encryption" of the result of the hmac. > The procedure used to produce the signature is described here for the > RSA signature algorithm case. Note the terms are from > draft-ietf-ipsec-isakmp-oakley-03.txt. > > - ISAKMP produces HASH_I/HASH_R however it wishes > > - the hash is used as input data for encryption with the RSA private > key, with > padding as required by the RSA algorithm (see PKCS#1 or the BSAFE > documentation) > > - the (key bits) of encryption output is passed over the wire as the > signature > > - the other side calculates the hash value HASH_I/HASH_R independantly > > - the other side decrypts the signature data using the public key > retrieved > from the cert we are sending over the wire This is fine for the bake-off but there is no requirement to pass certs over the wire and signature verification should not be dependent upon it. > - the other side compares the decrypted signature against it's locally > calculated hash and if they match you're all set. > > Note that the 'signature' data passed over the wire is the > of data as generated by the RSA algorithm. The > normal ISAKMP payload processing allows the receiving side to > determine how much data is present. The 'signature', that is, > the encoded hash, must be padded as required by the RSA > algorithm, so when the data is encrypted it consists of: > > one byte of zero > hash bytes > padding of zero bytes up to Actually, it should be (from PKCS#1): 00 | BT | PS | 00 | hmac where BT in this case would be a 1 (because it's encrypting with the private key), PS is a string of 0xff which is modulus-length minus 3 minus hmac length in length. > DIFFERENCE FROM PKCS#1. > > In PKCS#1 an ASN.1 structure encoded in BER would be transmitted > over the wire. I don't think this can be used because: > > a. PKCS#1 can't be referenced in IETF documents > b. PKCS#1 does not define hmac-md5 or hmac-sha1 or Tiger > > Note also this would add an implementation burden in that the > ISAKMP code would be responsible for generating BER encoded > information. But is is PKCS#1, it's just "PKCS#1 encryption". To do an RSA signatures you do a PKCS#1-defined RSA private key encryption of the output from the hmac function instead of a PKCS#1-defined "RSA signature" (which includes encoding a magic number that is outside the control of the IETF). > In my opinion, we should use the 'raw' signature for now. > > If we could obtain an IETF-compliant defininition of an enhanced > PKCS#1 format I would be willing to convert. The fact the > PKCS#1 format contains the length and the algorithm is > appealing. The fact that it contains the length is extremely important. Given a key modulus length payload how do you know the true length of the hash is without the above-mentioned encoding? The fact that it contains an algorithm identifier is problematic. The intent of the draft was to do authentication with RSA signatures by encrypting the hmac with a private key and verifying it with the corresponding public key. I've failed quite spectacularly in conveying this. I'm open to suggested text on how to properly convey the intent. regards, Dan. ------------------------------------------------------------------------------- Dan Harkins | E-mail: dharkins@cisco.com Network Protocol Security, cisco Systems | phone: +1 (408) 526-5905 170 W. Tasman Drive | fax: +1 (408) 526-4952 San Jose, CA 95134-1706, U.S.A. | ICBM: 37.45N, 122.03W ------------------------------------------------------------------------------- For your safety and the safety of others: concealed carry, and strong crypto ------------------------------------------------------------------------------- From owner-ipsec Fri Mar 14 15:29:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA02650 for ipsec-outgoing; Fri, 14 Mar 1997 15:21:34 -0500 (EST) Message-Id: <2.2.32.19970314203324.00b4a220@mailserv-H.ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 14 Mar 1997 15:33:24 -0500 To: ipsec@tis.com From: Naganand Doraswamy Subject: Clarification on 3des draft Sender: owner-ipsec@ex.tis.com Precedence: bulk Is there any need to support optional IV for the 3des transform. I would remove it is there is not going to be any hardware that implements 3des and needs to generate its own IV. Thanks, --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) From owner-ipsec Fri Mar 14 15:37:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA02751 for ipsec-outgoing; Fri, 14 Mar 1997 15:35:47 -0500 (EST) Message-ID: From: Greg Carter To: "'rodney@sabletech.com'" , "'dharkins@cisco.com'" Cc: "'ipsec@tis.com'" Subject: RE: PKI Signature format in ISAKMP - DSS Date: Fri, 14 Mar 1997 15:15:27 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Sender: owner-ipsec@ex.tis.com Precedence: bulk This refers to DSS signatures... Could we clarify the format of DSS signatures, all that's in the isakmp-oakley draft is 'encoded', to us that means the DSS signature defined in ANSI X9.30 part 3: "Certificate management for DSA". That is the ASN.1 encoding of r followed by s. ie DER encoding of type: SEQUENCE { r INTEGER, s INTEGER } Bye. From owner-ipsec Fri Mar 14 16:45:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA03239 for ipsec-outgoing; Fri, 14 Mar 1997 16:41:53 -0500 (EST) To: IETF-Announce: cc: ipsec@tis.com From: The IESG Subject: Last Call: The resolution of ISAKMP with Oakley to Proposed Standard Reply-to: iesg@ietf.org Date: Fri, 14 Mar 1997 16:17:42 -0500 Message-ID: <9703141617.aa22907@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk The IESG has received a request from the IP Security Protocol Working Group to consider the following Internet-Drafts for the status of Proposed Standard: o The resolution of ISAKMP with Oakley o Internet Security Association and Key Management Protocol (ISAKMP) o The Internet IP Security Domain of Interpretation for ISAKMP 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 March 28, 1997 Files can be obtained via ftp://ds.internic.net/internet-drafts/ From owner-ipsec Fri Mar 14 17:03:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA03360 for ipsec-outgoing; Fri, 14 Mar 1997 17:03:00 -0500 (EST) Message-Id: <3.0.16.19970314170013.2e9fff5e@pop3.pn.com> X-Pgp-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Fri, 14 Mar 1997 17:07:46 -0500 To: ipsec@tis.com From: Rodney Thayer Subject: IPsec in Memphis - when? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I don't see any IPsec sessions on the agenda at . When is it? -------- Rodney Thayer PGP Fingerprint: BB1B6428 409129AC 076B9DE1 4C250DD8 From owner-ipsec Mon Mar 17 00:44:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA16889 for ipsec-outgoing; Mon, 17 Mar 1997 00:34:00 -0500 (EST) Message-Id: <3.0.32.19970316213807.00930100@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sun, 16 Mar 1997 21:38:10 -0800 To: ipsec@tis.com From: Bob Monsour Subject: Closing out the COMPRESSION discussion Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk All, First, thanks to all who participated in the compression discussion. The debate has been lively and useful. I wanted to make sure that the straw ballot results were available to the list prior to the 3/26 cutoff for drafts to be released in time for Memphis. The results of the straw poll indicated: (1) a significant majority of those who participated in the discussion (there were around 30 total participants) believe that adding compression as an optional feature to ESP is a good idea, and (2) of those in that majority, most felt that using the most-significant bit of the pad length byte as a compressed/not-compressed indicator was an appropriate technique. There were a number of concerns raised on the list and I would like to close out the discussion with some additional insights on these points. 1. Compression belongs at a higher layer than IP There are a handful of people who feel this way. Some responded to this (as I did) by stating that there was no universally appropriate higher layer in which to do the compression. This is indeed true. However, it is certainly true that if compression was added to a higher layer protocol, say TCP, one would have the potential advantage of reducing the number of IP packets as well maintaining compression state across segments. The result would be a higher compression ratio for the same type of data. While adding compression to such a higher layer protocol has its advatnages for some environments, there is *NO* need for it to preclude the OPTIONAL use of compression in IPSec, where there *IS* gain to be had (leading to the next point). 2. There's not enough to gain when compressing packet-by-packet As most of you know (hopefully all of you), the amount of compression you get depends on the type of data being compressed. I first responded to this by providing some compression results based on using the LZS algorithm on some publically available test data. The response to this was "that's not *real* network data". Since that time, I have had a number of discussions with people in the networking industry regarding what *real* network data is. The reality is that one person's *real* network data is another person's meaningless data. You cannot simply sniff someone's T1 connection to the internet to get *real* network data. In the context of IPSec, I would imagine that network data that will be encrypted will look more like today's LAN traffic (currently privately held data that will now, under IPSec, be exposed to the internet). Also, as pointed out by Terry Davis from Boeing, "CAD, GIFs, or other barely compressable objects" will not compress well, but "email or a few thousand pages of maintenance manual" can achieve significant gains by compressing. A second response on this point came from Jim Hughes, who recently stated that "We also have numbers on the compression ratios in real world, long run time situations, and even clearing the dictionary on every packet, we average 2:1 compression of data. Even on most small packets, the overhead of the encapsulationis removed by what compression there is." Similarly, a Q&A doc from VPNet states "VPNet's data compression technology is oriented around a per-packet compensation for security-induced packet expansion. In current network tests, the performance improvement for very small packets is small, but for larger packets, network performance gains are substantial. Improvements between 10 and 40 percent are typical, though for packets containing highly compressible data, improvements of up to 70 percent are possible." 3. Using the most significant bit (msb) of the pad length will cause compatibility problems The proposal involves using the msb of the pad length field to indicate whether or not a packet is compressed. Note that the use of compression is intended to be negotiated on a per SA basis at by the key management protocol. Any current implementation of ESP that does not wish to support the OPTIONAL compression feature is free not to and will suffer no compatibility problems when interoperating with those implementations that support the compression feature. Current implementations will NEVER negotiate to turn on the compression feature. As a result, compressed data will NEVER be sent to them. As such, the msb can continue to be interpreted to mean that there are 128 additional bytes of padding. Implementations that DO support the compression feature will use a maximum of 127 bytes of padding, leaving the msb to indicate compressed/not-compressed. With that said, the working group should expect the next draft of the ESP specification to include compression as an optional feature of ESP (negotiated by the KMP) with the msb of the pad length field used as the packet compressed/not-compressed indicator. -Bob From owner-ipsec Mon Mar 17 11:29:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA21108 for ipsec-outgoing; Mon, 17 Mar 1997 11:25:50 -0500 (EST) Message-Id: <199703171625.LAA21108@portal.ex.tis.com> Date: Mon, 17 Mar 1997 11:21:47 -0500 From: smamros@newoak.com (Shawn Mamros) X-Mailer: Mozilla 4.0b2 (WinNT; I) MIME-Version: 1.0 To: ipsec@tis.com CC: iesg@ietf.org, smamros@newoak.com Subject: Comment on the ISAKMP/Oakley resolution draft X-Priority: 3 (Normal) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@ex.tis.com Precedence: bulk I have a concern regarding the latest version of the ISAKMP/Oakley resolution draft (draft-ietf-ipsec-isakmp-oakley-03.txt). The previous version of the draft (-02) allowed a mode of operation which is no longer possible under the new draft. When using pre- shared keys for authentication (in section 5.3), one can now use Oakley Main Mode only if the pre-shared keys are identified by the IP addresses of the peers. One cannot use keys associated with some other identifier supplied by the initiator (denoted as IDii in the draft), because that payload is encrypted with SKEYID_e, which is derived in part from the pre-shared key in question (as described at the beginning of section 5 - the pre-shared key is used to derive SKEYID, which in turn is used to derive SKEYID_e). The -02 version of the draft did allow Main Mode to be used for any initiator identifier, because SKEYID was derived in a different manner which did not include the pre-shared key. While the -03 draft does state that one can use Oakley Aggressive Mode instead for pre-shared keys, Agressive Mode does not provide identity protection (i.e., encryption of IDii) as Main Mode does. The root cause of the problem seems to be that the -03 draft introduces a new common algorithm for deriving HASH_I and HASH_R which uses SKEYID (beginning of section 5). In the -02 draft, HASH_I and HASH_R were derived differently, depending on which authentication method (signatures, public keys, or pre-shared keys) was used. When using pre-shared keys, the key clearly must be used to derive the hash in order to authenticate the peers to one another. In order to allow for this, the use of the pre-shared key was moved into the derivation for SKEYID. However, doing so introduces a dependency on the pre-shared key for SKEYID_a and SKEYID_e, which did not exist in the -02 draft. While I certainly believe that having common algorithms across different authentication methods wherever possible is a Good Thing in terms of reducing complexity, I do not feel that that justifies eliminating a useful mode of operation which was previously allowed. That being said, I do believe there exists a method by which the new common HASH_I and HASH_R derivation can remain. Just as HASH_I and HASH_R require additional processing to derive SIG_I and SIG_R when using signatures for authentication (section 5.1), one could require an additional step which combines HASH_I and the key into a HASH_I1 (likewise for HASH_R and HASH_R1). This would allow the pre-shared key to be removed from the derivation of SKEYID without losing authentication capability. Of course, I am open to other possible solutions to this problem. My goal here is to allow for a useful mode of operation (pre-shared keys identified by IDii with identity protection provided by Oakley Main Mode) to continue as it did in the prior version of the draft. -Shawn Mamros E-mail to: smamros@newoak.com From owner-ipsec Mon Mar 17 11:55:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA21385 for ipsec-outgoing; Mon, 17 Mar 1997 11:54:33 -0500 (EST) From: pau@watson.ibm.com Date: Mon, 17 Mar 1997 12:04:34 -0500 Message-Id: <9703171704.AA24466@secpwr.watson.ibm.com> To: smamros@newoak.com Subject: Re: Comment on the ISAKMP/Oakley resolution draft Cc: ipsec@tis.com, hugo@watson.ibm.com, pau@watson.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Md5: eZpwI3MlSYwhgkfKKoBwKg== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id LAA21382 Sender: owner-ipsec@ex.tis.com Precedence: bulk Shawn, Hugo and I discovered this too. One solution Hugo has is to give the shared key an ID (like an SPI). This ID could be sent in ID payload together with KE and NONCE. Another possibility I could see is to augment the DOI a little bit and send the key ID in "situation". Pau-Chen > > I have a concern regarding the latest version of the ISAKMP/Oakley > resolution draft (draft-ietf-ipsec-isakmp-oakley-03.txt). > > The previous version of the draft (-02) allowed a mode of operation > which is no longer possible under the new draft. When using pre- > shared keys for authentication (in section 5.3), one can now use > Oakley Main Mode only if the pre-shared keys are identified by the > IP addresses of the peers. One cannot use keys associated with > some other identifier supplied by the initiator (denoted as IDii > in the draft), because that payload is encrypted with SKEYID_e, > which is derived in part from the pre-shared key in question (as > described at the beginning of section 5 - the pre-shared key is > used to derive SKEYID, which in turn is used to derive SKEYID_e). > The -02 version of the draft did allow Main Mode to be used for > any initiator identifier, because SKEYID was derived in a different > manner which did not include the pre-shared key. > > While the -03 draft does state that one can use Oakley Aggressive > Mode instead for pre-shared keys, Agressive Mode does not provide > identity protection (i.e., encryption of IDii) as Main Mode does. > > The root cause of the problem seems to be that the -03 draft > introduces a new common algorithm for deriving HASH_I and HASH_R > which uses SKEYID (beginning of section 5). In the -02 draft, > HASH_I and HASH_R were derived differently, depending on which > authentication method (signatures, public keys, or pre-shared keys) > was used. When using pre-shared keys, the key clearly must be used > to derive the hash in order to authenticate the peers to one another. > In order to allow for this, the use of the pre-shared key was moved > into the derivation for SKEYID. However, doing so introduces a > dependency on the pre-shared key for SKEYID_a and SKEYID_e, which > did not exist in the -02 draft. > > While I certainly believe that having common algorithms across > different authentication methods wherever possible is a Good Thing > in terms of reducing complexity, I do not feel that that justifies > eliminating a useful mode of operation which was previously allowed. > That being said, I do believe there exists a method by which the > new common HASH_I and HASH_R derivation can remain. Just as HASH_I > and HASH_R require additional processing to derive SIG_I and SIG_R > when using signatures for authentication (section 5.1), one could > require an additional step which combines HASH_I and the key into > a HASH_I1 (likewise for HASH_R and HASH_R1). This would allow > the pre-shared key to be removed from the derivation of SKEYID > without losing authentication capability. > > Of course, I am open to other possible solutions to this problem. > My goal here is to allow for a useful mode of operation (pre-shared > keys identified by IDii with identity protection provided by Oakley > Main Mode) to continue as it did in the prior version of the draft. > > -Shawn Mamros > E-mail to: smamros@newoak.com > > > From owner-ipsec Mon Mar 17 14:18:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA22336 for ipsec-outgoing; Mon, 17 Mar 1997 14:17:25 -0500 (EST) Message-Id: <3.0.16.19970317141440.357f70a0@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Mon, 17 Mar 1997 14:22:27 -0500 To: ipsec@tis.com From: Rodney Thayer Subject: IPsec Implementation Survey Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_858644547==_" Sender: owner-ipsec@ex.tis.com Precedence: bulk --=====================_858644547==_ Content-Type: text/plain; charset="us-ascii" Attached is a revision of the IPsec Implementation Survey form. If you have an IPsec implementation and you would like to be listed in the survey, please fill this out and send it back to me, Rodney Thayer, at . I will collect this and publish them to the list before the meeting in Memphis. --=====================_858644547==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="SURVEY2.TXT" Name of Implementation : (name of your implementation/product) Version Described : Organization : (name of your organization) Which IP versions are supported : (IPv4, IPv6, or IPv4 and IPv6) Implements RFC-1828 AH MD5 : (YES, NO, In Progress, Planned, Partial) Implements RFC-1829 ESP DES-CBC : (YES, NO, In Progress, Planned, Partial) Implements AH HMAC MD5 : (YES, NO, In Progress, Planned, Partial; draft rev.) Implements AH HMAC SHA-1: (YES, NO, In Progress, Planned, Partial; draft rev.) Implements Combined ESP (DES+MD5+Replay, etc) : Please list combinations you support, and for each combination indicate (YES, NO, In Progress, Planned, Partial; draft rev.) Examples include MD5+DES+Replay, SHA-1+3DES, etc. Other AH Implemented Transforms : (YES, NO, In Progress, Planned, Partial; draft rev.) Other ESP Implemented Transforms : (YES, NO, In Progress, Planned, Partial; draft rev.) Transport mode : (YES, NO, In Progress, Planned, Partial) Tunnel mode : (YES, NO, In Progress, Planned, Partial) Key Management : (Manual, ISAKMP+Oakley, SKIP, Photuris, other, proprietary) Platforms : (4.4-Lite BSD, Solaris, IRIX, , STREAMS, LINUX, etc) Lineage of IPsec Code : (, ETHZ, JI, KA9Q, NIST, NRL, SUN, not applicable) Lineage of Key Mgmt Code: (, SUN, ETHZ, JI, cisco, not applicable) Location of Source Code : (provide URL if freely available, use the word "proprietary" if isn't freely available) POINTS of Contact : (email address, optionally also phone/fax/name) Claimed Interoperability: (list of systems that your implementation fully interoperates with) --=====================_858644547==_ Content-Type: text/plain; charset="us-ascii" Rodney Thayer +1 617 332 7292 Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA Fax: +1 617 332 7970 http://www.shore.net/~sable "Developers of communications software" --=====================_858644547==_-- From owner-ipsec Mon Mar 17 15:09:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA22787 for ipsec-outgoing; Mon, 17 Mar 1997 15:09:12 -0500 (EST) Message-Id: <199703172013.MAA17906@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: pau@watson.ibm.com Cc: smamros@newoak.com, ipsec@tis.com, hugo@watson.ibm.com Subject: Re: Comment on the ISAKMP/Oakley resolution draft In-Reply-To: Your message of "Mon, 17 Mar 1997 12:04:34 EST." <9703171704.AA24466@secpwr.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Mar 1997 12:13:36 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Shawn, Pau-Chen, > Shawn, Hugo and I discovered this too. One solution Hugo has > is to give the shared key an ID (like an SPI). This ID could > be sent in ID payload together with KE and NONCE. Another > possibility I could see is to augment the DOI a little bit > and send the key ID in "situation". If you pass an ID payload with the KE and NONCE payloads then why do Main Mode? That sounds like an Aggressive Mode to me. And if the ID payload is only some opaque blob of data that has meaning only to the parties involved then there's no loss of "ID protection" in Aggressive Mode. An ID of dharkins@cisco.com means something to a passive evesdropper; an ID of 7a8927c5478 (like a SPI) means nothing so why not just pass it in the clear and do an Aggressive Mode? The problem is that IDs of type FQDN or user@FQDN (the only two that convey any real meaning that the two parties might want to hide) cannot be used to identifiy pre-shared keys to be used with Main Mode. I'm not sure how big a problem this is. The two parties must somehow agree to a pre-shared key in some out-of-band manner, and presumably they'll also agree to some identifier for that key (which right now can't be FQDN or user@FQDN). The IPSec DOI reserves 6 ID types for private use. The two parties could agree that the identifier will be some opaque blob (like a SPI) and it's ID type will be from the private use range. Then you do Aggressive Mode with out conveying your identities to any evesdroppers; you retain "ID protection". Why isn't this acceptable? The pre-shared key was put into SKEYID, and SKEYID is used as the key to the HMAC (as opposed to part of the data to hash) on the recommendation of a cryptographer (it's a security issue). I'm hesitant to remove it to allow a case that I don't see as overwhelmingly compelling. Comments? Dan. From owner-ipsec Mon Mar 17 18:22:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA23983 for ipsec-outgoing; Mon, 17 Mar 1997 18:19:16 -0500 (EST) From: HUGO@watson.ibm.com Message-Id: <199703172324.SAA50747@mailhub1.watson.ibm.com> Date: Mon, 17 Mar 97 17:48:17 EST To: dharkins@cisco.com, PAU@watson.ibm.com, piper@cisco.com cc: smamros@newoak.com, ipsec@tis.com Subject: Comment on the ISAKMP/Oakley resolution draft (pre-shared) Sender: owner-ipsec@ex.tis.com Precedence: bulk Shawn and other intersted parties: Having the pre-shared key in SKEYID and the derived keys increases security. It was my recommendation to do so. As just one example consider two parties that use DH with a public prime p. If at some point enough cryptanalysis and pre-computation is done on p then every exchange using that prime may be compromised. This is a not-impossible scenario where you lose (in a hard way) all the advantages of perfect forward secrecy (your traffic of the last few years may be compromised!). If, however, you derived your key depending on both g^xy and your pre-shared key the attacker will need to find the value of that pre-shared key (which will probably not exist at that point of time) to find the actual keys used to protect the session traffic. I agree with you that having to tie the pre-shared key only to IP addresses is too much of a loss of flexibility and functionality of the protocol. However, there is the simple solution suggested in Pau-Chen and Dan's messages. That is, use a key identifier for the pre-shared key: such a key identifier would be meaningful only to the specific parties sharing that key. As Dan pointed out you can then dispense of non-aggressive mode and just do aggressive, thus saving communication. (You may still want non-aggressive mode for the sake of negotiation). Bottom line: we achieved more security, a more modular protocol, less communication and full functionality. In order to accomodate this key identifier one needs an "Identifiction Type Value" as defined in the Ipsec DOI (draft-ietf-ipsec-ipsec-doi-02.txt). This can be one of the "private" values to be agrred upon by the communicating parties, or we could have a type value (say 7) added in that draft for "ID_KEY". If there is no opposition to do so I would suggest this mininal editorial change to the DOI draft. Hugo From owner-ipsec Mon Mar 17 19:05:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA24219 for ipsec-outgoing; Mon, 17 Mar 1997 19:04:13 -0500 (EST) From: HUGO@watson.ibm.com Message-Id: <199703180009.TAA29672@mailhub1.watson.ibm.com> Date: Mon, 17 Mar 97 18:53:17 EST To: smamros@newoak.com cc: dharkins@cisco.com, PAU@watson.ibm.com, piper@cisco.com, ipsec@tis.com, smamros@newoak.com Subject: Comment on the ISAKMP/Oakley resolution draft (pre-shared) Sender: owner-ipsec@ex.tis.com Precedence: bulk See response below. > HUGO@watson.ibm.com wrote: > > Having the pre-shared key in SKEYID and the derived keys increases security. > > It was my recommendation to do so. As just one example consider two > > parties that use DH with a public prime p. If at some point enough > > cryptanalysis and pre-computation is done on p then every exchange using that > > prime may be compromised. This is a not-impossible scenario where you > > lose (in a hard way) all the advantages of perfect forward secrecy > > (your traffic of the last few years may be compromised!). > > If, however, you derived your key depending > > on both g^xy and your pre-shared key the attacker will need to find the > > value of that pre-shared key (which will probably not exist at that point > > of time) to find the actual keys used to protect the session traffic. > > OK, but if that's the case, is there then a problem with the > derivation of SKEYID in the case where signatures are used for > authentication, where only the nonces (passeed across the wire in > plaintext) and g^xy are used? You are right. In this sense the signature mode is the weakest of all three modes. In particular, in the case the public key encryption mode of authentication the attacker needs to break the TWO private keys of the parties AND the DH prime to find the keys (i.e. you get the MAXIMAL security of both DH and RSA). This is one of the important reasons why I have been "promoting" this mode for long time. BTW, this not only protects against a broken DH, but also against a partner to the communciation that implements poorly the DH exchange, e.g. by choosing short exponents or by not destroying the exponents immediately after use. In addition, the signature mode has several privacy weaknesses: it provides proofs of communication between the communicating parties, does not protects identities against active attacker (on the other hand it protects idenities with PFS), and does not provide identity-protection at all in aggressive mode. > > Regarding the other comments and suggestions that have been made, > I may have more to say in the next day or two - need to do some > more thinking on the subject... Hope it will be ok with you and others. Using pre-shared key in this way (with a key identifier) seems to be the best solution in many cases, e.g. for mobile users and dynamic IP addrsses. Hugo > > -Shawn Mamros > E-mail to: smamros@newoak.com From owner-ipsec Tue Mar 18 07:42:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA28129 for ipsec-outgoing; Tue, 18 Mar 1997 07:36:43 -0500 (EST) Message-Id: <199703181236.HAA28129@portal.ex.tis.com> Date: Mon, 17 Mar 1997 18:45:51 -0500 From: smamros@newoak.com (Shawn Mamros) X-Mailer: Mozilla 4.0b2 (WinNT; I) MIME-Version: 1.0 To: HUGO@watson.ibm.com CC: dharkins@cisco.com, PAU@watson.ibm.com, piper@cisco.com, ipsec@tis.com, smamros@newoak.com Subject: Re: Comment on the ISAKMP/Oakley resolution draft (pre-shared) X-Priority: 3 (Normal) References: <199703172324.SAA50747@mailhub1.watson.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@ex.tis.com Precedence: bulk HUGO@watson.ibm.com wrote: > Having the pre-shared key in SKEYID and the derived keys increases security. > It was my recommendation to do so. As just one example consider two > parties that use DH with a public prime p. If at some point enough > cryptanalysis and pre-computation is done on p then every exchange using that > prime may be compromised. This is a not-impossible scenario where you > lose (in a hard way) all the advantages of perfect forward secrecy > (your traffic of the last few years may be compromised!). > If, however, you derived your key depending > on both g^xy and your pre-shared key the attacker will need to find the > value of that pre-shared key (which will probably not exist at that point > of time) to find the actual keys used to protect the session traffic. OK, but if that's the case, is there then a problem with the derivation of SKEYID in the case where signatures are used for authentication, where only the nonces (passeed across the wire in plaintext) and g^xy are used? Regarding the other comments and suggestions that have been made, I may have more to say in the next day or two - need to do some more thinking on the subject... -Shawn Mamros E-mail to: smamros@newoak.com From owner-ipsec Tue Mar 18 08:53:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA28821 for ipsec-outgoing; Tue, 18 Mar 1997 08:53:01 -0500 (EST) 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-vpn-00.txt Date: Tue, 18 Mar 1997 08:49:48 -0500 Message-ID: <9703180849.aa18842@ietf.org> 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 : Implementation of Virtual Private Network (VPNs) with IP Security Author(s) : N. Doraswamy Filename : draft-ietf-ipsec-vpn-00.txt Pages : 5 Date : 03/14/1997 This document discusses methods for implementing Virtural Private Networks (VPN) with IP Security (IPSec). We discuss different scenarios in which VPN is implemented and the security implications for each of these scenarios. 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-vpn-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-vpn-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-vpn-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970317162735.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-vpn-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-vpn-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970317162735.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Mar 18 11:19:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00056 for ipsec-outgoing; Tue, 18 Mar 1997 11:17:46 -0500 (EST) Date: Tue, 18 Mar 97 16:15:01 GMT Standard Time From: Ran Atkinson Subject: Re: Closing out the COMPRESSION discussion To: Bob Monsour , ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <3.0.32.19970316213807.00930100@earthlink.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk All, The WG chairs do not see any clear consensus on compression within the IPsec WG at this time. As such, the discussion on compression is NOT "closed". In fact additional discussion on this topic is encouraged. We hope to have further discussions in Memphis on the topic of compression. People desiring to make technical presentations on this (or other IPsec) topic(s) should send email to me and Paul Lambert with the topic and time requested. Ran rja@inet.org From owner-ipsec Tue Mar 18 11:41:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00239 for ipsec-outgoing; Tue, 18 Mar 1997 11:40:04 -0500 (EST) Date: Tue, 18 Mar 97 16:37:36 GMT Standard Time From: Ran Atkinson Subject: [Admin] 38th IETF: IPSEC slots To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <2.2.32.19970318162210.0070912c@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk There are two sessions for IPSEC in Memphis as follows: Wednesday, April 9 at 0900-1115 (opposite stdguide, rmonmib, pktway, run, ids, rps, ftpext, qosr, otsv) Thursday, April 10 at 1300-1500 (opposite fax, mpls, lsma, ipngwg) One of these meetings will be focused on implementation discussions, including reports from the AIAG interoperability testing, etc. The other will focus more on standards issues. Ran rja@inet.org From owner-ipsec Tue Mar 18 12:18:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA00506 for ipsec-outgoing; Tue, 18 Mar 1997 12:06:00 -0500 (EST) Message-Id: <3.0.16.19970318120243.2957b404@pop3.pn.com> X-Pgp-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Tue, 18 Mar 1997 12:10:55 -0500 To: ipsec@tis.com From: Rodney Thayer Subject: survey results Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk If you have previously responded to a survey and you don't have any changes, you don't have to respond again. I will post the existing survey results along with the new ones I'm receiving. Sorry about the confusion. Rodney Thayer +1 617 332 7292 Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA Fax: +1 617 332 7970 http://www.shore.net/~sable "Developers of communications software" From owner-ipsec Tue Mar 18 15:04:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA00939 for ipsec-outgoing; Tue, 18 Mar 1997 15:01:06 -0500 (EST) Message-ID: <332EF66B.7701@newoak.com> Date: Tue, 18 Mar 1997 15:09:15 -0500 From: smamros@newoak.com (Shawn Mamros) X-Mailer: Mozilla 4.0b2 (WinNT; I) MIME-Version: 1.0 To: HUGO@watson.ibm.com CC: dharkins@cisco.com, PAU@watson.ibm.com, piper@cisco.com, ipsec@tis.com, smamros@newoak.com Subject: Re: Comment on the ISAKMP/Oakley resolution draft (pre-shared) X-Priority: 3 (Normal) References: <199703172324.SAA50747@mailhub1.watson.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@ex.tis.com Precedence: bulk After thinking about the issue some more and discussing it with my coworkers, we're willing to go with the workaround proposed by Pau-Chen, Dan and Hugo (i.e., using an opaque identifier in Oakley Aggressive Mode to find the correct pre-shared key). Thanks for the suggestion, guys... One possibility that Hugo mentioned in one of his messages: > In order to accomodate this key identifier one needs an > "Identifiction Type Value" as defined in the Ipsec DOI > (draft-ietf-ipsec-ipsec-doi-02.txt). > This can be one of the "private" values to be agrred upon by the > communicating parties, or we could have a type value (say 7) added in > that draft for "ID_KEY". > If there is no opposition to do so I would suggest this mininal editorial > change to the DOI draft. Ideally, I too would like to see an "official" value designated in the DOI draft, if it's possible. But I'm willing to live with a private value if we have to... -Shawn Mamros E-mail to: smamros@newoak.com From owner-ipsec Tue Mar 18 15:06:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA00987 for ipsec-outgoing; Tue, 18 Mar 1997 15:06:03 -0500 (EST) Message-Id: <199703182009.MAA03622@mailsun3-fddi.us.oracle.com> Date: 18 Mar 97 11:09:43 -0800 From: "PALAMBER.US.ORACLE.COM" To: ipsec@tis.com Subject: IPSEC Agenda Cc: rodney@sabletech.com, rja@inet.org MIME-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.0.4.0.25) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Sender: owner-ipsec@ex.tis.com Precedence: bulk There will be two IPSEC sessions in Memphis: Wednesday, April 9 at 0900-1115 (opposite stdguide, rmonmib, pktway, run, ids, rps, ftpext, qosr, otsv) Thursday, April 10 at 1300-1500 (opposite fax, mpls, lsma, ipngwg) The first session will cover the IPSEC specifications in progress and ongoing or new IPSEC work items. The second session will be an implementation session that only covers implementation issues, interoperability testing, interoperability profiles, etc. Please send requests for agenda slots asap to the co-chairs (rja@inet.org, palamber@us.oracle.com). Please be sure to have "IPSEC Agenda" in your subject line or your message may be ignored. Preference is always given to editors of IPSEC I-Ds. If you are interested in presenting during the implementation session please also copy to Rodney Thayer (rodney@sabletech.com). Rodney is helping coordinate the IPSEC implementation session in Memphis (thanks Rodney!). Regards, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 633-2963 Redwood Shores, CA 94065 E-Mail: palamber@us.oracle.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Secure jobs for software developers 6+ years experience. Send resumes to palamber@us.oracle.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-ipsec Tue Mar 18 15:57:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA01310 for ipsec-outgoing; Tue, 18 Mar 1997 15:56:57 -0500 (EST) Message-Id: <199703182022.MAA09677@fluffy.cisco.com> To: smamros@newoak.com (Shawn Mamros) cc: HUGO@watson.ibm.com, dharkins@cisco.com, PAU@watson.ibm.com, piper@cisco.com, ipsec@tis.com Subject: Re: Comment on the ISAKMP/Oakley resolution draft (pre-shared) In-reply-to: Your message of "Tue, 18 Mar 1997 15:09:15 EST." <332EF66B.7701@newoak.com> Date: Tue, 18 Mar 1997 12:22:16 -0800 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk This seems like a worthwhile addition. I'll post an updated IPSEC DOI before the Memphis deadline. I have one other attribute that needs to be added ("Key Length" for variable length ciphers like RC5). Derrell From owner-ipsec Tue Mar 18 17:32:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA01887 for ipsec-outgoing; Tue, 18 Mar 1997 17:27:56 -0500 (EST) Date: 18 Mar 97 16:32:27 -0600 Subject: Re: [Admin] 38th IETF: IPSEC slots From: "James Hughes" To: ipsec@tis.com, "Ran Atkinson" X-Mailer: Cyberdog/2.0b1 Mime-Version: 1.0 Message-Id: Content-Type: multipart/mixed; boundary="Cyberdog-MixedBoundary-00034EB0" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk --Cyberdog-MixedBoundary-00034EB0 X-Fontfamily: Palatino X-Fontsize: 12 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Should I plan on presenting? jim On Tue, Mar 18, 1997 10:37 AM, --Cyberdog-MixedBoundary-00034EB0 Content-Type: application/X-url Content-Transfer-Encoding: base64 Content-Description: Ran Atkinson bWFpbHRvOnJqYUBpbmV0Lm9yZw== --Cyberdog-MixedBoundary-00034EB0 X-Fontfamily: Palatino X-Fontsize: 12 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable wrote: > > > There are two sessions for IPSEC in Memphis as follows: > > Wednesday, April 9 at 0900-1115 (opposite stdguide, rmonmib, pktway, > run, ids, rps, ftpext, qosr, otsv) > Thursday, April 10 at 1300-1500 (opposite fax, mpls, lsma, ipngwg) > > One of these meetings will be focused on implementation discussions, > including reports from the AIAG interoperability testing, etc. > > The other will focus more on standards issues. > > Ran > rja@inet.org --Cyberdog-MixedBoundary-00034EB0-- From owner-ipsec Tue Mar 18 18:41:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA02261 for ipsec-outgoing; Tue, 18 Mar 1997 18:39:58 -0500 (EST) Message-Id: <2.2.32.19970318235202.00b0e704@mailserv-H.ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Mar 1997 18:52:02 -0500 To: ipsec@tis.com From: Naganand Doraswamy Subject: Issues with generating IV's in combined transforms Sender: owner-ipsec@ex.tis.com Precedence: bulk Both DES and 3DES combined transform specify the way to generate IV's. However, we dont maintain a running IV. In this case, isint it better to just send an IV in the packet always and not make it optional? --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) From owner-ipsec Tue Mar 18 20:38:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA02940 for ipsec-outgoing; Tue, 18 Mar 1997 20:36:58 -0500 (EST) Message-Id: <199703190141.RAA19484@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: ipsec@tis.com Cc: anx-sec@dot.netrex.net Subject: cisco's free ISAKMP reference implementation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Mar 1997 17:41:27 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk A bug has been found in the latest ISAKMP release from cisco. If any of you obtained a copy (and want to do signature authentication) please get a fresh copy. Sorry for the inconvienence. Dan. From owner-ipsec Wed Mar 19 09:59:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA07232 for ipsec-outgoing; Wed, 19 Mar 1997 09:56:36 -0500 (EST) Message-Id: <3.0.32.19970319065713.00949100@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 19 Mar 1997 06:57:20 -0800 To: Ran Atkinson From: Bob Monsour Subject: Re: Closing out the COMPRESSION discussion Cc: Bob Monsour , ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Would someone like to suggest where to take the discussion from here? -Bob At 04:15 PM 3/18/97 Time, Ran Atkinson wrote: >All, > >The WG chairs do not see any clear consensus on compression within the IPsec >WG at this time. As such, the discussion on compression is NOT "closed". >In fact additional discussion on this topic is encouraged. > >We hope to have further discussions in Memphis on the topic of compression. > >People desiring to make technical presentations on this (or other IPsec) >topic(s) should send email to me and Paul Lambert >with the topic and time requested. > >Ran >rja@inet.org > > > From owner-ipsec Wed Mar 19 11:02:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA07734 for ipsec-outgoing; Wed, 19 Mar 1997 11:00:03 -0500 (EST) Message-Id: <3.0.1.32.19970319110315.00b4ad70@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 19 Mar 1997 11:03:15 -0500 To: Bob Monsour , Ran Atkinson From: Robert Moskowitz Subject: Re: Closing out the COMPRESSION discussion Cc: Bob Monsour , ipsec@tis.com In-Reply-To: <3.0.32.19970319065713.00949100@earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 06:57 AM 3/19/97 -0800, Bob Monsour wrote: >Would someone like to suggest where to take the discussion from here? > Unfortunately, this straw vote occured over a time where my mail was hosed from multiple sources (maybe someone was out to get me ;). Compression is a must deliver for remote, dialup users. These will number in their thousands in the corporate arena. In fact, until IPsec is deployed internally in corporations, remote systems will represent the lion share of the market and the dollar volume (even with gateways costing more than ws code). If this group does not address compression head-on, someone(s) will do it and publish, at best, an informational RFC of how they did it and vendors will move down that road to compete in the market. ie the market decides. Get off the dime, people. Chrysler alone currently fields 6000 notebooks with another 1000 on order. We plan on putting IPsec into all of them 4Q97. The vendor that delivers compression will get our attention. Ford, GM, UTA, TRW, PACCAR, John Deere, etc have similar needs. We will work as a consolidated group (to an extent of course :) to get product that meets our needs. I welcome Bob's efforts. It is a careful balance of functionality and interoperability. I invite him to bring his approach to round 3 or 4 of our testing/piloting of IPsec. I'd rather it be an IPsec wg methodology. I can dance around no compression for a little while, but I've been chartered by the AIAG to deliver the goods, securely..... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Wed Mar 19 11:48:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA08121 for ipsec-outgoing; Wed, 19 Mar 1997 11:48:25 -0500 (EST) Date: Wed, 19 Mar 1997 11:50:40 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199703191650.LAA28195@earth.hpc.org> To: rgm3@chrysler.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199703191615.JAA20358@baskerville.CS.Arizona.EDU> Subject: Re: Closing out the COMPRESSION discussion Sender: owner-ipsec@ex.tis.com Precedence: bulk > Compression is a must deliver for remote, dialup users. Wonderful, just have the compression WG publish their RFC describing the protocol; I assume they'll define one for TCP streams and another that can sit over any datagram protocol. The dime that this group should rise from is inline rekeying using DH medium-term secrets. Hilarie From owner-ipsec Wed Mar 19 12:22:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA08339 for ipsec-outgoing; Wed, 19 Mar 1997 12:20:41 -0500 (EST) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199703191725.JAA00587@kebe.eng.sun.com> Subject: All this tweaking is nice, but... To: ipsec@tis.com Date: Wed, 19 Mar 1997 09:25:39 -0800 (PST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello folks in IPsec-land! I've been seeing a lot of last-minute tweaks lately on the list. As someone who Writes Code (TM), and as someone who's helped build some of the earliest versions of IPsec, I just have one question: WHY? Most of the ones I've seen recently seem extraneous (we can argue until we're blue in the face about if truncation is stronger, but the critical question is if non-truncated is BROKEN?), and others are made for reasons that don't take into account the big picture (code needed to parse variable-sized replay counters is lost in the noise compared with the HMAC calculations, so don't go whining about performance). I'll bet small sums that some of what's been popping up on IPsec is the result of some of the AIAG stuff. It's good that stuff like AIAG happens, but you guys can't forget that some of us aren't doing (or can't do) AIAG yet for _varying_ reasons. A few things to remember folks: 1.) The IP Security Architecture is EXTENSIBLE. This means if something's really broke, you can obsolete the current draft with a new one. Apart from changes derived from Bellovin's summer USENIX paper (some of which, mind you, merely involved following the spec), I haven't seen anything after those changes (Combined ESP, replay) that fixes honest-to-God BREAKAGE. Let's go with what's there, and create NEW drafts for some of these new approaches. 2.) The KISS principle. Yes, we can't leave gaping holes, but if there are no gaping holes, let's not go changing for change's sake! I'd suggest to everyone on this list a re-reading of _The Mythical Man-Month_ by Fred Brooks. And if you've never read this seminal work, for crying out loud find a copy. 3.) Let's not create a separate implementors list the way IPng did. I don't get AIAG-type mail, because I'm unable to show up for now. I'm sure I'm not the only one, though. Spec writers need to hear about implementation experience, and implementors need to hear the writers' rationale(s). 4.) We're in the risk reduction business. The only perfect security is the good ole-fashioned airgap firewall, or something else that keeps you from moving bits. (If anyone calls your network "truly secure" be afraid, be very afraid.) If we reduce the vulnerability, we're doing well. Alright alright, I'll climb down off my soapbox now. ObPlug: My updated internet drafts are in the I-D queue currently. Watch for them. -- Daniel L. McDonald - Solaris Internet Engineering || MY OPINIONS ARE NOT Mail: danmcd@eng.sun.com, danmcd@kebe.com <*> || NOT NECESSARILY SUN'S! Phone: (415) 786-6815 |"rising falling at force ten WWW: http://www.kebe.com/~danmcd | we twist the world and ride the wind" - Rush From owner-ipsec Wed Mar 19 13:01:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08737 for ipsec-outgoing; Wed, 19 Mar 1997 13:00:55 -0500 (EST) Message-Id: <3.0.1.32.19970319130501.00a79450@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 19 Mar 1997 13:05:01 -0500 To: ipsec@tis.com From: Robert Moskowitz Subject: Purpose of AIAG discussion list.... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk For those of you not interested in what is going on the AIAG list, but want to know why it exists, here is a note that I posted on it a week ago to clear this up, I hope. >Reply-To: rgm3@is.chrysler.com >X-Sender: rgm3@dilbert.is.chrysler.com >Date: Wed, 12 Mar 1997 16:57:22 -0500 >To: anx-sec@dot.netrex.net, anx-sec@dot.netrex.net, > Naganand Doraswamy >From: Robert Moskowitz >Subject: Re: developers list >Sender: owner-anx-sec@dot.netrex.net >Reply-To: anx-sec@dot.netrex.net > >At 05:02 PM 3/8/97 Time, Ran Atkinson wrote: >> >>Paul Lambert and I would like to suggest that the implementer discussions >>occur on the main IPsec list rather than on some sidebar list. This >>helps keep everyone in sync. Also, the IPsec list is not so noisy these >>days that it is an issue to have implementer discussions on the main >>list. > >The purpose of this list is to allow vendors and AIAG members to move IPsec >forward to implementation in step with the ANX schedule. To this extent, >defining what will be needed in terms of the protocols, and what is not >clear can definitely be handled on this list. > >However, when things are unclear in understanding the specs, or when >particular insights are learned here, these really have to go to the main >IPsec list. > >I also plan on keeping the main IPsec list abreast of what our requirements >- expectations - experiences are. > >As an ADMIN note, Ran has been on this list since I started it. I was very >appreciative of Steve Kent to be willing to add this list to his traffic to >gain his insights. But to all non-coders or non-auto-implementors, I ask >you to understand our purpose (get product out that interoperates) and our >schedule. > > >Robert Moskowitz >Chrysler Corporation >(810) 758-8212 > > Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Wed Mar 19 13:18:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08842 for ipsec-outgoing; Wed, 19 Mar 1997 13:18:01 -0500 (EST) Message-ID: <61CDD2C9A961CF11B6A000805FD40AA9031C76EA@RED-84-MSG.dns.microsoft.com> From: Glen Zorn To: rgm3@chrysler.com, Bob Monsour , Ran Atkinson Cc: ipsec@tis.com Subject: RE: Closing out the COMPRESSION discussion Date: Wed, 19 Mar 1997 10:03:23 -0800 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm not sure I understand your point, Bob. Surely most (if not all) dial-up users will be using PPP, which already offers compression. What am I missing? -----Original Message----- From: Robert Moskowitz [SMTP:rgm3@chrysler.com] Sent: Wednesday, March 19, 1997 8:03 AM To: Bob Monsour; Ran Atkinson Cc: Bob Monsour; ipsec@tis.com Subject: Re: Closing out the COMPRESSION discussion At 06:57 AM 3/19/97 -0800, Bob Monsour wrote: >Would someone like to suggest where to take the discussion from here? > Unfortunately, this straw vote occured over a time where my mail was hosed from multiple sources (maybe someone was out to get me ;). Compression is a must deliver for remote, dialup users. These will number in their thousands in the corporate arena. In fact, until IPsec is deployed internally in corporations, remote systems will represent the lion share of the market and the dollar volume (even with gateways costing more than ws code). If this group does not address compression head-on, someone(s) will do it and publish, at best, an informational RFC of how they did it and vendors will move down that road to compete in the market. ie the market decides. Get off the dime, people. Chrysler alone currently fields 6000 notebooks with another 1000 on order. We plan on putting IPsec into all of them 4Q97. The vendor that delivers compression will get our attention. Ford, GM, UTA, TRW, PACCAR, John Deere, etc have similar needs. We will work as a consolidated group (to an extent of course :) to get product that meets our needs. I welcome Bob's efforts. It is a careful balance of functionality and interoperability. I invite him to bring his approach to round 3 or 4 of our testing/piloting of IPsec. I'd rather it be an IPsec wg methodology. I can dance around no compression for a little while, but I've been chartered by the AIAG to deliver the goods, securely..... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Wed Mar 19 14:05:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA09269 for ipsec-outgoing; Wed, 19 Mar 1997 14:02:17 -0500 (EST) Message-Id: <3.0.1.32.19970319140514.00ab68f0@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 19 Mar 1997 14:05:14 -0500 To: Glen Zorn , Bob Monsour , Ran Atkinson From: Robert Moskowitz Subject: RE: Closing out the COMPRESSION discussion Cc: ipsec@tis.com In-Reply-To: <61CDD2C9A961CF11B6A000805FD40AA9031C76EA@RED-84-MSG.dns.mi crosoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:03 AM 3/19/97 -0800, Glen Zorn wrote: >I'm not sure I understand your point, Bob. Surely most (if not all) >dial-up users will be using PPP, which already offers compression. What >am I missing? Once you encrypt you cannot compress, or else there is something wrong with your crypto, as I understand it. Thus PPP compression would only act on the PPP and IP header stuff. No offense, Glen, but this question tends to indicate that you have missed a big part of the compression discussion. Another reason given for IPsec compression is to get a packet to fit into an IP tunnel payload. The argument against this is that MTU discovery should handle this problem. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Wed Mar 19 17:13:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA10541 for ipsec-outgoing; Wed, 19 Mar 1997 17:11:06 -0500 (EST) Message-ID: <01BC3470.1AC91AE0@Tastid.cisco.com> From: adams@cisco.com (Rob Adams) To: ipsec@tis.com ('ipsec@tis.com') Subject: RE: All this tweaking is nice, but... Date: Wed, 19 Mar 1997 14:16:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I don't know but I think we wouldn't be doing all this tweeking if the original drafts had been well thought out and the NRL "reference" pile of... code... made sense for more than just the base transforms which, lets face it, made no sense. You must agree that less than six months ago when we had a base transform that depended on changing the behaviour of MD5 and sets of documents that said "oh and key management will handle that" when key management didn't exist really, and we had drafts with material changes being introduced AFTER last call and etc. etc. etc. we were in pretty bad shape. I would argue that this process is broken and that the tweaks are necessary to produce something that is secure and that does make sense and is extensible. The drafts/RFC we have now are not really any of the above. 64 bit replay? great for alignment, bad for security/stupid to implement. key hashing by transforms based on ISAKMP attributes? what? secure maybe, extensible? what? documents to resolve documents? When is that ever right? variable length optional fields in the middle of fixed headers?? WHAT! -10. I can hear my compsci 120 prof laughing now.. I would call all of the above "honest to God BREAKAGE." A lot of us "Write Code (TM)". A lot of us write for a market that cares about quality and security. A lot of us write code that has to be maintained and costs money if it is broken. A lot of us will have to live with this pile of .. code .. for a long time in the future. We want this to work, to be secure, to be really extensible and we don't want to support broken, ill-conceived trash that we'll have to maintain forever because some customer will not upgrade. That's the difference between the NRL hack ah oh sorry, code and what we are doing. I don't think we require perfection, we just require that it makes sense and will actually achieve the goals we have for our products and our customers. Rob Adams Cisco Systems ---------- From: Dan McDonald[SMTP:Dan.McDonald@Eng.sun.com] Sent: Wednesday, March 19, 1997 9:25 AM To: ipsec@tis.com Subject: All this tweaking is nice, but... Hello folks in IPsec-land! I've been seeing a lot of last-minute tweaks lately on the list. As someone who Writes Code (TM), and as someone who's helped build some of the earliest versions of IPsec, I just have one question: WHY? Most of the ones I've seen recently seem extraneous (we can argue until we're blue in the face about if truncation is stronger, but the critical question is if non-truncated is BROKEN?), and others are made for reasons that don't take into account the big picture (code needed to parse variable-sized replay counters is lost in the noise compared with the HMAC calculations, so don't go whining about performance). I'll bet small sums that some of what's been popping up on IPsec is the result of some of the AIAG stuff. It's good that stuff like AIAG happens, but you guys can't forget that some of us aren't doing (or can't do) AIAG yet for _varying_ reasons. A few things to remember folks: 1.) The IP Security Architecture is EXTENSIBLE. This means if something's really broke, you can obsolete the current draft with a new one. Apart from changes derived from Bellovin's summer USENIX paper (some of which, mind you, merely involved following the spec), I haven't seen anything after those changes (Combined ESP, replay) that fixes honest-to-God BREAKAGE. Let's go with what's there, and create NEW drafts for some of these new approaches. 2.) The KISS principle. Yes, we can't leave gaping holes, but if there are no gaping holes, let's not go changing for change's sake! I'd suggest to everyone on this list a re-reading of _The Mythical Man-Month_ by Fred Brooks. And if you've never read this seminal work, for crying out loud find a copy. 3.) Let's not create a separate implementors list the way IPng did. I don't get AIAG-type mail, because I'm unable to show up for now. I'm sure I'm not the only one, though. Spec writers need to hear about implementation experience, and implementors need to hear the writers' rationale(s). 4.) We're in the risk reduction business. The only perfect security is the good ole-fashioned airgap firewall, or something else that keeps you from moving bits. (If anyone calls your network "truly secure" be afraid, be very afraid.) If we reduce the vulnerability, we're doing well. Alright alright, I'll climb down off my soapbox now. ObPlug: My updated internet drafts are in the I-D queue currently. Watch for them. -- Daniel L. McDonald - Solaris Internet Engineering || MY OPINIONS ARE NOT Mail: danmcd@eng.sun.com, danmcd@kebe.com <*> || NOT NECESSARILY SUN'S! Phone: (415) 786-6815 |"rising falling at force ten WWW: http://www.kebe.com/~danmcd | we twist the world and ride the wind" - Rush From owner-ipsec Wed Mar 19 18:28:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA11248 for ipsec-outgoing; Wed, 19 Mar 1997 18:26:34 -0500 (EST) Message-Id: <61CDD2C9A961CF11B6A000805FD40AA9031DB71B@RED-84-MSG.dns.microsoft.com> From: Glen Zorn To: rgm3@chrysler.com, Bob Monsour Cc: ipsec@tis.com Subject: RE: Closing out the COMPRESSION discussion Date: Wed, 19 Mar 1997 15:29:57 -0800 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:03 AM 3/19/97 -0800, Glen Zorn wrote: >I'm not sure I understand your point, Bob. Surely most (if not all) >dial-up users will be using PPP, which already offers compression. What >am I missing? Once you encrypt you cannot compress, or else there is something wrong with your crypto, as I understand it. Thus PPP compression would only act on the PPP and IP header stuff. Yes, you wouldn't get a very good compression factor at least. No offense, Glen, None taken! but this question tends to indicate that you have missed a big part of the compression discussion. That answers one question; I'll shut up an d listen for awhile. Perhaps it was just that I dropped in on the middle of the conversation, but I was puzzled as to what compression had to do w/security. Another reason given for IPsec compression is to get a packet to fit into an IP tunnel payload. The argument against this is that MTU discovery should handle this problem. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Wed Mar 19 21:04:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA12032 for ipsec-outgoing; Wed, 19 Mar 1997 21:03:30 -0500 (EST) Date: Thu, 20 Mar 97 01:57:18 GMT Standard Time From: Ran Atkinson Subject: Re: the COMPRESSION discussion To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <3.0.1.32.19970319110315.00b4ad70@dilbert.is.chrysler.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Just to be clear, I _personally_ am indifferent about compression. As co-chair, I'm very religious about following the standards process. Before we can move forward there MUST be rough consensus within the WG on how to proceed. Right now this just is not present. Sigh. The items that the IPsec WG needs to sort out are: 1) Is compression "must implement" or "optional to implement" or "outside our scope" ? If its inside our scope, then these next items also need to be sorted out: 2) What compression mechanism (not algorithm, but how to implement and at what processing layer) should be used ? 3) How to ensure that the compression mechanism can support arbitrary compression algorithms so that a new gee-whiz compression algorithm can be added modularly without changing everything. Reasonable steps towards progress might include: - Various people writing up various approaches as I-Ds and presenting these in Memphis (warning: time is short) - Discussing specifics on the IPsec list, noting which items are most important. - A clear agreement on the scope of the problem that should be addressed. - Deciding whether compression is just an ESP issue or whether it might be good to have a more generalised scheme for IP-layer compression of any IP packet (not just those packets with IPsec) Ran rja@inet.org From owner-ipsec Wed Mar 19 21:05:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA12076 for ipsec-outgoing; Wed, 19 Mar 1997 21:05:33 -0500 (EST) Date: Thu, 20 Mar 97 02:04:42 GMT Standard Time From: Ran Atkinson Subject: Re: Closing out the COMPRESSION discussion To: Hilarie Orman , rgm3@chrysler.com Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199703191650.LAA28195@earth.hpc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Wed, 19 Mar 1997 11:50:40 -0500 Hilarie Orman wrote: > The dime that this group should rise from is inline rekeying using DH > medium-term secrets. > > Hilarie ---------------End of Original Message----------------- Hilarie, I expect that Bill Sommerfeld will be publishing a revised version of inline keying with ISAKMP in the near future and I hope it will be discussed in Memphis. Bill is the document editor for that work item. Best wishes, Ran rja@inet.org From owner-ipsec Thu Mar 20 02:42:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA13657 for ipsec-outgoing; Thu, 20 Mar 1997 02:41:13 -0500 (EST) Message-Id: <3.0.32.19970319234159.009c34e0@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 19 Mar 1997 23:42:06 -0800 To: Ran Atkinson From: Bob Monsour Subject: Re: the COMPRESSION discussion Cc: PALAMBER@us.oracle.com, ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 01:57 AM 3/20/97 Time, Ran Atkinson wrote: > >Just to be clear, I _personally_ am indifferent about compression. >As co-chair, I'm very religious about following the standards process. >Before we can move forward there MUST be rough consensus within the WG >on how to proceed. Right now this just is not present. Sigh. >The items that the IPsec WG needs to sort out are: > >1) Is compression "must implement" or "optional to implement" or > "outside our scope" ? > Ran, please forgive my frustration here (and perhaps I'm miss-reading the process) but I distinctly recall Paul Lambert getting up to summarize the activity of the WG meeting (in San Jose) and saying that there appeared to be consensus that the WG should take up compression as a work item. What I find frustrating is that the recently issued minutes (I understand that they "have not been edited") state "A straw pole indicated there is no current consensus on how to proceed". Am I the only one with this recollection? I read Paul's comment as calling compression within the scope of the WG. >If its inside our scope, then these next items also need to >be sorted out: > > >2) What compression mechanism (not algorithm, but how to implement > and at what processing layer) should be used ? >3) How to ensure that the compression mechanism can support arbitrary > compression algorithms so that a new gee-whiz compression > algorithm can be added modularly without changing everything. I appreciate your desire to be "very religious about following the standards process", but what I also find frustrating is the lack of presence of the co-chairs, in a moderating role, during the lengthy discussions that have been conducted on the list; items 2 and 3 that you list above are topics that have been discussed somewhat vigorously over the last few months. Where were you? The working group guidelines call for the co-chairs to "attempt to ensure that the discussions on the list are relevant and that they converge to consensus agreements". If there was an issue of whether or not compression was "inside our scope", then I would've expected to have the question of relevance raised early in the discussion for us to carry out that debate prior to spending an awful lot of WG time and energy on the topic. Specifically, in an email I wrote on Jan 23, I said: At the December IETF meeting, the IPSEC working group consensus was to undertake compression as a work item. In the rest of that email, I recapped the San Jose discussion, reviewed the proposals made in San Jose, and requested input on some of the issues raised at the WG meeting. I understand that the decisions in the meeting are not final (nothing is), but again, I would've expected some co-chair moderation to raise the question to the WG to avoid wasting everyone's valuable time. >Reasonable steps towards progress might include: > - Various people writing up various approaches as I-Ds and > presenting these in Memphis (warning: time is short) > - Discussing specifics on the IPsec list, noting which items > are most important. > - A clear agreement on the scope of the problem that should > be addressed. > - Deciding whether compression is just an ESP issue or > whether it might be good to have a more generalised scheme > for IP-layer compression of any IP packet (not just those > packets with IPsec) In an earlier email I made a formal request for agenda time in Memphis. There will be a draft submitted by the 3/26 cutoff date. As promised earlier, I will not refer to any consensus or straw poll info during my presentation. I will defer to you to make the necessary process calls at the meeting. In closing, the reality I am seeing in the vendor community is that there WILL be a number of companies in the market with compressing IPSec implementations. In the interest of the user community, it is important that the WG strive for the goal of interoperable implementations of this capability. I hope you understand my concerns. Regards (really), -Bob From owner-ipsec Thu Mar 20 09:44:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA16496 for ipsec-outgoing; Thu, 20 Mar 1997 09:42:34 -0500 (EST) Date: Thu, 20 Mar 1997 09:45:10 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199703201445.JAA06780@earth.hpc.org> To: rja@inet.org Cc: rgm3@chrysler.com, ipsec@tis.com In-reply-to: Yourmessage Subject: Re: Closing out the COMPRESSION discussion Sender: owner-ipsec@ex.tis.com Precedence: bulk As I mentioned in San Jose, Bill Sommerfeld's version of inline keying is not at all what I mean. What I mean is carrying an identifier in the ESP header that can be hashed with a pre-established secret to produce the unique key for the packet payload. This can be done many times to achieve uni-directional rekeying before security would demand that the pre-established secret be changed. I think the distinction is inline keys vs. inline key exchanges. Hilarie From owner-ipsec Thu Mar 20 10:44:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA17060 for ipsec-outgoing; Thu, 20 Mar 1997 10:43:23 -0500 (EST) Date: Thu, 20 Mar 97 15:30:53 GMT Standard Time From: Ran Atkinson Subject: Re: the COMPRESSION discussion To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <3.0.32.19970319234159.009c34e0@earthlink.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Wed, 19 Mar 1997 23:42:06 -0800 Bob Monsour wrote: > At 01:57 AM 3/20/97 Time, Ran Atkinson wrote: > > > >Just to be clear, I _personally_ am indifferent about compression. > >As co-chair, I'm very religious about following the standards process. > >Before we can move forward there MUST be rough consensus within the WG > >on how to proceed. Right now this just is not present. Sigh. > >The items that the IPsec WG needs to sort out are: > > > >1) Is compression "must implement" or "optional to implement" or > > "outside our scope" ? > > > > Ran, please forgive my frustration here (and perhaps I'm miss-reading the > process) but I distinctly recall Paul Lambert getting up to summarize the > activity of the WG meeting (in San Jose) and saying that there appeared to > be consensus that the WG should take up compression as a work item. > ... the recently issued minutes (I understand that > they "have not been edited") state "A straw pole indicated there is no > current consensus on how to proceed". Am I the only one with this > recollection? I read Paul's comment as calling compression within the scope > of the WG. Those statements are not mutually exclusive. The fact that we are discussing compression is consistent with it being a Work Item. Not all work items lead to specifications, though most do. "How to proceed" is a broader question that encompasses the items I mentioned in my email note: mandatory or optional to implement what mechanism to use etc. (see original note) Further, frustrating though it might be, the consensus of this WG seems to be fairly fluid on several topics, including compression. I have received recent email from several different people asserting that they now believe compression to be important but out of scope for IPsec in that they believe it should be done at a higher protocol processing layer. I might or might not personally agree, but its not my personal call -- its up to the group as a whole to reach some conclusions. Those who really want to make progress on this should write up some concrete protocol specifications in the form of an I-D, put it online, present it to the WG in Memphis, and see whether the WG as a whole is comfortable with that approach. Such an I-D should try to answer the questions I've posed. Its entirely possible for this WG to reach consensus on this in Memphis if people will write some concrete things up and present them in a way that convinces most people in the WG... Ran rja@inet.org From owner-ipsec Thu Mar 20 10:53:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA17135 for ipsec-outgoing; Thu, 20 Mar 1997 10:53:29 -0500 (EST) Message-Id: <97Mar20.105913est.11651@elgreco.rnd.border.com> To: Ran Atkinson cc: ipsec@tis.com Subject: Re: the COMPRESSION discussion References: <3.0.1.32.19970319110315.00b4ad70@dilbert.is.chrysler.com> In-reply-to: Your message of "Wed, 19 Mar 1997 20:57:18 -0500". From: "C. Harald Koch" X-uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19029.858873477.1@rafael.rnd.border.com> Date: Thu, 20 Mar 1997 10:57:58 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message , Ran Atkinson writes: > > Just to be clear, I _personally_ am indifferent about compression. > As co-chair, I'm very religious about following the standards process. > Before we can move forward there MUST be rough consensus within the WG > on how to proceed. Right now this just is not present. Sigh. And this is where I'm wary of compression as part of the IPsec WG. Compression is extremely difficult to standardize, due to the number of patents on compression algorithms. Witness the PPP WG, which ran around and around on the discussion of compression for years, and where there is *still* no useful interoperable compression. It's already taken us far too long to get standards out; adding compression will only make this worse. -- Harald Koch From owner-ipsec Thu Mar 20 11:02:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA17189 for ipsec-outgoing; Thu, 20 Mar 1997 11:02:02 -0500 (EST) Date: Thu, 20 Mar 1997 10:59:15 -0500 From: "Ferdinand N. Ahlberg" Message-Id: <199703201559.KAA19229@olympus.ctron.com> To: rgm3@chrysler.com, rmonsour@earthlink.net, rja@inet.org, glennz@microsoft.com Subject: RE: Closing out the COMPRESSION discussion Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Hey now! > > I'm not sure I understand your point, Bob. Surely most (if not all) > dial-up users will be using PPP, which already offers compression. What > am I missing? > IPSec, among other things, defines encrypting packets at the network layer. PPP compression is performed at the data link layer. Compression algorithms search the data stream for patterns and then replace those patterns with smaller representations. Encryption algorithms generate outputs which are free of repetitive patterns. Therefore, compression of encryted data will have no effect. So, use of compression deserves to be defined in IPSec, because, if you encrypt at the network layer, your PPP compression will not compress the packets. In order to harmonize the two technologies, you must compress before encrypting. Ferd /////////////////////////////////////// // // // Ferdinand N. Ahlberg // // WAN Development // // Cabletron Systems, Inc. // // // // ahlberg@ctron.com // // // /////////////////////////////////////// From owner-ipsec Thu Mar 20 11:23:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA17288 for ipsec-outgoing; Thu, 20 Mar 1997 11:23:39 -0500 (EST) Date: Thu, 20 Mar 1997 08:28:44 -0800 Message-Id: <199703201628.IAA25182@gump.eng.ascend.com> From: Karl Fox To: "C. Harald Koch" Cc: Ran Atkinson , ipsec@tis.com Subject: Re: the COMPRESSION discussion In-Reply-To: <97Mar20.105913est.11651@elgreco.rnd.border.com> References: <3.0.1.32.19970319110315.00b4ad70@dilbert.is.chrysler.com> <97Mar20.105913est.11651@elgreco.rnd.border.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ipsec@ex.tis.com Precedence: bulk C. Harald Koch writes: > Compression is extremely difficult to standardize, due to the number of > patents on compression algorithms. Witness the PPP WG, which ran around and > around on the discussion of compression for years, This is true. > and where there is *still* no useful interoperable compression. This is not true. CCP is standardized, and at least two compression methods are in widespread use, being available on the majority of all PPP-speaking devices. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 From owner-ipsec Thu Mar 20 12:12:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA17580 for ipsec-outgoing; Thu, 20 Mar 1997 12:11:27 -0500 (EST) Message-Id: <199703201715.MAA00500@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: ho@earth.hpc.org (Hilarie Orman) Cc: rja@inet.org, rgm3@chrysler.com, ipsec@tis.com Subject: Re: inline keying In-Reply-To: ho's message of Thu, 20 Mar 1997 09:45:10 -0500. <199703201445.JAA06780@earth.hpc.org> Date: Thu, 20 Mar 1997 12:15:14 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk I've received relatively little feedback on the inline keying proposal; as i'm in the process of revising it (hopefully in time for the deadline next Wednesday), I'd very much like to hear what you, or anyone else, has to say. > As I mentioned in San Jose, Bill Sommerfeld's version of inline keying > is not at all what I mean. What I mean is carrying an identifier in > the ESP header that can be hashed with a pre-established secret to > produce the unique key for the packet payload. This can be done many > times to achieve uni-directional rekeying before security would demand > that the pre-established secret be changed. What you're suggesting is rekeying every packet. Putting my efficiency hat on, this could get quite expensive (potentially doubling the crypto overhead vs. fixed keys for short packets..). My proposal was (essentially) rekeying every "connection" or "flow", so that the second and subsequent packets in each direction can run at the same speed as a vanilla fixed-key SA. > I think the distinction is inline keys vs. inline key exchanges. Fair enough.. Anyone else have any comments? - Bill From owner-ipsec Thu Mar 20 12:55:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA17855 for ipsec-outgoing; Thu, 20 Mar 1997 12:54:36 -0500 (EST) Message-Id: <3.0.32.19970320095113.009c6680@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 20 Mar 1997 09:51:27 -0800 To: "C. Harald Koch" From: Bob Monsour Subject: Re: the COMPRESSION discussion Cc: Ran Atkinson , ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:57 AM 3/20/97 -0500, C. Harald Koch wrote: >Compression is extremely difficult to standardize, due to the number of >patents on compression algorithms. Witness the PPP WG, which ran around and >around on the discussion of compression for years, and where there is >*still* no useful interoperable compression. The issue that surrounded and delayed the PPP WG had to do with 2 Motorola patents, neither of which involved compression algorithms per se. One has to do with the idea of maintaining multiple compression contexts/histories over a communication link and the second had to do with a way to handle out-of-order packets and resetting the compression contexts/histores appropriately. Neither of these come into play in the proposed IPSec method for compressing. This is because no context/history is maintained from one packet to the next (unlike PPP). Perhaps someone else from the PPP world could respond with their knowledge on the subject as well. -Bob Disclaimer: I'm not a lawyer. From owner-ipsec Thu Mar 20 12:58:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA17887 for ipsec-outgoing; Thu, 20 Mar 1997 12:58:08 -0500 (EST) Message-Id: <199703201803.KAA00704@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Thu, 20 Mar 97 10:03:08 -0800 To: Ran Atkinson Subject: Re: the COMPRESSION discussion cc: ipsec@tis.com Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: <3.0.32.19970319234159.009c34e0@earthlink.net> Sender: owner-ipsec@ex.tis.com Precedence: bulk > Those who really want to make progress on this should write up > some concrete protocol specifications in the form of an I-D, > put it online, present it to the WG in Memphis, and see whether > the WG as a whole is comfortable with that approach. Such an I-D > should try to answer the questions I've posed. > I'm confused, don't we already have such documents? (draft-sabin-esp-des3-lzs-md5-00.txt and draft-sabin-lzs-payload-00.txt) -dpg From owner-ipsec Thu Mar 20 13:09:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA18000 for ipsec-outgoing; Thu, 20 Mar 1997 13:09:10 -0500 (EST) Message-Id: <199703201813.KAA00712@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Thu, 20 Mar 97 10:13:58 -0800 To: ipsec@tis.com Subject: How about a DESX transform? Reply-To: dennis.glatting@plaintalk.bellevue.wa.us Sender: owner-ipsec@ex.tis.com Precedence: bulk Is there interest for a DESX transform? Would the introduction of such a transform be counter productive at this time? -dpg From owner-ipsec Thu Mar 20 15:59:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA19234 for ipsec-outgoing; Thu, 20 Mar 1997 15:55:24 -0500 (EST) Date: Thu, 20 Mar 1997 16:00:17 -0500 (EST) From: Robert Glenn Message-Id: <199703202100.QAA26863@snad.ncsl.nist.gov> To: ipsec@tis.com Subject: New AH Transform Drafts submitted Cc: rob.glenn@nist.gov Sender: owner-ipsec@ex.tis.com Precedence: bulk I've submitted the new AH transform drafts today. They should show up at your favorite I-D place in a few days. Until then, I've made them available at: ftp://ftp.antd.nist.gov/pub/ipsec/draft-ietf-ipsec-ah-hmac-md5-96-00.txt and ftp://ftp.antd.nist.gov/pub/ipsec/draft-ietf-ipsec-ah-hmac-sha-1-96-00.txt. These are to replace RFC2085 and draft-ietf-ipsec-ah-hmac-sha-04.txt. Here are some quick diffs & potential open issues. Before commenting on this message, please first read the drafts. 1. The HMAC digest is truncated to 96 bits. 2. The Replay Prevention field is a fixed 32-bits. 3. Replay Prevention is still optional BUT, if not implemented or not in use (as specified by the SA) the field remains in the packet header but is zeroed and ignored - read the spec for more details. 4. The Replay Prevention field is an up counter that starts at 1. Actually this is kept from the previous specs. The reason I mention it, is that it differs from the ESP-DES-MD5 spec. I avoided using a negotiated counter because of the complexity it adds and I'm not convinced that starting at a fixed number weakens security. I'm open to be convinced. 5. There is a pointer to a HMAC test vectors draft (forth coming with in the next day or so) that will hopefully eliminate some of the interoperability problems seen recently. There are additional changes where we tried to make things a bit more clear. Please read the drafts and provide comments. I'll re-iterate the above in Memphis and bring up additional issues that may arise between now and then. Rob G. rob.glenn@nist.gov From owner-ipsec Thu Mar 20 16:47:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA00284 for ipsec-outgoing; Thu, 20 Mar 1997 16:35:09 -0500 (EST) Message-Id: <199703202130.QAA17141@raptor.research.att.com> To: Robert Glenn cc: ipsec@tis.com, rob.glenn@nist.gov Subject: Re: New AH Transform Drafts submitted Date: Thu, 20 Mar 1997 16:30:38 -0500 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk 4. The Replay Prevention field is an up counter that starts at 1. Act ually this is kept from the previous specs. The reason I mention it, is that it differs from the ESP-DES-MD5 spec. I avoided using a negotiated counter because of the complexity it adds and I'm not convinced that starting at a fixed number weakens security. I'm open to be convinced. My issue with the replay counter applies to ESP, not AH. I know of no weaknesses here. The only possible issue is whether or not MD5 or SHA are weaker if handed large numbers of 0-bits; I suspect not with this few. From owner-ipsec Thu Mar 20 16:47:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA00275 for ipsec-outgoing; Thu, 20 Mar 1997 16:35:01 -0500 (EST) Date: Thu, 20 Mar 97 21:15:26 GMT Standard Time From: Ran Atkinson Subject: RE: the COMPRESSION discussion To: "Ferdinand N. Ahlberg" Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199703201559.KAA19229@olympus.ctron.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Thu, 20 Mar 1997 10:59:15 -0500 "Ferdinand N. Ahlberg" wrote: > So, use of compression deserves to be defined in IPSec, because, if you > encrypt at the network layer, your PPP compression will not compress the > packets. Some have argued that it is better to define a separate per-packet compression method that can be used by IPsec but is not tied directly inside the ESP packet format. Others argue that compression should be within ESP. Either approach eliminates the issue that link-layer compression is ineffective on encrypted data. > In order to harmonize the two technologies, you must compress before > encrypting. That is an argument for optional compression but it doesn't argue for or against either of the approaches that have been proposed on this list. Ran rja@inet.org From owner-ipsec Fri Mar 21 06:59:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA04382 for ipsec-outgoing; Fri, 21 Mar 1997 06:57:41 -0500 (EST) Message-Id: <2.2.32.19970321013202.006df08c@trix.cisco.com> X-Sender: sned@trix.cisco.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Mar 1997 17:32:02 -0800 To: rmonsour@earthlink.net From: Steve Sneddon Subject: "Pillage first, then burn" - Attila the Hun Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk "Compress first, then encrypt" - Bob Monsure Bob, I have watched the IPSec mailing list debates pretty much from the sidelines so far. I am heartened by the lively debate, but disappointed by closure on key aspects of the standards effort (no slam intended against anyone). I agree with Ran - there isn't a consensus at this point. Email to the IPSec list has its place, and formal presentations have their place, but I believe you (HiFn) and I (Cisco) need to host an informal BOF-like discussion in Memphis around this topic in the hope that it can help move opinion forward. Maybe Tuesday evening would work. At that session, I propose that we discuss Cisco's results with compression in an IPSec-type environment. We have tied LZS into our client stack and are now accumulating data on what it can do for you. We should present that data to the community, even if it's in pretty raw form (which it will be!) at that time. Who knows, we may even be ready to demo a compression-enabled IPSec implementation by then (watch as five Cisco engineers slaughter me in Email for saying this...). I will also be prepared to discuss ways that Cisco can assist others with their implementations. One final point. Some people worry that working on compression now will slow down IPSec standards work. While I understand that concern, it is more than outweighed in my mind by how seriously a lack of compression would impede actual customer adoption of this technology. In fact, Cisco does not plan to release an IPSec implementation until there is a plan, which we can communicate clearly to customers, about how and when we will be doing compression in that environment. This is the result of significant customer backlash to lack of compression in our now-shipping but non-standard encryption offering. In closing, let me emphatically state my support for proper process in the IETF, and my strong desire for a standard in this important area. Thanks, Bob, for your help with this. Anybody on the IPSec list who wants to discuss this more in private is encouraged to send me private Email. \|||/ (. .) ------ooO-(_)-Ooo------------------------------------------------------------ ^^ ^^ Cisco Systems, Inc. STEVE SNEDDON .||. .||. IOS Development Director, IOS Client Tech .||||. .||||. 170 West Tasman Drive Phone: 408-527-1035 ..:||||||||:..:|||||||:.. SJ-F2 Pager: 800-365-4578 Cisco Systems Inc. San Jose, CA 95134-1706 EMAIL: sned@cisco.com ----------------------------------------------------------------------------- From owner-ipsec Fri Mar 21 07:48:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA04803 for ipsec-outgoing; Fri, 21 Mar 1997 07:48:22 -0500 (EST) Message-Id: <3.0.1.32.19970321075102.0093ee10@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 21 Mar 1997 07:51:02 -0500 To: Steve Sneddon , rmonsour@earthlink.net From: Robert Moskowitz Subject: Re: "Pillage first, then burn" - Attila the Hun Cc: ipsec@tis.com In-Reply-To: <2.2.32.19970321013202.006df08c@trix.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 05:32 PM 3/20/97 -0800, Steve Sneddon wrote: >Email to the IPSec list has its place, and formal presentations have their >place, but I believe you (HiFn) and I (Cisco) need to host an informal >BOF-like discussion in Memphis around this topic in the hope that it can >help move opinion forward. Maybe Tuesday evening would work. I hope we can fit this into the main IPsec session. I seem to think I have some IAB meeting tues night. >At that session, I propose that we discuss Cisco's results with compression >in an IPSec-type environment. We have tied LZS into our client stack and are >now accumulating data on what it can do for you. We should present that data >to the community, even if it's in pretty raw form (which it will be!) at >that time. Who knows, we may even be ready to demo a compression-enabled >IPSec implementation by then (watch as five Cisco engineers slaughter me in >Email for saying this...). I will also be prepared to discuss ways that >Cisco can assist others with their implementations. Gee do I know those 5 engineers? Aren't they already very busy next week? >One final point. Some people worry that working on compression now will slow >down IPSec standards work. While I understand that concern, it is more than >outweighed in my mind by how seriously a lack of compression would impede >actual customer adoption of this technology. In fact, Cisco does not plan to >release an IPSec implementation until there is a plan, which we can >communicate clearly to customers, about how and when we will be doing >compression in that environment. This is the result of significant customer >backlash to lack of compression in our now-shipping but non-standard >encryption offering. I can do my boarder to boarder without compression, but workstation to boarder I need it or I will get slaughtered by the whole auto community. And they use heavy wheeled methods over here... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Fri Mar 21 13:51:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA07322 for ipsec-outgoing; Fri, 21 Mar 1997 13:48:28 -0500 (EST) Date: 21 Mar 97 12:50:52 -0600 Subject: Re: "Pillage first, then burn" - Attila the Hun From: "James Hughes" To: rmonsour@earthlink.net, "Steve Sneddon" Cc: ipsec@tis.com, ken@anubis.network.com, varnis@winternet.com X-Mailer: Cyberdog/2.0b1 Mime-Version: 1.0 Message-Id: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk "Press release first, then develop" - (Name withheld by request) Again, I hesitate to answer this. I seem to see that there are people that again claim that their intentions and experiments are more valuable than product experience in a compression with encryption product. The NSC product won the Best of Show at INTEROP '95. It had compression then, and it has it now. On Thu, Mar 20, 1997 7:32 PM, Steve Sneddon wrote: > Email to the IPSec list has its place, and formal presentations have their > place, but I believe you (HiFn) and I (Cisco) need to host an informal > BOF-like discussion in Memphis around this topic in the hope that it can > help move opinion forward. Maybe Tuesday evening would work. In my heart, I know that cisco -is- the pre-eminent vendor of eveything important and we are not. NSC does have 2+ years of experience with implementing, deploying and real traffic with products that have packet level compression and encryption. This is actual experience, not conjecture. This is also true from the legal, commercial as well as the technical areas. I find that Cisco claiming the right to lead the discussions and host such a BOF to be incredulous. > This is the result of significant customer > backlash to lack of compression in our now-shipping but non-standard > encryption offering. > In fact, Cisco does not plan to > release an IPSec implementation until there is a plan I personally find this kind of grandstanding abhorrent. To claim the high ground in the compression discussion because their customers see this as cisco problem is (in my mind) the same kind of paper tiger announcements that their encryption program did 2 years ago when several vendors were trying to make a living with existing products built on forethough, cisco was trying to freeze the market with press releases so they could play catch up. I will (again) be happy to supply real results in providing a combined compressed, replay prevented, authentic, integrity and privacy transform (as I did to the IPSEC working group in 1994 in San Jose). jim http://www.network.com/~hughes From owner-ipsec Fri Mar 21 14:04:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA07444 for ipsec-outgoing; Fri, 21 Mar 1997 14:03:32 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Mar 1997 14:10:11 -0500 To: ipsec@tis.com From: Stephen Kent Subject: Proposed changes to ESP (andf a little AH too) Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, In working on revisions to the AH and ESP specs, we've noticed that there is an opportunity to make a change to the ESP format and processing that would simplify implementations, introduce greater consistency between AH and ESP, and offer greater protection against denial of servioce attacks. However, in setting out to revise the ESP spec, the intent was NOT to make any changes to the format (for backward compatability) and hence I am somewhat reluctant to prose such changes at this point in time. Nonetheless, I ask the WG to consider these proposed changes relative to the benefits noted above, and balance them against the cost to implementors. ESP transforms that include an anti-replay counter place this counter at the begining of the encrypted portion of the ESP payload. This motivates negotiating a random starting value for the counter (to minimize known plaintext attacks) and it creates the requirement for the AR window mechanism to deal with modular arithmetic, since the counter may wrap around the 32 bit space legitimately. Note that for AH, recent I-Ds defin ethe counter value to begin at 1, which makes life much easier. I propose to move the counter value out of the encrypted portion of the payload (it would appear immediately after the SPI), and to define it to begin at 1. This would simplify counter and counter window management and make it uniform with AH in this regard. It also allows for very fast rejection of replays by a receiver. After matching an inbound packet to an SA (using the SPI) the counter value can be checked, prior to any crypto processing. Moving the counter to this location causes the IV (if present) to appear immediately before the encrypted portion of the payload, and to be aligned on an 8-byte boundary. This offers potential (though probably minor) performance improvements for receivers, since crypto that uses explicit IVs tend to view it as an immdeiate prefix for the ciphertext. Now for a bigger change! I suggest that we reverse the order of encryption and authentication processing, when both are employed. Now, authentication processing occurs first, then encryption. This means that a receiver must decrypt then autehnticate. While most systems I have seen in the past have adopted this strategy, we are now more concerned with denial of service attacks. A likely common use of ESP is to create VPNs thorugh IPSEC implementations in security gateways. If we reverse the order of processing, then a secruity gateway can validate the integrity and authenticity of a packet befor edecrypting it, thus rejecting bogus packets faster (about twice as fast, in many instances), than if we had to decrypt then authenticate. Combined with the psoposed positional change for the counter (suggested above), we now have an ability to reject duplicate or spurious packets very quickly, providing better defense against DoS attacks. One final note re ESP formats and processing: I-Ds discussing anti-replay require support of a window size of 1, which implies strict sequencing of packets. I'd like to remove this requirement. In fact, I'd like to suggest that supporting a window size of 1 is inappropriate. The IP layer does NOT guarantee ordered delivery and by imposing strict sequencing via IPSEC we are violating a fundamental characteristic of the IP layer. Note that such sequencing could have adverse affects on TCP connections (ofrcing unnecessary retransmission), merely because of packets arrived at a security gateway out of order, due to no malicious actions. The motivation for the counter and window mechanaims was to protect against replays, not to enforce strict sequencing at the IP layer. Please respond to these proposed changes. We're submitting revised versions of AH and ESP, designed to reduce the proliferation of distinct transform documents, to meet the 3/36 cutoff. We'll put the changes I noted above in these I-Ds, but if the WG does not endorse some or all of these changes, we will quickly revise the documents and re-issue them. Presentations on these changes, and on other issues that we've encountered in the course of revising the architecture document, will be made in Memphis. I also will be sending out a message on the architecture issues next week, providing fodder for discussion prior to Memphis. The revised architecture I-D will not be ready for Memphis, because of the many issues that we want to get Wg feedback on, and because we are re-writing the document from scratch to better articulate these and other issues. Thanks in advance for your carefuyl reading and feedback, Steve From owner-ipsec Fri Mar 21 15:20:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA08035 for ipsec-outgoing; Fri, 21 Mar 1997 15:17:56 -0500 (EST) Message-Id: <3.0.32.19970321122157.00919680@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 21 Mar 1997 12:21:59 -0800 To: Stephen Kent From: Bob Monsour Subject: Re: Proposed changes to ESP (andf a little AH too) Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 02:10 PM 3/21/97 -0500, Stephen Kent wrote: > Now for a bigger change! I suggest that we reverse the order of >encryption and authentication processing, when both are employed. Now, >authentication processing occurs first, then encryption. This means that a >receiver must decrypt then autehnticate. Steve, I understand the rationale, but want to make sure I understand exactly what you are proposing. Are you saying that in ESP, the sender would encrypt the payload and then calculate the MAC over the encrypted payload? -Bob From owner-ipsec Fri Mar 21 16:05:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA08304 for ipsec-outgoing; Fri, 21 Mar 1997 16:04:19 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.32.19970321122157.00919680@earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Mar 1997 16:08:36 -0500 To: Bob Monsour From: Stephen Kent Subject: Re: Proposed changes to ESP (andf a little AH too) Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bob, Yes, that is exactly what I am saying. If both encryption and authentication/integrity are selected as services, apply the encryption algorithm first, then the auth/integrity algorithm (to the ciphertext). Steve From owner-ipsec Fri Mar 21 16:05:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA08303 for ipsec-outgoing; Fri, 21 Mar 1997 16:04:19 -0500 (EST) Message-Id: <199703212108.QAA01317@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: Bob Monsour Cc: Stephen Kent , ipsec@tis.com Subject: Re: Proposed changes to ESP (andf a little AH too) In-Reply-To: rmonsour's message of Fri, 21 Mar 1997 12:21:59 -0800. <3.0.32.19970321122157.00919680@earthlink.net> Date: Fri, 21 Mar 1997 16:08:22 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > I understand the rationale, but want to make sure I understand exactly what > you are proposing. Are you saying that in ESP, the sender would encrypt the > payload and then calculate the MAC over the encrypted payload? Normally I tend to like things which improve performance, but I don't really like this proposal, for robustness reasons; it allows errors in encryption or decryption to go undetected, while doing the MAC over the plaintext provides better assurance that the data was decrypted correctly. Consider the case where the encryption key gets smashed but the authentication key is intact .. you get authentic gibberish out of the transform instead of a hard indication that something's out of synch between the endpoints. - Bill From owner-ipsec Fri Mar 21 16:09:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA08339 for ipsec-outgoing; Fri, 21 Mar 1997 16:07:50 -0500 (EST) Date: Fri, 21 Mar 1997 16:12:11 -0500 Message-Id: <9703212112.AA20804@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Stephen Kent Cc: ipsec@tis.com In-Reply-To: Stephen Kent's message of Fri, 21 Mar 1997 14:10:11 -0500, Subject: Re: Proposed changes to ESP (andf a little AH too) Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Fri, 21 Mar 1997 14:10:11 -0500 From: Stephen Kent Now for a bigger change! I suggest that we reverse the order of encryption and authentication processing, when both are employed. Now, authentication processing occurs first, then encryption. This means that a receiver must decrypt then autehnticate. While most systems I have seen in the past have adopted this strategy, we are now more concerned with denial of service attacks. Hmm... there's a definite tradeoff here between the trying to prevent denial of service attacks, versus the potential traffic analysis that this allows, at least in some cases. In the case of using ESP to create VPN's through security gateways, the threat of traffic analysis doesn't really apply, since the authenticated destination will always be the other security gateway. Indeed, the traffic analysis threat isn't important if we're doing host keying for the same reason --- the low level, unauthenticated address allows for traffic analysis anyway. The only place where traffic analysis would matter would be if we did user-based keying, and we have multiple users using the same host, in a time-sharing fashion. I believe this is not going to be a likely use of IPSEC, and so I agree with Steve's recommendation. If there is any disagreement on this point, it's likely going to be because people believe that there will be a large amount of usage of both (a) user-based keying, and (b) time-sharing machines. While I could believe (a), I have trouble believing (b). - Ted From owner-ipsec Fri Mar 21 16:34:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA08518 for ipsec-outgoing; Fri, 21 Mar 1997 16:30:58 -0500 (EST) Date: Fri, 21 Mar 1997 16:33:15 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199703212133.QAA01890@earth.hpc.org> To: sommerfeld@apollo.hp.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199703201733.KAA02818@baskerville.CS.Arizona.EDU> Subject: Re: inline keying Sender: owner-ipsec@ex.tis.com Precedence: bulk > What you're suggesting is rekeying every packet. Not at all. If the "key hash index" doesn't change, then the key doesn't change. You can keep a small (2 or 3) table of most recently used derived keys to avoid having to recompute. Hilarie From owner-ipsec Fri Mar 21 16:55:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA08646 for ipsec-outgoing; Fri, 21 Mar 1997 16:50:07 -0500 (EST) Message-Id: <199703212154.QAA01422@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: "Theodore Y. Ts'o" Cc: Stephen Kent , ipsec@tis.com Subject: Re: Proposed changes to ESP (andf a little AH too) In-Reply-To: tytso's message of Fri, 21 Mar 1997 16:12:11 -0500. <9703212112.AA20804@dcl.MIT.EDU> Date: Fri, 21 Mar 1997 16:54:09 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > If there is any disagreement on this point, it's likely going to be > because people believe that there will be a large amount of usage of > both (a) user-based keying, and (b) time-sharing machines. While I > could believe (a), I have trouble believing (b). traditional time-sharing is indeed fading, but I think there are a number of important services with similar characteristics: - "virtual web hosting" (many web sites from different companies on one server). - application gateways/proxies (going outbound through a firewall). - multiple-layer applications (with a client, a frontend server, and a backend database). - Bill From owner-ipsec Fri Mar 21 16:56:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA08629 for ipsec-outgoing; Fri, 21 Mar 1997 16:48:34 -0500 (EST) Hops: 0 Host: tis.com. Posted-Date: Fri, 21 Mar 1997 23:49:47 -0200 (GMT) Message-Id: <199703212153.XAA26081@del.tla.org> X-Mailer: exmh version 1.6.2 7/18/95 To: ipsec@tis.com Subject: Re: Proposed changes to ESP (andf a little AH too) In-reply-to: Your message of "Fri, 21 Mar 1997 14:10:11 EST." Reply-To: ji@hol.gr Organization: La maison qui rend fou. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Mar 1997 23:52:56 +0200 From: John Ioannidis Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm all in favour of doing the encryption first and the authentication after, so that on receipt we can authenticate before we receive, but wasn't there some cryptographic argument against that sort of thing? Or was it decided back when we only had the RFC 182* transforms that in the case of cascaded transforms, we should encapsulate first with AH-MD5 and then with DES-ESP, and that carried over into the combined ESP transform? Or could it even be a carry-over back from the swIPe days (which also encrypted the authenticated packet)? /ji From owner-ipsec Fri Mar 21 17:12:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA08785 for ipsec-outgoing; Fri, 21 Mar 1997 17:10:13 -0500 (EST) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199703212215.OAA22300@kebe.eng.sun.com> Subject: Re: Proposed changes to ESP (andf a little AH too) To: kent@bbn.com (Stephen Kent) Date: Fri, 21 Mar 1997 14:15:23 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: from "Stephen Kent" at Mar 21, 97 02:10:11 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 > In working on revisions to the AH and ESP specs, we've noticed that Ummm, I've a quick question. Who are, "we"? I thought you (singular) were rewhacking these drafts. Are there others we (the good folks in IPsec-land) do not currently know? > there is an opportunity to make a change to the ESP format and processing > that would simplify implementations, introduce greater consistency between > AH and ESP, and offer greater protection against denial of servioce > attacks. However, in setting out to revise the ESP spec, the intent was > NOT to make any changes to the format (for backward compatability) and > hence I am somewhat reluctant to prose such changes at this point in time. Good points on the cleanup, the backward compatibility, and the implication that there is a tradeoff between the two. > Nonetheless, I ask the WG to consider these proposed changes relative to > the benefits noted above, and balance them against the cost to > implementors. My first and foremost concern is that we don't hold up this IPsec specification train any longer. We need to stop the target from moving as much as it is. Some of us have enough implementation headaches w/o changing specs. After that urgent concern, the question becomes: Is improvement worth the time and pain

that it'll take to implement said improvement? Is: >> X

It seems we have quite a few working systems already. So while time might be relatively small, pain might be high because things might be deployed already. Enough philosophy, I got shredded for that once already. ;) > I propose to move the counter value out of the encrypted portion of the > payload (it would appear immediately after the SPI), and to define it to > begin at 1. This would simplify counter and counter window management and > make it uniform with AH in this regard. It also allows for very fast > rejection of replays by a receiver. After matching an inbound packet to an > SA (using the SPI) the counter value can be checked, prior to any crypto > processing. It _seems_ very rational. How much replay-enabled code do we have out there? I personally haven't approached replay protection yet, and this seems easy enough to build. OTOH, I can't speak for my fellow implementors. Also, consider this potential attack when taking your "It also allows for very fast rejection..." sentence into account: I'm receiving ESP packets. I get packets #1, #2, and #3 from the actual source. Now assume active attacker Mallory injects an ESP packet with #4 into the flow. My "quick reject" algorithm accepts Mallory's #4, while rejecting the geniune #4 that arrives while I'm attempting to decrypt Mallory's #4. (Remember folks, some of us live in a multi-threaded, multi-processing world.) Granted, this is a denial-of-service attack, and as your paper with Voidoc (sp.?) points out, you can't shut down all denial-of-service attacks. My question is, does this attack exist with the previous method of implementing replay counters? > Now for a bigger change! I suggest that we reverse the order of > encryption and authentication processing, when both are employed. This > means that a receiver must decrypt then autehnticate. While most systems I > have seen in the past have adopted this strategy, we are now more concerned > with denial of service attacks. A likely common use of ESP is to create > VPNs thorugh IPSEC implementations in security gateways. If we reverse the > order of processing, then a secruity gateway can validate the integrity and > authenticity of a packet befor edecrypting it, thus rejecting bogus packets > faster (about twice as fast, in many instances), than if we had to decrypt > then authenticate. Combined with the psoposed positional change for the > counter (suggested above), we now have an ability to reject duplicate or > spurious packets very quickly, providing better defense against DoS > attacks. Ahhhhh, so _THAT's_ how you solve my problem mentioned above. My "quick reject" algorithm doesn't reject until auth passes/fails. Let me reiterate that this seems rational, and that as a fresh-from-scratch implementor I can build this. Let me also reiterate that there is running code out there now (I'd like to know how widely deployed, actually. It could be useful data.), and it may be not operationally painless. > One final note re ESP formats and processing: I-Ds discussing > anti-replay require support of a window size of 1, which implies strict > sequencing of packets. I'd like to remove this requirement. At the risk of sounding like a parrot, it's a nice idea, but will it break anyone's back too much? In this case, however, it really seems like it's not difficult to achieve. Replay window size is negotiated in Key mgmt., so you can just have key mgmt. reject such window replay window sizes. > We're submitting revised versions of AH and ESP, designed to reduce > the proliferation of distinct transform documents, to meet the 3/36 cutoff. That's 3/26, and while it may reduce the number of transform documents, will it reduce the number of transforms? > Presentations on these changes, and on other issues that we've encountered > in the course of revising the architecture document, will be made in > Memphis. I also will be sending out a message on the architecture issues > next week, providing fodder for discussion prior to Memphis. The revised > architecture I-D will not be ready for Memphis, because of the many issues > that we want to get Wg feedback on, and because we are re-writing the > document from scratch to better articulate these and other issues. Again, the issue of transforms vs. algorithm vectors is foremost in my head. I've envisioned an IPsec module (AH or ESP) doing as much common work as possible and only farming out the algorithm-specific stuff. With "transforms" it's not clear to me that you can farm out as little. Hard to say, and I do live in a different kernel-internals world than other implementors. I'd like resolution on that issue. Is my unit of difference a transform, or (algorithm + option) combinations? > Thanks in advance for your carefuyl reading and feedback, Hope this helps! -- Daniel L. McDonald - Solaris Internet Engineering || MY OPINIONS ARE NOT Mail: danmcd@eng.sun.com, danmcd@kebe.com <*> || NOT NECESSARILY SUN'S! Phone: (415) 786-6815 |"rising falling at force ten WWW: http://www.kebe.com/~danmcd | we twist the world and ride the wind" - Rush From owner-ipsec Fri Mar 21 17:19:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA08847 for ipsec-outgoing; Fri, 21 Mar 1997 17:18:19 -0500 (EST) Message-Id: <199703212221.RAA03006@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: ji@hol.gr cc: ipsec@tis.com Subject: Re: Proposed changes to ESP (andf a little AH too) In-reply-to: Your message of "Fri, 21 Mar 1997 23:52:56 +0200." <199703212153.XAA26081@del.tla.org> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 21 Mar 1997 17:21:52 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk John Ioannidis writes: > I'm all in favour of doing the encryption first and the > authentication after, so that on receipt we can authenticate before > we receive, but wasn't there some cryptographic argument against > that sort of thing? Or was it decided back when we only had the RFC > 182* transforms that in the case of cascaded transforms, we should > encapsulate first with AH-MD5 and then with DES-ESP, and that > carried over into the combined ESP transform? Back when I was still involved in the drafting of these things (long ago) I kept asking for input on the cryptographic and other desiderata for picking one or the other. I got very little feedback. I don't think the decisions was made consciously. The topic deserves a full scale discussion... Perry From owner-ipsec Fri Mar 21 18:31:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA09367 for ipsec-outgoing; Fri, 21 Mar 1997 18:29:36 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <9703212112.AA20804@dcl.MIT.EDU> References: Stephen Kent's message of Fri, 21 Mar 1997 14:10:11 -0500, Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Mar 1997 18:23:44 -0500 To: "Theodore Y. Ts'o" From: Stephen Kent Subject: Re: Proposed changes to ESP (andf a little AH too) Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Ted, Even for transport mode ESP, the proposed swap of fields only exposes the packet counters, nothing else that was not expose before. The SPIs are equally visible in both cases, as are the soure and destination addresses and the IP packet IDs. Together, these pieces of data provide me with enough info to do a good job of TA, exclusive of the counter info. So, I'm not sure that I understand why you feel that the exposure of the packet counters represents much of an aid to traffic analysis. Steve From owner-ipsec Fri Mar 21 18:32:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA09387 for ipsec-outgoing; Fri, 21 Mar 1997 18:31:06 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Mar 1997 18:26:41 -0500 To: Bill Sommerfeld From: Stephen Kent Subject: Re: Proposed changes to ESP (andf a little AH too) Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, You are right that an error that occurs during decryption will not be detected by this reversed ordering of the operations. However, the purpose of the authentication/integrity service in IPSEC is to detect malicious modification of the data, not to protect against errors that might occur during protocol processing within IPSEC. Such errors copuld also occur after both operations were completed, irrespective of the order of processing, and thus would be undetected by the IPSEC module. Yes, an encryption key mismatch would not be detected under the proposed processing order, but I expect the encryption and authentication keys for ESP will be derrived algorithmically from a common source, e.g., as described in Jim Hughes I-D. In such cases, it would be unlikely for the sort of error you describe to occur. I admit there is a greater chance of this for manually configured keys, but since this would trash all incoming traffic over the Sa in question, this should be an easy error to track down. Steve From owner-ipsec Fri Mar 21 18:51:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA09476 for ipsec-outgoing; Fri, 21 Mar 1997 18:49:43 -0500 (EST) Message-ID: <33331FCD.2781@cs.umass.edu> Date: Fri, 21 Mar 1997 18:54:53 -0500 From: Lewis McCarthy Organization: Theoretical Computer Science Group, UMass-Amherst, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha) MIME-Version: 1.0 To: IPsec Mailing List Subject: Re: Proposed changes to ESP (andf a little AH too) References: <199703212108.QAA01317@thunk.ch.apollo.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill Sommerfeld writes: [re: ciphertext = MAC(encrypt(plaintext))] > Normally I tend to like things which improve performance, but I don't > really like this proposal, for robustness reasons; it allows errors in > encryption or decryption to go undetected, while doing the MAC over > the plaintext provides better assurance that the data was decrypted > correctly. The optional preliminary "sanity check" of the decrypted replay counter value (in e.g. draft-...-esp-3des-md5-00) still could be used to detect most encryption/decryption errors, provided the counter remains inside the encrypted portion and randomly initialized. This would represent an intermediate approach between the current method and the revised one proposed by Steve K. (et al. ?). Fake packets could be detected relatively quickly, as per Steve, but replays would still take longer to notice, as per the status quo. Presumably the sanity check would change from optional to required or recommended. -Lewis From owner-ipsec Fri Mar 21 18:55:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA09521 for ipsec-outgoing; Fri, 21 Mar 1997 18:53:44 -0500 (EST) Date: Fri, 21 Mar 1997 18:58:55 -0500 Message-Id: <9703212358.AA20912@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Stephen Kent Cc: "Theodore Y. Ts'o" , ipsec@tis.com In-Reply-To: Stephen Kent's message of Fri, 21 Mar 1997 18:23:44 -0500, Subject: Re: Proposed changes to ESP (andf a little AH too) Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, My mistake. I had assumed that the AH SPI was encrypted, and was therefore not visible. It sounds like I was mistaken. - Ted From owner-ipsec Fri Mar 21 19:12:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA09598 for ipsec-outgoing; Fri, 21 Mar 1997 19:10:48 -0500 (EST) Message-ID: <333324BE.794B@cs.umass.edu> Date: Fri, 21 Mar 1997 19:15:58 -0500 From: Lewis McCarthy Organization: Theoretical Computer Science Group, UMass-Amherst, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha) MIME-Version: 1.0 To: IPsec Mailing List Subject: Re: replay window size (Re: Proposed changes to ESP (andf a little AH too)) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen Kent writes: > One final note re ESP formats and processing: I-Ds discussing > anti-replay require support of a window size of 1, which implies strict > sequencing of packets. I'd like to remove this requirement. In fact, I'd > like to suggest that supporting a window size of 1 is inappropriate. Do you have a recommendation for the replacement mandatory-to-implement window size, instead of 1? To minimize disruption, we might upgrade size=32 from recommended to mandatory-to-implement. -Lewis From owner-ipsec Fri Mar 21 21:44:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA10289 for ipsec-outgoing; Fri, 21 Mar 1997 21:42:09 -0500 (EST) Date: Sat, 22 Mar 97 02:38:59 GMT Standard Time From: Ran Atkinson Subject: Re: "Pillage first, then burn" - Attila the Hun To: Steve Sneddon Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <2.2.32.19970321013202.006df08c@trix.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, If you are interested in working within the process, constructive steps towards consensus would include: -- NOT holding a separate meeting. -- writing up cisco's proposal for compression with IPsec as an I-D and submitting it before the I-D cutoff before Memphis. -- presenting that specific proposal to the IPsec WG in the usual IPsec meeting so that everyone can consider it openly (I also anticipate other compression proposals to be presented in the IPsec WG meetings). For item 3, you'd need to send email to Paul Lambert (copy to me) asking for agenda time, providing a topic, and giving a presentation estimate so Paul can schedule accordingly (Paul mostly takes care of the meetings :-). Best wishes, Ran rja@inet.org From owner-ipsec Sat Mar 22 10:17:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA13406 for ipsec-outgoing; Sat, 22 Mar 1997 10:13:22 -0500 (EST) Message-Id: <199703221517.KAA26648@amaterasu.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: Proposed changes to ESP (andf a little AH too) In-reply-to: Your message of "Fri, 21 Mar 1997 14:10:11 EST." Date: Sat, 22 Mar 1997 10:17:41 -0500 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Stephen" == Stephen Kent writes: Stephen> ESP transforms that include an anti-replay counter Stephen> place this counter at the begining of the encrypted Stephen> portion of the ESP payload. This motivates negotiating a Stephen> random starting value for the counter (to minimize known Stephen> plaintext attacks) and it creates the requirement for the Stephen> AR window mechanism to deal with modular arithmetic, Stephen> since the counter may wrap around the 32 bit space Stephen> legitimately. Note that for AH, recent I-Ds defin ethe Stephen> counter value to begin at 1, which makes life much Stephen> easier. I propose to move the counter value out of the Stephen> encrypted portion of the payload (it would appear Stephen> immediately after the SPI), and to define it to begin at Forgive me for not being a cryptographer: but isn't the SHA+AH+reply draft flawed in not including the replay counter in the authenticated data? It seems that the ESP anti-reply counter is properly placed to me. :!mcr!: | Network security consulting and Michael Richardson | contract programming WWW: mcr@sandelman.ottawa.on.ca. PGP key available. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBMzP4DqZpLyXYhL+BAQGyzQL/XLrmjbQWECxOeIeA0E81zfr3qYXLPPhF A78qwqBgXeX69huwMqmYnGQORe1riuP1sw6X5mVhzjf3qMxKNDeZtLXboB+R+jj3 SBcnVWMQpXVCaEKzbcZ15nG2+7WDEyI5 =WS+q -----END PGP SIGNATURE----- From owner-ipsec Sat Mar 22 11:40:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA13740 for ipsec-outgoing; Sat, 22 Mar 1997 11:38:23 -0500 (EST) Message-Id: <2.2.32.19970322165101.00b92a24@mailserv-H.ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 22 Mar 1997 11:51:01 -0500 To: Stephen Kent From: Naganand Doraswamy Subject: Re: Proposed changes to ESP (andf a little AH too) Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, I like your idea of starting the replay counter with 1. I think we should adopt it. With respect to doing authentication first and then encryption, in terms of implementation it is not a very big change. I am not a cryptographer but it looks like the processing involed with bad packets is lesser in the scheme you are proposing. I dont know of vendor who has a product out in the market supporting the combined transform. So if we decide to do this, this HAS to be decided at Memphis. Many of us are almost ready to release products in the next 3-4 months timeframe and once we have products out there, it becomes a real pain if there is a fundamental change in the transform. I will support this provided we can reach a decision in Memphis. Regarding the window size, I think it is upto the implementation. I have always seen window size as something that should not be negoatiated and is entirely upto the receiver to decide the size. If the receiver chooses a window size of 1, they in all probability they may drop quite a few packets. --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) From owner-ipsec Sat Mar 22 14:44:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA14480 for ipsec-outgoing; Sat, 22 Mar 1997 14:41:28 -0500 (EST) Message-Id: <3.0.16.19970322144254.1d1721aa@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Sat, 22 Mar 1997 14:46:55 -0500 To: ipsec@tis.com From: Rodney Thayer Subject: Who is ELVIS? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk This is not a joke. Sorry but I couldn't resist that subject line, as I stare at my Memphis IETF Hotel reservation, where the price goes UP for Saturday night (to $219) apparently due to tourists who come into town to see Graceland. On the IPsec survey I see two implementations I don't have new or old entries for. These are listed in the section where people report what other implementations they have interoperated with. One is "Elvis" and one is "SOS". What are these? -------- Rodney Thayer PGP Fingerprint: BB1B6428 409129AC 076B9DE1 4C250DD8 From owner-ipsec Sat Mar 22 14:53:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA14507 for ipsec-outgoing; Sat, 22 Mar 1997 14:50:59 -0500 (EST) Message-Id: <1.5.4.16.19970322195558.0bf7ea44@world.std.com> X-Sender: dpj@world.std.com X-Mailer: Windows Eudora Light Version 1.5.4 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 22 Mar 1997 14:55:58 -0500 To: wdmaugh@tycho.ncsc.mil, mss@tycho.ncsc.mil, sjt@epoch.ncsc.mil, mjs@terisa.com From: "David P. Jablon" Subject: Re: Last Call: The resolution of ISAKMP with Oakley to Proposed Standard Cc: ipsec@tis.com, iesg@ietf.org Sender: owner-ipsec@ex.tis.com Precedence: bulk Douglas, Mark, Jeff, and Mark, In draft-ietf-ipsec-isakmp-07.txt, there is some some seriously misleading information in the initial discussion of strong and weak authentication. I've included a reworded paragraph that corrects this problem. Here's the offending paragraph: | 1.5 Authentication | | A very important step in establishing secure network communications is au- | thentication of the entity at the other end of the communication. Many | authentication mechanisms are available. Authentication mechanisms fall | into two catagories of strength - weak and strong. | [So far so good, except for "categories"] Passwords are an ex- | ample of a mechanism that provides weak authentication. ... This is wrong. Passwords are not a mechanism. They're just a factor in establishing identity, like stored secret keys, private keys, fingerprints, or faces. Strong password protocols exist, and passwords are important for strong network authentication. Yes, many bad ways to use passwords have been implemented and deployed. Yes, there's a lot of misinformation about passwords out there. But let's not propagate more of it. | ... The reason pass- | words are considered weak is the fact that most users pick passwords that | are easy to guess and when used over an unprotected network are easily | read by network sniffers. ... This is poorly worded. If you're talking about off-line dictionary attack on the sniffed messages, strong password methods are immune to this. There are also good ways to generate large-enough (for strong methods) passwords with deterministic entropy that are easily memorized, and for preventing on-line guessing attacks. Sending clear-text passwords or keys is a weak mechanism. Sending passwords or keys in easily decrypted form is weak. Sending small passwords in a one-way hashed form that permits eavesdropper dictionary attack is weak. Password-authenticated key exchange is strong, and there are at least three ways to do this. They are all as strong as the more commonly known digital signature approaches, when properly used, and can provide added benefits in many applications, due to decreased need for stored keys or certificates. As I understand ISAKMP, passwords aren't suitable here mainly because users are not actively involved in the authentication process. So the keys have to be stored anyway, and thus there is no good reason not to use *large* keys. This makes your condemnation of password-based mechanisms even more inappropriate. Here's a suggested rewording of the paragraph: | 1.5 Authentication | | A very important step in establishing secure network communications is au- | thentication of the entity at the other end of the communication. Many | authentication mechanisms are available. Authentication mechanisms fall | into two categories of strength - weak and strong. | Sending clear-text keys over a network is weak, | due to the threat of reading them with a network sniffer. | Sending one-way hashed poorly-chosen keys with low-entropy is | also weak, due to the added threat of brute-force guessing | attack on the sniffed messages. Digital signatures [... etc.] Thanks. -- David > The IESG has received a request from the IP Security Protocol Working > Group to consider the following Internet-Drafts for the status of > Proposed Standard: > > o The resolution of ISAKMP with Oakley > > o Internet Security Association and Key Management Protocol (ISAKMP) > > o The Internet IP Security Domain of Interpretation for ISAKMP > > > 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 March 28, 1997 > >Files can be obtained via ftp://ds.internic.net/internet-drafts/ ------------------------------------ David P. Jablon Integrity Sciences, Inc. Tel: +1 508 898 9024 http://world.std.com/~dpj/ E-mail: dpj@world.std.com From owner-ipsec Sat Mar 22 15:12:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA14609 for ipsec-outgoing; Sat, 22 Mar 1997 15:10:00 -0500 (EST) Message-Id: <199703222014.MAA24591@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Rodney Thayer Cc: ipsec@tis.com Subject: Re: Who is ELVIS? In-Reply-To: Your message of "Sat, 22 Mar 1997 14:46:55 EST." <3.0.16.19970322144254.1d1721aa@pop3.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 22 Mar 1997 12:14:52 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Elvis not only left the building, he left the country. You can visit him at http://www.elvis.ru (it helps if you have KOI-8). > On the IPsec survey I see two implementations I don't have new or old > entries for. These are listed in the section where people report what > other implementations they have interoperated with. One is "Elvis" and one > is "SOS". > > What are these? Elvis is a SKIP implementation from Russia. Dan. From owner-ipsec Sat Mar 22 15:24:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA14661 for ipsec-outgoing; Sat, 22 Mar 1997 15:20:02 -0500 (EST) Message-Id: <3.0.16.19970322152445.2a07148e@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Sat, 22 Mar 1997 15:25:16 -0500 To: ipsec@tis.com From: Rodney Thayer Subject: IPsec Survey Results, March 1997 [rev 1] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I have gathered the survey results at this URL: . Thanks to FTP Software for hosting this. Please check for errors. There are 28 implementations listed. I'll update this periodically as I get more responses. -------- Rodney Thayer PGP Fingerprint: BB1B6428 409129AC 076B9DE1 4C250DD8 From owner-ipsec Sat Mar 22 18:11:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA15417 for ipsec-outgoing; Sat, 22 Mar 1997 18:02:44 -0500 (EST) Message-Id: <199703222307.PAA24653@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Rodney Thayer Cc: ipsec@tis.com Subject: Re: IPsec Survey Results, March 1997 [rev 1] In-Reply-To: Your message of "Sat, 22 Mar 1997 15:25:16 EST." <3.0.16.19970322152445.2a07148e@pop3.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 22 Mar 1997 15:07:54 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Rodney, Please update ftp://research.ftp.com/pub/ipsec/results.htm for the cisco IOS entry to the following: Name of Implementation: cisco IOS (TM) Organisation: cisco Systems Which IP versions are supported: IPv4 & IPv6 in progress Implemented Features: AH (RFC-1825,1826): yes ESP (RFC-1825,1827): yes AH MD5 (RFC-1828): yes ESP DES (RFC-1829): yes Other implemented AH transforms: AH-HMAC-MD5 & AH-HMAC-SHA Other implemented ESP transforms: ESP-DES-MD5-Replay Key Management: ISAKMP+Oakley (v6 and v2, v7 and v3 in progress) Platforms: cisco Lineage of IPsec Code: cisco Systems Lineage of Key Mgmt Code: cisco Systems Location of Source Code: proprietary Point of Contact: Cheryl Madson > Thanks to FTP Software for hosting this. Yes, thanks! Dan. From owner-ipsec Sat Mar 22 19:08:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA15660 for ipsec-outgoing; Sat, 22 Mar 1997 19:03:52 -0500 (EST) Hops: 0 Host: sabletech.com. Posted-Date: Sun, 23 Mar 1997 02:05:13 -0200 (GMT) Message-Id: <199703230008.CAA08137@del.tla.org> X-Mailer: exmh version 1.6.2 7/18/95 To: Rodney Thayer Cc: ipsec@tis.com Subject: Re: Who is ELVIS? In-reply-to: Your message of "Sat, 22 Mar 1997 14:46:55 EST." <3.0.16.19970322144254.1d1721aa@pop3.pn.com> Reply-To: ji@hol.gr Organization: La maison qui rend fou. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 23 Mar 1997 02:08:20 +0200 From: John Ioannidis Sender: owner-ipsec@ex.tis.com Precedence: bulk [[ intentionally Cc'ed to the whole list ]] > On the IPsec survey I see two implementations I don't have new or old > entries for. These are listed in the section where people report what > other implementations they have interoperated with. One is "Elvis" and one > is "SOS". > > What are these? > I don't know about Elvis, but SOS refers to my (JI) implementation for BSDI, presented at the December '95 IETF in Dallas. /ji From owner-ipsec Sun Mar 23 13:24:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA19988 for ipsec-outgoing; Sun, 23 Mar 1997 13:16:59 -0500 (EST) From: Uri Blumenthal Message-Id: <9703231820.AA24783@hawpub.watson.ibm.com> Subject: Re: Proposed changes to ESP (andf a little AH too) To: ji@hol.gr Date: Sun, 23 Mar 1997 13:20:53 -0500 (EST) Cc: ipsec@tis.com In-Reply-To: <199703212153.XAA26081@del.tla.org> from "John Ioannidis" at Mar 21, 97 11:52:56 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk John Ioannidis says: > I'm all in favour of doing the encryption first and the authentication > after, so that on receipt we can authenticate before we receive, but > wasn't there some cryptographic argument against that sort of thing? The main argument against doing encryption first and auth second would be - generally speaking there is no guarantee even if you verified the CIPHERTEXT correctly, that the PLAINTEXT finally obtained is the same as was sent. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Sun Mar 23 15:04:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA20357 for ipsec-outgoing; Sun, 23 Mar 1997 14:59:37 -0500 (EST) Message-Id: <3.0.16.19970323150234.2987aab4@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Sun, 23 Mar 1997 15:04:42 -0500 To: uri@watson.ibm.com From: Rodney Thayer Subject: Re: Proposed changes to ESP (andf a little AH too) Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Would that mean that a transform combination of (outer AH, ESP, and inner AH) be useful? Or, of course, AH and ESP-with-authentication. At 01:20 PM 3/23/97 -0500, you wrote: >John Ioannidis says: >> I'm all in favour of doing the encryption first and the authentication >> after, so that on receipt we can authenticate before we receive, but >> wasn't there some cryptographic argument against that sort of thing? > >The main argument against doing encryption first and auth second would >be - generally speaking there is no guarantee even if you verified the >CIPHERTEXT correctly, that the PLAINTEXT finally obtained is the same >as was sent. >-- >Regards, >Uri uri@watson.ibm.com >-=-=-=-=-=-=- > > > -------- Rodney Thayer PGP: BB1B6428 409129AC 076B9DE1 4C250DD8 From owner-ipsec Sun Mar 23 16:59:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA20848 for ipsec-outgoing; Sun, 23 Mar 1997 16:53:17 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199703221517.KAA26648@amaterasu.sandelman.ottawa.on.ca> References: Your message of "Fri, 21 Mar 1997 14:10:11 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 22 Mar 1997 14:56:05 -0500 To: Michael Richardson From: Stephen Kent Subject: Re: Proposed changes to ESP (andf a little AH too) Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Mike, Both AH and ESP encompass the anti-replay counter within the scope of the authentication/integrity calculation. Steve From owner-ipsec Sun Mar 23 18:12:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA21175 for ipsec-outgoing; Sun, 23 Mar 1997 18:06:20 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <9703231820.AA24783@hawpub.watson.ibm.com> References: <199703212153.XAA26081@del.tla.org> from "John Ioannidis" at Mar 21, 97 11:52:56 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 23 Mar 1997 18:02:25 -0500 To: uri@watson.ibm.com From: Stephen Kent Subject: Re: Proposed changes to ESP (andf a little AH too) Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Uri, Just an observation about the encrypt-then-authentication (outbound) approach. When AH and ESP were initially defined, ESP provided only encryption. To achieve the combined authentication and encrypt function that was later added to ESP transforms, one would have to employ both AH and ESP. The architecture document does not recommend against applying ESP first and then adding AH, and I have seen many examples based on this ordering of these transforms. Thus, in reversing the order of the algorithm processing as I have suggested, one has a function analogous (though not exactly equivalent) to what has been proposed and advertized as a reasonable application of AH and ESP in the IPSEC context. You are right, of course, that the "outer" authentication computation verifies the ciphertext, not the underlying plaintext. However, the recipient has negotiated both the key and the encryption algorithm used to transform the ciphertext into plaintext, and we are requiring PFS for the key management algorithms. So, a number of tricks that one might attempt to undermine the binding between the ciphertext and plaintext should be thwarted. Also, we are talking about authentication and integrity, not non-repudiation, here, so some other forms of attacks that might be of concern in the NR context don't apply either. Given these caveats, do you feel that the proposed re-ordering of the processing steps (and associated syntax changes) poses a concern? If so, could you provide an example of the sort of attack that we would be subject to under this proposed re-ordering? Thanks, Steve From owner-ipsec Sun Mar 23 18:12:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA21176 for ipsec-outgoing; Sun, 23 Mar 1997 18:06:21 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199703212215.OAA22300@kebe.eng.sun.com> References: from "Stephen Kent" at Mar 21, 97 02:10:11 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 23 Mar 1997 17:36:13 -0500 To: Dan.McDonald@Eng.sun.com (Dan McDonald) From: Stephen Kent Subject: Re: Proposed changes to ESP (andf a little AH too) Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, The "we" working on the revisions include two folks from my network security departement at BBN (Karen Seo and Nina Yuan), plus Charlie Lynn, a protocol expert who has been involved in Nimrod, IPv6, host requirements and many other TCP/IP activities at BBN for over 15 years. Nina will be at Memphis (I have a prior engagement in Singapore) to brief the AH and ESP I-Ds, plus to go over some of the architecture document open issues. I agree with your observation that we have to look at every proposed change to AH and ESP with an eye toward the percieved benefit and to the cost (including time to market) for vendors. However, in working on the architecture document, we have uncovered a lot of issues that have not been well addressed to date, and I suspect that resolving these issues will actually cause more potential delays than the format changes we're looking at for AH and ESP. For example, the list had a brief discussion of PMTU and DF bit conventions, but our analysis has come up with a pretty good rationale for what various implementations should do, and when. Also, the currently posted architectuire I-D calls for being able to use a variety of IP header fields (and TCP/UDP port fields) as selectors for defining SAs or nested sets of SAs (I like the term "SA bundle" as suggested earlier). Yet, I have not seen any implementations that support these features, so far, even though the I-D has been out for over 6 months. As for the window size issue, I agree that one can simply decline to negotiate a size of 1, as a means of addressing this issue. However, I really believe that a size of 1 is so awful that it ought not be allowed. Moreover, only a size of 1 is proposed as required so far, and if we say dom't do 1, then we cannot rely on anyone doing 32 (and multiples thereof) instead. So, that's why I'd like to change to make 32 a MUST support, and multiples of 32 be recommemded optional window sizes. Your question about tranform document vs. transforms deserves a thoughtful reply. The revised specs (its more of an issue for ESP, but it applies to AH as well) will contain the details for (optional) anti-replay counter management. They also will describe how to do (optional) HMAC computation, with appropriate references to base spec by Hugo. There will be a definition of the required padding technique for ESP. Default algorithms will be cited and referred to via base algorithm specs. The goal is to no longer have "transform" documents, but only these specs and algorithm documents. In that sense, the number of transforms will diminish, since we will have made the combinations of algorithms and processing morr modular. However, one will still need to negotiate "transforms" as part of SA management, and it's up to the Wg to decide how many of these MUST be supported, vs. ones that MAY be supported, etc. So, I do think my goal is consistent with yours, in that I hope to have algorithms plus options within each protocol. One selects the combinations of algorithms and options via SA management, and we have chosen to label the bundled combinations "transforms." Steve P.S. I hope this explanation lays to rest any rumors about the demise of AH. I do see a diminished role for AH once we have ESP implementations that support encryptionless SAs, but there will still be uses for AH. From owner-ipsec Sun Mar 23 18:26:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA21241 for ipsec-outgoing; Sun, 23 Mar 1997 18:21:51 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: <3.0.1.32.19970319110315.00b4ad70@dilbert.is.chrysler.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 23 Mar 1997 18:22:09 -0500 To: Ran Atkinson From: Stephen Kent Subject: Re: the COMPRESSION discussion Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Ran, I think that we can make provision for compression in ESP, while deferring some of the issues you raised. For example, we already allow the definition of additional encryption and authentication algorithms, in addition to having define defaults that must be implemented. For compression, we could hold off on defining a MUST implement default, and thus rely on specific choices that are defined later. I admit that this is not the preferred approach, and it certainly does not promote interoperability as well as the tack we have taken with encryption and authentication algorithms so far, but it is a start. We have debated the question of at what processing layer to implement compression and there is agreement that one cabn do it at various layers, with differing benefits. But, the issue for us is not that more general one, but rather do we wish to provide for optional compression in the context of ESP. I agree with Bob and others that the responses on the list suggest that there is asubstantial support for this as an optional feature, to be negotiated on a per-SA basis. Support for arbitrary algorithms is a good goal, but operating in the IP layer, we have to limit ourselves to algorithms that do not rely on ordered delivery. I think that we understand the limitations on the methods that will work in our context, and those become constraints on applicable algorithms. It does not seem appropriate to require than any compression algortihm be a candiadte for IPSEC ESP use. Only ones that are fairly stateless should be candidates, given the out-of-order arrival and packet loss that are characteristics of IP layer traffic. I agree with most of your proposed process for dealing with this issue, and hope that we will receive submissions on specific, detailed proposals. However, I also believe that Bob has provided the necessary details that are sufficient for mods to the ESP spec, to accommodate a range of compression options and that we can add this to a later version of the ESP I-D with little or no effort. I do not agree with the suggestion to explore whether this is a generic IP layer issue vs. just an ESP issue. If we really want to make progerss on this, and meet the well-articulated needs of folks like Bob Moskowitz, I think we must plan on putting compression into IPSEC, since it is the use of ESP that especially motivates the need for compression as a compensating factor. So, I'd like to see us proceed as follows to add compression to our specs, if the WG agrees: - have the architecture document describe the optional use of compression within ESP, to be negotiated on a per-SA basis - define in the relevant ISAKMP documents how to negotiate compression - set aside the high order bit from the ESP padding field to indicate if compression has been applied to an individual packet - define in ESP the scope of compression and any alignment considerations applicable to the use of compression - define compression algorithms for ESP use in separate base documents, which can have backpointers to the architecture, ESP, and ISAKMP docs Steve From owner-ipsec Sun Mar 23 22:15:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA22243 for ipsec-outgoing; Sun, 23 Mar 1997 22:10:10 -0500 (EST) From: Uri Blumenthal Message-Id: <9703240315.AA280941@hawpub.watson.ibm.com> Subject: Re: Proposed changes to ESP (andf a little AH too) To: kent@bbn.com (Stephen Kent) Date: Sun, 23 Mar 1997 22:15:13 -0500 (EST) Cc: ipsec@tis.com In-Reply-To: from "Stephen Kent" at Mar 23, 97 06:02:25 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen Kent says: > You are right, of course, that the "outer" authentication > computation verifies the ciphertext, not the underlying plaintext. Of course. (:-) > However, the recipient has negotiated both the key and the encryption > algorithm used to transform the ciphertext into plaintext, and we are > requiring PFS for the key management algorithms....Also, we are talking > about authentication and integrity, not non-repudiation, here....... Yes, I understand that. > Given these caveats, do you feel that the proposed re-ordering of > the processing steps (and associated syntax changes) poses a concern? If > so, could you provide an example of the sort of attack that we would be > subject to under this proposed re-ordering? 1. I'm not sure. As you might have noticed, that same approach is adopted by SNMP Security (encrypt the body first, then authenticate the whole package), and similar arguments were made (wrt. who cares about non- repudiation etc.). Of course it's a reasonable assumption, that if both sides have the same encryption algorithm/key and the ciphertext is authentic, then the plaintext will also match. And *if* you can guarantee that the keys are indeed intact on both ends, *probably* the approach will work OK. 2. I don't have [at this moment] an example of how to break this encrypt-first-auth-second scheme. But I haven't really thought about it, and there are others more clever than me wrt. crypto attacks on the algorithms and protocols. 3. I basically tried to simply answer the question posted: what's the difference wrt. the order of the operations. Crypto people, am I the only one who is not 100% comfortable with this order of the operations? Can *you* think of an attack? What would be the assumptions for such an attack to succeed? -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Sun Mar 23 22:46:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA22414 for ipsec-outgoing; Sun, 23 Mar 1997 22:42:43 -0500 (EST) Message-Id: <199703240346.WAA15658@raptor.research.att.com> To: uri@watson.ibm.com cc: kent@bbn.com (Stephen Kent), ipsec@tis.com Subject: Re: Proposed changes to ESP (andf a little AH too) Date: Sun, 23 Mar 1997 22:46:32 -0500 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk Crypto people, am I the only one who is not 100% comfortable with this order of the operations? Can *you* think of an attack? What would be the assumptions for such an attack to succeed? Kent's approach defeats Wagner's short-block guessing attack (described in my paper ftp://ftp.research.att.com/dist/smb/badesp.ps). This is precisely because it does protect the ciphertext. My discomfort is due solely to the fact that I want these transforms standardized *now*. Anything that delays them is no good. From owner-ipsec Mon Mar 24 01:03:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA23092 for ipsec-outgoing; Mon, 24 Mar 1997 00:57:27 -0500 (EST) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199703240602.WAA06987@kebe.eng.sun.com> Subject: Re: Proposed changes to ESP (andf a little AH too) To: kent@bbn.com (Stephen Kent) Date: Sun, 23 Mar 1997 22:02:36 -0800 (PST) Cc: Dan.McDonald@Eng.sun.com, ipsec@tis.com In-Reply-To: from "Stephen Kent" at Mar 23, 97 05:36:13 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 > For example, the list had a brief discussion of PMTU and DF bit > conventions, but our analysis has come up with a pretty good rationale for > what various implementations should do, and when. I remember this discussion. I'm looking forward to seeing what you have to say on this topic. (IMHO, the only big issue I see on this front is that transport sessions (i.e. TCP) should be informed to ratchet down their MSS when/if using IPsec. This passing of information can be difficult in certain circumstances.) > Also, the currently posted architectuire I-D calls for being able to use a > variety of IP header fields (and TCP/UDP port fields) as selectors for > defining SAs or nested sets of SAs (I like the term "SA bundle" as > suggested earlier). Yet, I have not seen any implementations that support > these features, so far, even though the I-D has been out for over 6 months. Previous work has suggested that for outbound packets and their SAs, the "per-endpoint" abstraction works well. This same previous work, however, does not cover tying inbound SAs to an endpoint. I have some ideas, but I look forward to learning other approaches to the problem. > So, that's why I'd like to change to make 32 a MUST support, and multiples > of 32 be recommemded optional window sizes. My current experience with replay is limited, hence I do not feel qualified to comment on this just now. I look at it as something new to learn. :) > Your question about tranform document vs. transforms deserves a > thoughtful reply. It's a tricky question that affects: 1.) Key management * What do I negotiate? * What allows better policy definitions? 2.) AH and ESP code * What abstraction to my kernel-loadable modules implement? * What allows better policy definitions? 3.) APIs for both key management and endpoint security * What do I offer to the user or key management programs? * How do I manually administer such things? > However, one will still need to negotiate "transforms" as part of SA > management, and it's up to the Wg to decide how many of these MUST be > supported, vs. ones that MAY be supported, etc. > One selects the combinations of algorithms and options via SA management, > and we have chosen to label the bundled combinations "transforms." Okay. > I hope this explanation lays to rest any rumors about the demise of AH. I > do see a diminished role for AH once we have ESP implementations that > support encryptionless SAs, but there will still be uses for AH. There are plenty of uses for AH, even with encryptionless ESP. These include (in order of importance): 1.) Use of certain IP/IPv6 options w/o having to encapsulate them. Source routing is the foremost example that comes to my mind. These options, while used hop-by-hop, only need to be really authenticated end-to-end. 2.) AH has been sucessfully exported. I'm under the impression that ESP is "encryption-enabling" as per dain-bramaged U.S. export control law. 3.) Given the way IPv6 handles its payloads and options in discrete next-header units, AH fits in better (IMHO) with IPv6 processing. Thanks for the reply, and see you in Memphis! Dan From owner-ipsec Mon Mar 24 01:04:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA23103 for ipsec-outgoing; Mon, 24 Mar 1997 00:59:26 -0500 (EST) Message-ID: <3336197C.2847@cs.umass.edu> Date: Mon, 24 Mar 1997 01:04:44 -0500 From: Lewis McCarthy Organization: Theoretical Computer Science Group, UMass-Amherst, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha) MIME-Version: 1.0 To: IPsec Mailing List Subject: Re: Proposed changes to ESP (andf a little AH too) References: <9703240315.AA280941@hawpub.watson.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Uri Blumenthal writes: > 2. I don't have [at this moment] an example of how to break this > encrypt-first-auth-second scheme. Let me just toss in another observation on this operation ordering. Compared to auth-then-encrypt, I think this order technically makes it easier to compile a set of plaintext/ciphertext pairs, because it moves a potential entropy source outside the encryption. Suppose the replay counter is shifted outside the encryption as suggested. If an attacker can choose payload data & type values that require no padding, then all the plaintext input to the encryption transform is known, and of course the resulting ciphertext can be observed. On the other hand, with the auth-then-encrypt ordering, the HMAC digest forms part of the plaintext input to the encryption transform. The attacker presumably can't choose the HMAC digest value, and _may_ be unable to verify it at the receiver. Thus the complete plaintext corresponding to an observed ciphertext may not be as readily available to the attacker. (It also may be easier under some circumstances for the attacker to verify unpadded payload data & type values than HMAC digest values, at the receiver, even when nothing is chosen. The HMAC digest is much less interesting to higher protocol layers than is the payload, after the receiver performs its authentication check.) -Lewis From owner-ipsec Mon Mar 24 08:26:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA25427 for ipsec-outgoing; Mon, 24 Mar 1997 08:23:32 -0500 (EST) Date: Mon, 24 Mar 1997 08:23:32 -0500 (EST) Message-Id: <199703241323.IAA25427@portal.ex.tis.com> To: "James Hughes" From: Steve Sneddon Subject: Re: "Pillage first, then burn" - Attila the Hun Cc: rmonsour@earthlink.net, ipsec@tis.com, ken@anubis.network.com, varnis@winternet.com Sender: owner-ipsec@ex.tis.com Precedence: bulk At 12:50 PM 3/21/97 -0600, James Hughes wrote: >"Press release first, then develop" - (Name withheld by request) OK, I admit, you made me :=). > >Again, I hesitate to answer this. > >I seem to see that there are people that again claim that their intentions >and experiments are more valuable than product experience in a compression >with encryption product. The NSC product won the Best of Show at INTEROP >'95. It had compression then, and it has it now. Then I hope we can figure out a way to work together toward the goal of getting standards in this area. Let's discuss any commercial issues outside of the IETF list. > >On Thu, Mar 20, 1997 7:32 PM, Steve Sneddon wrote: >> Email to the IPSec list has its place, and formal presentations have >their >> place, but I believe you (HiFn) and I (Cisco) need to host an informal >> BOF-like discussion in Memphis around this topic in the hope that it can >> help move opinion forward. Maybe Tuesday evening would work. > >In my heart, I know that cisco -is- the pre-eminent vendor of eveything >important and we are not. NSC does have 2+ years of experience with >implementing, deploying and real traffic with products that have packet >level compression and encryption. This is actual experience, not >conjecture. This is also true from the legal, commercial as well as the >technical areas. > >I find that Cisco claiming the right to lead the discussions and host such >a BOF to be incredulous. I said an "informal BOF-like discussion". I have something very informal and totally unofficial and off the record in mind. We'll have plenty of occasion for real sessions at the official meeting. If you want to help lead it, great. I'll find the hall, and you can bring the pizza. :=) [The rest of this message is best answered off the mailing list. I'll send you private mail.] From owner-ipsec Mon Mar 24 08:30:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA25497 for ipsec-outgoing; Mon, 24 Mar 1997 08:29:34 -0500 (EST) Date: Mon, 24 Mar 1997 08:29:34 -0500 (EST) From: owner-ipsec@ex.tis.com Message-Id: <199703241329.IAA25497@portal.ex.tis.com> To: lmccarth@cs.umass.edu (Lewis McCarthy) cc: ipsec@tis.com (IPsec Mailing List) Subject: Re: replay window size (Re: Proposed changes to ESP (andf a little AH too)) Date: Sun, 23 Mar 1997 11:14:46 -0800 From: Derrell Piper Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk The size of the replay window should be implementation defined. There's nothing you can do in the protocol to force the other end to honor any particular window size, so you might as well let him choose one that's efficient for his particular kernel/architecture. On 32-bit systems, this will probably be 32, and on Alpha, 64. Steve Kent suggested in Montreal that the size might want to be negotiated so that the initiator has some way to indicate to the receiver the anti-replay size that he believes might be most appropriate. I think this adds unnecessary complexity, but I could support this if it's worded appropriately. In the past, it has been worded as if increasing the size of the replay detection window somehow weakens the anti-replay protection. Derrell > Do you have a recommendation for the replacement mandatory-to-implement > window size, instead of 1? To minimize disruption, we might upgrade > size=32 from recommended to mandatory-to-implement. > >-Lewis From owner-ipsec Mon Mar 24 10:16:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA27000 for ipsec-outgoing; Mon, 24 Mar 1997 10:16:00 -0500 (EST) Message-Id: <97Mar24.102209est.11650@elgreco.rnd.border.com> To: "James Hughes" cc: "Steve Sneddon" , ipsec@tis.com Subject: Vendor Interests (was Re: "Pillage first, then burn" - Attila the Hun) References: In-reply-to: hughes's message of "Fri, 21 Mar 1997 13:50:52 -0500". From: "C. Harald Koch" Date: Mon, 24 Mar 1997 10:20:45 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message , "James Hughes" writes: > > I find that Cisco claiming the right to lead the discussions and host such > a BOF to be incredulous. I assume that everyone participating in this discussion is an individual, and not a mindless slave to their employer's desires. It's certainly the case that at each IETF meeting, the participants remain the same while the "company names" on people's badges keep changing; this would support my assumption. -- Harald Koch From owner-ipsec Mon Mar 24 10:45:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA27210 for ipsec-outgoing; Mon, 24 Mar 1997 10:45:20 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3336197C.2847@cs.umass.edu> References: <9703240315.AA280941@hawpub.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 24 Mar 1997 10:46:42 -0500 To: Lewis McCarthy From: Stephen Kent Subject: Re: Proposed changes to ESP (andf a little AH too) Cc: IPsec Mailing List Sender: owner-ipsec@ex.tis.com Precedence: bulk Lewis, It is true that moving the counter and the HMAC outside of the encryption boundary does remove a source of unpredictable plaintext from the message. However, the HMAC is at the end of the message, and the use of an IV in feedback modes is designed to provide an unpredictable starting point for the encryption process. If the contents of the message are predictable, as suggested, then there typically will be enough plaintext to support a known plaintext attack irresepctive of the posotioning of the counter value. See Steve Bellovin's recent paper (in the Proceedings of the Symposium on Network and Distributed System Security, Feb 97) analyzing such attacks in a typical IP/TCP context. Steve From owner-ipsec Mon Mar 24 11:16:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA27210 for ipsec-outgoing; Mon, 24 Mar 1997 10:45:20 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3336197C.2847@cs.umass.edu> References: <9703240315.AA280941@hawpub.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 24 Mar 1997 10:46:42 -0500 To: Lewis McCarthy From: Stephen Kent Subject: Re: Proposed changes to ESP (andf a little AH too) Cc: IPsec Mailing List Sender: owner-ipsec@ex.tis.com Precedence: bulk Lewis, It is true that moving the counter and the HMAC outside of the encryption boundary does remove a source of unpredictable plaintext from the message. However, the HMAC is at the end of the message, and the use of an IV in feedback modes is designed to provide an unpredictable starting point for the encryption process. If the contents of the message are predictable, as suggested, then there typically will be enough plaintext to support a known plaintext attack irresepctive of the posotioning of the counter value. See Steve Bellovin's recent paper (in the Proceedings of the Symposium on Network and Distributed System Security, Feb 97) analyzing such attacks in a typical IP/TCP context. Steve From owner-ipsec Mon Mar 24 11:22:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00405 for ipsec-outgoing; Mon, 24 Mar 1997 11:20:44 -0500 (EST) From: Hsin Fang Date: Mon, 24 Mar 1997 11:23:26 -0500 (EST) Message-Id: <199703241623.LAA06124@emu.ncsl.nist.gov> To: kent@bbn.com Subject: Re: Proposed changes to ESP (andf a little AH too) Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, In your 23 Mar 1997 note, you wrote: > As for the window size issue, I agree that one can simply decline > to negotiate a size of 1, as a means of addressing this issue. However, I > really believe that a size of 1 is so awful that it ought not be allowed. > Moreover, only a size of 1 is proposed as required so far, and if we say > dom't do 1, then we cannot rely on anyone doing 32 (and multiples thereof) > instead. So, that's why I'd like to change to make 32 a MUST support, and > multiples of 32 be recommemded optional window sizes. I can understand that mandatory window size of 1 is not a good idea: it force to drop every single out-of-order packet. But I don't see any good reason to force the window size to be 32*X (X >= 1). Shouldn't people be allowed to pick up any smaller number, let us say 8 or 16, as best fit their application? Window size of 32*X when X>=2 is quite big to me considering that it is a per destination/per security association figure. Regards, Hsin From owner-ipsec Mon Mar 24 11:22:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00391 for ipsec-outgoing; Mon, 24 Mar 1997 11:19:14 -0500 (EST) 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-ah-hmac-md5-96-00.txt Date: Mon, 24 Mar 1997 09:58:17 -0500 Message-ID: <9703240958.aa24177@ietf.org> 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 : HMAC-MD5-96 IP Authentication with Replay Prevention Author(s) : M. Oehler, R. Glenn Filename : draft-ietf-ipsec-ah-hmac-md5-96-00.txt Pages : 8 Date : 03/21/1997 This document describes a keyed-MD5 transform to be used in conjunction with the IP Authentication Header [RFC-1826]. The particular transform is based on [RFC-2104]. A replay prevention field is also specified. 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-ah-hmac-md5-96-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ah-hmac-md5-96-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-md5-96-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970321095813.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-md5-96-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ah-hmac-md5-96-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970321095813.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Mar 24 11:22:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00283 for ipsec-outgoing; Mon, 24 Mar 1997 11:13:51 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199703241329.IAA25497@portal.ex.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 24 Mar 1997 10:59:48 -0500 To: ipsec@tis.com From: Stephen Kent Subject: Re: replay window size Sender: owner-ipsec@ex.tis.com Precedence: bulk Derrell, The revised specs will make sure that there is no confusion re the relative secruity afforded by different replay windo sizes. As you observe, a large window, if proparly implemented, does just as good a job of preventing replays as a smaller window. The difference is that larger windows have a greater tolerance for out of order packet arrival than smaller windows, but IP assumes out of order arrival, and is silent on the extent to which such behavior may be benign (vs. malicious). I'm concvrened about having the window size be solely implementation defined, since that can lead to unopredictable behavior that may be hard to track down. Also, there seems to be general agreement that a wiondow size of 32, or multiples thereof, is relatively easy to implement. I don't want to have implementors feel that they must implement arbitrary size windows, since that is potentially hard (or inefficient), yet some have sent me private mail expressing concerns abotu exactly that. So, we need to clarify this. Also, I don't want to see a window size of 1 since that conflcits with the IP layer model for delivery. I like to think in terms of "consumer protection" when writing a spec. If certain requirements are levied, then the purchasers of IPSEC-compliant devices will be assured of a certain level of functionality (though not assurance), and interoperability will be fostered. If we are silent on important issues, such as what size window is supported for anti-replay, then I worry about what the products will do. Hence my desire to stipulate reasonable requirements for window sizes. However, I am sensitive to your concern re negotiation and if we could settle on a window size of 32 as a mandatory to implement default, and have negotiation of larger sizes optional, that might address both concerns. Steve From owner-ipsec Mon Mar 24 13:59:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA01739 for ipsec-outgoing; Mon, 24 Mar 1997 13:56:11 -0500 (EST) From: Robert Glenn Date: Mon, 24 Mar 1997 14:00:37 -0500 (EST) Message-Id: <199703241900.OAA12874@sloth.ncsl.nist.gov> To: ipsec@tis.com Subject: HMAC Test case draft submitted Cc: pau@watson.ibm.com, rob.glenn@nist.gov Sender: owner-ipsec@ex.tis.com Precedence: bulk In hopes of helping eliminate some of the more basic algorithm-specific interoperability problems, Pau-Chen Cheng and I have put together and submitted a HMAC Test Cases I-D that covers HMAC-MD5 and HMAC-SHA. I've put an advanced copy at: ftp://ftp.antd.nist.gov/pub/ipsec/draft-cheng-hmac-test-cases-00.txt. Rob G. rob.glenn@nist.gov From owner-ipsec Mon Mar 24 16:40:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA02892 for ipsec-outgoing; Mon, 24 Mar 1997 16:36:52 -0500 (EST) Message-Id: <199703242141.QAA01968@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: ipsec@tis.com Subject: Open issues for inline keying. Date: Mon, 24 Mar 1997 16:41:25 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk I've gotten several bits of feedback on my inline keying proposal; unfortunately, there doesn't seem to be any particular consensus in the comments I've received. Please read draft-ietf-ipsec-inline-isakmp-00.txt; it's not very long; a quick summary is that it involves "spawning" new security associations from old ones by using "reply-SPI-creation" messages piggybacked on normal network traffic. I see three major open isues: Issue 1: How do we frame the reply-SPI creation message within the packet? [There are some similarities between this issue and the compression issue. It would be good to resolve them in a similar way..] option 1a: Steal a bit out of the ESP encoding to indicate the presence of a reply-SPI-creation message. Perhaps the next-to-the-high-order bit of the pad length? :-)) This bit would only be used if the endpoints had configured/negotiated inline keying in the parent SA. option 1b: use a new IP-level protocol with a "next-protocol" field, and set the next-protocol field of the containing ESP header to this new protocol, and the inline-keying protocol's next-protocol to the payload's protocol. One implementor was significantly opposed to this idea; another was significantly in favor of it and I haven't heard any other opinions. option 1c: Use the ipv6 "destination options" IP-layer protocol (IP protocol 60) to contain the reply-SPI-creation message. For those unfamiliar with ipv6 (which includes myself): ipv6 doesn't include any space for option information in the base IP header; instead, it uses a nested protocol approach akin to AH (ip protocol 60 is the "ipv6 destination options" protocol). It appears to me that there is fundamentally no reason why this protocol could not also be used inside an ipv4 header, though it may be a little more work in ipv4-only implementations and it may complicate mixed ipv4/ipv6 implementations. option 1d: anyone have any better ideas? Issue 2: What goes inside the reply-SPI creation message? option 2a: An a message from an ISAKMP quick-mode exchange (which requires three messages before both new SA's can be brought up). option 2b: A simplified quick-mode-like message which creates a reply-SPI in a single message, allowing both child-SA's to be brought up in a single message exchange, probably piggybacked on the SYN and SYN-ACK of a connection establishment. This is lower overhead, probably higher efficiency, but more work to implement and analyze since we can't just encapsulate the isakmp message and send it in line. Issue 3: Keying the payload which is along for the ride with the reply-SPI-creation message. option 3a: Just use the SPI's encryption as-is [which seems like it might be cryptographically weaker than options 3b and 3c ] option 3b: Include a nonce in the reply-spi-creation message to hash with the shared secret to generate the key for this packet. [this is effective, but non-modular] option 3c: define a new class of ESP transforms which include a nonce in each packet (Hilarie Orman called this a "key hash index") which is combined with the SA's shared secret to generate the key used to encrypt the packet. This may be easier to do given the new mix-and-match ESP architecture which Steve Kent has proposed, and I think this, without the additional reply-SPI-creation protocol, is what Hilarie is looking for. --- Does anyone have any commentary? If you have a preference, please explain why (since I'm easier to convince if there's a rationale behind it). I am currently leaning towards 1c, 2b, and 3c, but could be convinced one way or the other. The -01 draft will likely continue to waffle about the issues unless I receive *convincing* arguments in favor of particular options by late tomorrow. - Bill From owner-ipsec Mon Mar 24 23:44:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA05211 for ipsec-outgoing; Mon, 24 Mar 1997 23:41:45 -0500 (EST) From: HUGO@watson.ibm.com Message-Id: <199703250446.XAA49412@mailhub1.watson.ibm.com> Date: Mon, 24 Mar 97 23:38:20 EST To: iesg@ietf.org, IPSEC@tis.com cc: DHARKINS@cisco.com, carrel@ipsec.org, RJA@inet.org, PALAMBER@us.oracle.com, CANETTI@watson.ibm.com Subject: oakley-03: last call comments Sender: owner-ipsec@ex.tis.com Precedence: bulk In the last months I have been collaborating with Dan Harkins on several design issues for the isakmp/oakley protocol. Dan has been very open and receptive of the changes and design guidelines that I suggested. There are two issues, however, that were not resolved in oakley-03. They are significant for security and functionality reasons so I insist they need to be done. I am also adding a third simple change that I failed to communicate to the editors in time before the appearance of oakley-03. The changes are simple from editorial point of view (full text change is suggested below). They do impact implementations but do not require any extensive work to adjust to them. Therefore, now is the right time to do them before fielded implementations are available. Notice that I am careful not to suggest any change that could lead to delays in the standard definition and deployment. Change No. 1: Quick Mode ************************ The draft says: > Quick Mode is defined as follows: > > Initiator Responder > ----------- ----------- > HDR*, HASH(1), SA, Ni > [, KE ] [, IDui, IDur ] --> > <-- HDR*, HASH(2), SA, Nr > [, KE ] [, IDui, IDur ] > HDR*, HASH(3) --> > > Where: > HASH(1) and HASH(2) are the prf over the message id (M-ID) from > the ISAKMP header concatenated with the entire message that follows > the hash including payload headers, but excluding any padding added > for encryption. HASH(3)-- for liveliness-- is the prf over the value > zero represented as a single octet, followed by a concatenation of > the message id and the two nonces-- the initiator's followed by the > responder's. In other words, the hashes for the above exchange are: > > HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDui | IDur ]) > HASH(2) = prf(SKEYID_a, M-ID | SA | Nr [ | KE ] [ | IDui | IDur ]) > HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni | Nr) > Problem: A basic practice in authentication protocols is to use nonces to guarantee the freshness of the authentication messages. In this case there is a nonce Ni sent for I to R in the first message. That nonce Ni needs to be incorporated into the hash computation of HASH(2) for such a freshness purpose (to prevent re-play attacks). This is also consistent with design of HASH_I and HASH_R in all the other modes of the protocol. Recommendation: Change > HASH(2) = prf(SKEYID_a, M-ID | SA | Nr [ | KE ] [ | IDui | IDur ]) to HASH(2) = prf(SKEYID_a, M-ID | SA | Nr | Ni [ | KE ] [ | IDui | IDur ]) ^^ Discussion: Currently, freshness in HASH(2) IS provided via the field M-ID which ISAKMP specifies to be "randomly chosen by the Initiator". The problem is that M-ID (message identifier) has no cryptographic motivation by itself in ISAKMP. It is used by a system to differentiate parallel (phase 2) exchanges belonging to the same tunnel. In particular, in many cases implementations could dispense of the randomness (e.g. when no parallel sessions are run). Actually, we cannot even guarantee that this definition of M-ID as a random number will not be changed in the future in arevised ISAKMP version. Who will then remember that there is a cryptographic use of this number in Oakley? Since Ni is there anyway in Oakley let's use it as freshness guarantee, thus making Oakley more self-contained, more secure, and easier for analysts and implementers to understand its cryptographic rationale and design. Change No. 2: Authentication through public key encryption *********************************************************** Problem: The draft currently provides identity protection in this mode (page 11) by encrypting the identities under a public key encryption. As specified now this public key encryption is separated from that of the nonces Ni and Nr. This means that the protocol requires TWO encryption and decryption operation for each party. This is unnecessarily expensive (depending on your processor the extra exponentiation may have negligible up to significant effect in performance). Indeed it is enough to encrypt the nonce under the public key and to derive from it a key for a symmetric encryption (e.g. under DES) of the identity. This solution adds no significant complexity to the implementation and saves a costly long (RSA or other) exponentiation. (It also allows to easily encrypt long certificates if sent from Inititiator to Responder; currently such an encryption is not specified/possible.) Recommendation: Change the following text (page 11) > > In addition to the nonce, the identities of the parties (IDii and > IDir) are also encrypted with the other parties public key. If the > authentication method is public key encryption, the nonce and > identity payloads MUST be encrypted with the public key of the other > party. Only the body of the payloads are encrypted, the payload > headers are left in the clear. > > When using encrytion for authentication with Oakley, Main Mode is > defined as follows. > > Initiator Responder > ----------- ----------- > HDR, SA --> > <-- HDR, SA > HDR, KE, [ HASH(1), ] > PubKey_r, > PubKey_r --> > HDR, KE, PubKey_i, > <-- PubKey_i > HDR*, HASH_I --> > <-- HDR*, HASH_R > > Oakley Aggressive Mode authenticated with encryption is described as > follows: > > Initiator Responder > ----------- ----------- > HDR, SA, [ HASH(1),] KE, > Pubkey_r, > Pubkey_r --> > HDR, SA, KE, PubKey_i, > <-- PubKey_r, HASH_R > HDR, HASH_I --> > > > > Harkins, Carrel [Page 11] TO: The nonce is encrypted with the other parties public key. The identities of the parties (IDii and IDir) are encrypted with a symmetric cipher (as negotiated by the ISAKMP Security Association, e.g. DES) using a key derived from the nonce (if a certificate is passed from Initiator to Responder it is encrypted under the same key as the identities). If the authentication method is public key encryption, the nonce payload MUST be encrypted with the public key of the other party. Only the body of the payloads are encrypted, the payload headers are left in the clear. When using encryption for authentication with Oakley, Main Mode is defined as follows. Initiator Responder ----------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, [ HASH(1), ] PubKey_r --> Ne_i [Ne_i] <-- HDR, KE, PubKey_i Ne_r HDR*, HASH_I --> <-- HDR*, HASH_R The keys Ne_i and Ne_r are defined as: Ne_i = prf(Ni, CKY-I) Ne_r = prf(Nr, CKY-R) The notation <...>PubKey refers to public key encryption (e.g. using the RSA algorithm) while the notation <...>Ne refers to encryption under a symmetric cipher (e.g DES) as negotiated for payload encryption by the ISAKMP SA. The key used for symmetric encryption to protect the third (resp. fourth) message payloads is derived (and possibly expanded) from Ne_i (resp. Ne_r) in an algorithm-specific manner (see appendix B). If CBC mode is used for the encryption then the initialization vector (IV) is set to 0 (notice that the value Ne_i is ephemeral). Encrypted payloads are padded up to the nearest block size using bytes containing 0x00. Oakley Aggressive Mode authenticated with encryption is described as follows: Initiator Responder ----------- ----------- HDR, SA, [ HASH(1),] KE, Pubkey_r, Ne_i --> [Ne_i] HDR, SA, KE, PubKey_i, <-- Ne_r, HASH_R HDR, HASH_I --> (end of proposed change) Discussion: A further security measure that can be taken here is to use Ne_i and Ne_r to encrypt the KE payload. This adds more security to the DH exchange (against broken modulus p, against short exponents, etc.). I leave the decision to the editors whether to add this encryption as part of the specification or not. Also, notice that I left the HDR* notation in non-aggressive mode although this encryption (under SKEYID_e) it is not really necessary since the identities are not there. Whether to remove that encryption is up to the editors. Leaving it adds to the processing time but may simplify implementation as it is consistent with other non-aggressive modes. Change No. 3: Derivation of SKEYID ********************************** SKEYID derivation is defined as: > > For signatures: SKEYID = prf(Ni | Nr, g^xy) > For public key encryption: SKEYID = hash(Ni | Nr) > For pre-shared keys: SKEYID = prf(pre-shared-key, Ni | Nr) In the case of public key encryption I suggest to change the definition to For public key encryption: SKEYID = prf(Ni | Nr, CKY-I | CKY-R) This is better compatible with the definition of prf (rather than just hash) and uniform with all other key derivations in this protocol. Note: The suggestion SKEYID = hash(Ni | Nr) is my own fault. Pau-Chen Cheng suggested the above improved prf derivation. Hugo From owner-ipsec Tue Mar 25 01:34:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA05854 for ipsec-outgoing; Tue, 25 Mar 1997 01:32:17 -0500 (EST) To: ipsec@ex.tis.com Path: not-for-mail From: daw@cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: Proposed changes to ESP (andf a little AH too) Date: 24 Mar 1997 22:33:06 -0800 Organization: ISAAC Group, UC Berkeley Lines: 39 Message-ID: <5h7rj2$ng6@joseph.cs.berkeley.edu> References: <199703212153.XAA26081@del.tla.org> <9703231820.AA24783@hawpub.watson.ibm.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk In article <9703231820.AA24783@hawpub.watson.ibm.com>, Uri Blumenthal wrote: > The main argument against doing encryption first and auth second would > be - generally speaking there is no guarantee even if you verified the > CIPHERTEXT correctly, that the PLAINTEXT finally obtained is the same > as was sent. That's a robustness argument against authenticating the ciphertext, and a pretty good one if the decryption routine is complicated. However, if the decryption is simple & easy to analyze, we can (mostly) put to rest those fears about authenticating ciphertext. Suppose the decryption routine depends only on the authenticated ciphertext (and a key). We assume the two endpoints both see the same view of the key. Furthermore, we assume the MAC is secure, so that the two endpoints both share the same view of the ciphertext. Because decryption is a function that depends on no other parameters (by assumption), then the result of decryption will be the same at both endpoints. Therefore, you can be sure that the plaintext finally obtained is the same as was sent. Some examples where this informal "proof" goes wrong will probably make the argument clearer. If decryption depended on an IV which wasn't authenticated (more specifically, wasn't included in the MAC input for this packet), then the arguments fails -- and indeed, if an adversary with control over the IV can fake the first block of plaintext at will without breaking the MAC. If decryption included a decompression stage which depended on some context (a LZH dictionary, say), and that context was implicit and un-authenticated, the argument fails. So-- how simple is the decryption routine? What parameters does it depend on? If the decryption routine is simple enough that we can (with pretty high assurance) isolate all the parameters it depends on and ensure that they are authenticated, then we have a good argument saying that authenticating the ciphertext is safe. Otherwise, we should start to worry that authenticating the ciphertext is not robust enough. From owner-ipsec Tue Mar 25 09:12:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA09120 for ipsec-outgoing; Tue, 25 Mar 1997 09:10:04 -0500 (EST) Message-Id: <3.0.1.32.19970325072815.009d8350@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 25 Mar 1997 07:28:15 -0500 To: Stephen Kent , "Theodore Y. Ts'o" From: Robert Moskowitz Subject: Re: Proposed changes to ESP (andf a little AH too) Cc: ipsec@tis.com In-Reply-To: References: <9703212112.AA20804@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 06:23 PM 3/21/97 -0500, Stephen Kent wrote: > > Even for transport mode ESP, the proposed swap of fields only >exposes the packet counters, nothing else that was not expose before. The >SPIs are equally visible in both cases, as are the soure and destination >addresses and the IP packet IDs. Together, these pieces of data provide me >with enough info to do a good job of TA, exclusive of the counter info. >So, I'm not sure that I understand why you feel that the exposure of the >packet counters represents much of an aid to traffic analysis. Silly rabbit, when you are behind on mail, good thing to read through whole thread before interjecting :) This answers my question Steve.... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Tue Mar 25 09:12:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA09125 for ipsec-outgoing; Tue, 25 Mar 1997 09:10:06 -0500 (EST) Message-Id: <3.0.1.32.19970325071745.009d7450@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 25 Mar 1997 07:17:45 -0500 To: Stephen Kent , ipsec@tis.com From: Robert Moskowitz Subject: Re: Proposed changes to ESP (andf a little AH too) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 02:10 PM 3/21/97 -0500, Stephen Kent wrote: > > Now for a bigger change! I suggest that we reverse the order of >encryption and authentication processing, when both are employed. Now, >authentication processing occurs first, then encryption. This means that a >receiver must decrypt then autehnticate. While most systems I have seen in >the past have adopted this strategy, we are now more concerned with denial >of service attacks. A likely common use of ESP is to create VPNs thorugh >IPSEC implementations in security gateways. If we reverse the order of >processing, then a secruity gateway can validate the integrity and >authenticity of a packet befor edecrypting it, thus rejecting bogus packets >faster (about twice as fast, in many instances), than if we had to decrypt >then authenticate. Combined with the psoposed positional change for the >counter (suggested above), we now have an ability to reject duplicate or >spurious packets very quickly, providing better defense against DoS attacks. Steve, I will admit my limited experience in this matter, but in secure mail, it makes sense to auth then encrypt to hide identities for traffic analysis and for gaining identities of protected individuals (like CEOs). Now does the same argument apply to IPsec? Would exposing the auth information reveal more than some would want? Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Tue Mar 25 09:12:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA09135 for ipsec-outgoing; Tue, 25 Mar 1997 09:10:30 -0500 (EST) Message-Id: <3.0.1.32.19970325072021.009d7450@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 25 Mar 1997 07:20:21 -0500 To: "Theodore Y. Ts'o" , Stephen Kent From: Robert Moskowitz Subject: Re: Proposed changes to ESP (andf a little AH too) Cc: ipsec@tis.com In-Reply-To: <9703212112.AA20804@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:12 PM 3/21/97 -0500, Theodore Y. Ts'o wrote: > >In the case of using ESP to create VPN's through security gateways, the >threat of traffic analysis doesn't really apply, since the authenticated >destination will always be the other security gateway. Indeed, the >traffic analysis threat isn't important if we're doing host keying for >the same reason --- the low level, unauthenticated address allows for >traffic analysis anyway. > >The only place where traffic analysis would matter would be if we did >user-based keying, and we have multiple users using the same host, in a >time-sharing fashion. Ah, but you missed the case where the SA was built from the identity of the system behind the gateway. This is not user-based keying, but key proxing. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Tue Mar 25 10:27:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA09753 for ipsec-outgoing; Tue, 25 Mar 1997 10:24:32 -0500 (EST) Message-Id: <3.0.16.19970325102428.1b17eeca@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Tue, 25 Mar 1997 10:29:50 -0500 To: ipsec@tis.com From: Rodney Thayer Subject: replay mandatory? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Replay is mandatory? As in, replay size of 1 (no replay checking) is forbidden? >From: Hsin Fang >Date: Mon, 24 Mar 1997 11:23:26 -0500 (EST) >To: kent@bbn.com >Subject: Re: Proposed changes to ESP (andf a little AH too) >Cc: ipsec@tis.com >Sender: owner-ipsec@ex.tis.com > > >Steve, > >In your 23 Mar 1997 note, you wrote: > >> As for the window size issue, I agree that one can simply decline >> to negotiate a size of 1, as a means of addressing this issue. However, I >> really believe that a size of 1 is so awful that it ought not be allowed. >> Moreover, only a size of 1 is proposed as required so far, and if we say >> dom't do 1, then we cannot rely on anyone doing 32 (and multiples thereof) >> instead. So, that's why I'd like to change to make 32 a MUST support, and >> multiples of 32 be recommemded optional window sizes. > >I can understand that mandatory window size of 1 is not a good idea: it force >to drop every single out-of-order packet. But I don't see any good reason to >force the window size to be 32*X (X >= 1). Shouldn't people be allowed to pick >up any smaller number, let us say 8 or 16, as best fit their application? >Window size of 32*X when X>=2 is quite big to me considering that it is a per >destination/per security association figure. > >Regards, >Hsin > > > > -------- Rodney Thayer PGP: BB1B6428 409129AC 076B9DE1 4C250DD8 From owner-ipsec Tue Mar 25 10:28:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA09759 for ipsec-outgoing; Tue, 25 Mar 1997 10:25:52 -0500 (EST) Date: Tue, 25 Mar 1997 10:30:15 -0500 Message-Id: <199703251530.KAA00625@road-warrior.mit.edu> From: "Jeffrey I. Schiller" To: kent@bbn.com CC: rja@inet.org, ipsec@tis.com In-reply-to: (message from Stephen Kent on Sun, 23 Mar 1997 18:22:09 -0500) Subject: Re: the COMPRESSION discussion Sender: owner-ipsec@ex.tis.com Precedence: bulk I have tried to keep my nose out of this debate, but Memphis is approaching rapidly (must have put it on one of the Fedex jets) and we need to come to cloture real soon. From: Stephen Kent ... So, I'd like to see us proceed as follows to add compression to our specs, if the WG agrees: - have the architecture document describe the optional use of compression within ESP, to be negotiated on a per-SA basis - define in the relevant ISAKMP documents how to negotiate compression - set aside the high order bit from the ESP padding field to indicate if compression has been applied to an individual packet - define in ESP the scope of compression and any alignment considerations applicable to the use of compression - define compression algorithms for ESP use in separate base documents, which can have backpointers to the architecture, ESP, and ISAKMP docs This looks like a good plan to me. -Jeff From owner-ipsec Tue Mar 25 11:00:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA10042 for ipsec-outgoing; Tue, 25 Mar 1997 10:57:47 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199703241623.LAA06124@emu.ncsl.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Mar 1997 10:54:58 -0500 To: Hsin Fang From: Stephen Kent Subject: Re: Proposed changes to ESP (andf a little AH too) Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Hsin, Arbitrary size windows are potentially expensive to implement, though conceptually simple. We chose 32 (and multiples thereof) for the ease with which one can implement the window on a 32 bit (or 64 bit) machine. This sort of pragmatic recognition of commonly deployed machine word sizes also shows up in the IPv6 packet alignment requirements, so it is not out of pace here. Note that there is no security risk associated with a larger window size, i.e., in all cases all replays are rejected. The larger window size just provides a greater tolerance for out-of-order arrival, which is itsefl a feature of IP. Steve From owner-ipsec Tue Mar 25 11:00:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA10041 for ipsec-outgoing; Tue, 25 Mar 1997 10:57:46 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.16.19970325102428.1b17eeca@pop3.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Mar 1997 10:59:50 -0500 To: Rodney Thayer From: Stephen Kent Subject: Re: replay mandatory? Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Rodney, The window size of 1 does prevent replay, but it also prevents legitimate, out-of-order arrival of packets at the IP layer. A larger window size does not allow ANY replays; it just allows packets to arrive at the IPsec implementation out of order and still be checked and accepted. Steve From owner-ipsec Tue Mar 25 11:56:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA10498 for ipsec-outgoing; Tue, 25 Mar 1997 11:51:56 -0500 (EST) Message-Id: <199703251656.LAA02300@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: daw@cs.berkeley.edu (David Wagner) Cc: ipsec@ex.tis.com Subject: Re: Proposed changes to ESP (andf a little AH too) In-Reply-To: daw's message of 24 Mar 1997 22:33:06 -0800. <5h7rj2$ng6@joseph.cs.berkeley.edu> Date: Tue, 25 Mar 1997 11:56:26 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > > The main argument against doing encryption first and auth second would > > be - generally speaking there is no guarantee even if you verified the > > CIPHERTEXT correctly, that the PLAINTEXT finally obtained is the same > > as was sent. > > That's a robustness argument against authenticating the ciphertext, > and a pretty good one if the decryption routine is complicated. > > However, if the decryption is simple & easy to analyze, we can (mostly) > put to rest those fears about authenticating ciphertext. It's also the case that the bulk of the protocols which will likely be used inside ESP (IP, UDP, TCP) already use a simple 16-bit checksum, which will cause most garbled traffic to be dropped. If we assume that errors where the ciphertext is authenticated but the decryption is garbled will most likely occur during debugging of new code or manual keying, then that would seem to be an acceptable risk; the operator(s) will interpret 99.998% packet loss as 100% packet loss and start debugging.. We merely need to specify that the IP checksum MUST be supplied on transmission and verified on receipt for packets nested inside ESP. - Bill From owner-ipsec Tue Mar 25 13:43:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA11500 for ipsec-outgoing; Tue, 25 Mar 1997 13:40:40 -0500 (EST) Message-Id: <3.0.16.19970325133743.373f1152@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Tue, 25 Mar 1997 13:45:32 -0500 To: Stephen Kent From: Rodney Thayer Subject: Re: replay mandatory? Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I wonder if I am missing something. Today, in an IPsec-less environment, if I get IP packets for 1000 different TCP circuits, I have to have some pool of local copies of packets to deal with out-of-order IP packets. If I implement IPsec, with NO replay, things are the same. I decrypt, I send it to the next step in the process, and presumably the same pool could be used. If I require a replay window of 32 for 1000 different Security Associations, that means I need to keep 32*1000 copies of IP packets around. I can't spread the pool cost among the 1000 like I could in the non-IPsec case. At 10:59 AM 3/25/97 -0500, you wrote: >Rodney, > > The window size of 1 does prevent replay, but it also prevents >legitimate, out-of-order arrival of packets at the IP layer. A larger >window size does not allow ANY replays; it just allows packets to arrive at >the IPsec implementation out of order and still be checked and accepted. > >Steve > > > > -------- Rodney Thayer PGP: BB1B6428 409129AC 076B9DE1 4C250DD8 From owner-ipsec Tue Mar 25 14:22:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA11864 for ipsec-outgoing; Tue, 25 Mar 1997 14:20:05 -0500 (EST) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199703251925.LAA07271@kebe.eng.sun.com> Subject: Re: replay mandatory? To: rodney@sabletech.com (Rodney Thayer) Date: Tue, 25 Mar 1997 11:25:06 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: <3.0.16.19970325133743.373f1152@pop3.pn.com> from "Rodney Thayer" at Mar 25, 97 01:45:32 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 > I wonder if I am missing something. I think the only thing you're missing is that you CAN have no replay protection on your SA(s). (There is no window size when you have no replay.) I see people saying, "If you use replay, the minimum window size MUST be 32 packets." And let's look at your concerns. > Today, in an IPsec-less environment, if I get IP packets for 1000 different > TCP circuits, I have to have some pool of local copies of packets to deal > with out-of-order IP packets. Basically, each TCP connection has state which will queue up the packets that arrive out of order, rather than deliver them to the appropriate application. If a segment arrives out-of-order, it gets queued at the TCP control block (or whatever you call yours), and that memory is held until such time as the data is delivered and consumed. > If I implement IPsec, with NO replay, things are the same. I decrypt, I > send it to the next step in the process, and presumably the same pool could > be used. If the same memory block (mbuf, mblk, whatever you use) ISN'T being used after you've decrypted (OR AUTHENTICATED, DON'T FORGET AH, FOLKS), I question your design. :) You're right, you just deliver as before w/o replay. > If I require a replay window of 32 for 1000 different Security > Associations, that means I need to keep 32*1000 copies of IP packets > around. Not necessarily. It's POSSIBLE that you'll have 31*1000 copies of IP packets queued up, assuming a Byzantine failure. Besides, at some point in time, you just assume that packet didn't arrive, drop it, then deliver the .. etc packets. Delivery will free up the resources. Keep in mind that with larger replay windows, system resources CAN be consumed at a faster rate. It doesn't, however, mean that they WILL be consumed at a faster rate. > I can't spread the pool cost among the 1000 like I could in the non-IPsec > case. I understand that you're concerned about system resources. It sounds like, in your system, you allocate a fixed number of buffers allocated to network traffic. Yes, a large replay window will perhaps exhaust your finite supply of buffers quicker than no replay. If packets are behaving themselves and arrive mostly in-order, even with a replay window of 256, you won't be burning your buffers very quickly. I suspect that's the common case. Finally, if I understand, if you're that concerned about system resources, you can have a policy of no-replay-protection in your KMd. Dan From owner-ipsec Tue Mar 25 14:32:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA12015 for ipsec-outgoing; Tue, 25 Mar 1997 14:31:18 -0500 (EST) Message-Id: <199703251935.OAA02413@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: Rodney Thayer Cc: Stephen Kent , ipsec@tis.com Subject: Re: replay mandatory? In-Reply-To: rodney's message of Tue, 25 Mar 1997 13:45:32 -0500. <3.0.16.19970325133743.373f1152@pop3.pn.com> Date: Tue, 25 Mar 1997 14:35:12 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > If I require a replay window of 32 for 1000 different Security > Associations, that means I need to keep 32*1000 copies of IP packets > around. I can't spread the pool cost among the 1000 like I could in the > non-IPsec case. No, you process non-replayed packets out-of-order as they arrive (and toss replayed or stale packets as they arrive), so, at the ipsec layer, for 1000 SA's, you need room for 1000 * 64 bits of storage (32 bits of sequence number plus 32 bits of replay-window bitmap); this is most likely smaller than the encryption state. You still need buffering in tcp and in ip fragment reassembly. - Bill From owner-ipsec Tue Mar 25 14:39:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA12156 for ipsec-outgoing; Tue, 25 Mar 1997 14:37:56 -0500 (EST) From: HUGO@watson.ibm.com Message-Id: <199703251942.OAA28141@mailhub1.watson.ibm.com> Date: Tue, 25 Mar 97 14:12:31 EST To: sommerfeld@apollo.hp.com, daw@cs.berkeley.edu cc: ipsec@ex.tis.com Subject: Proposed changes to ESP (andf a little AH too) Sender: owner-ipsec@ex.tis.com Precedence: bulk Ref: Your note of Tue, 25 Mar 1997 11:56:26 -0500 (attached) I agree with both Bill's note attached here, and Dave Wagner's comments in a recent note. If the choice would be pure cryptographic I might be inclined for the current authenticate-the-plaintext (and encrypt the MAC) approach. It better captures the real objective which is to authenticate the plaintext rather than the ciphertext. However, the other approach is not bad enough as to be immediately disqualified. If authenticate-the-ciphertext is chosen, it will be important to have some remarks in the draft in the lines of Dave's note. The real question to decide in this WG is whether the advantage against denial of service attacks provided by the authenticate-the-ciphertext approach is important enough to risk even further delay of ipsec deployment (which is also a form of denial-of-service attack :) In other words, if any of these discussion cannot be resolved by Memphis leave it the way it is now and go forward. Hugo ----------------------------- Note follows ------------------------------ Received: from mailhub1.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2R4) with TCP; Tue, 25 Mar 97 12:19:36 EST Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [9.2.250.12]) by mailhub1.watson.ibm.com (8.8.2/01-15-97) with ESMTP id MAA43726; Tue, 25 Mar 1997 12:19:35 -0500 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by igw2.watson.ibm.com (8.7.6/8.7.1) with ESMTP id MAA24364; Tue, 25 Mar 1997 12:18:56 -0500 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA10498 for ipsec-outgoing; Tue, 25 Mar 1997 11:51:56 -0500 (EST) Message-Id: <199703251656.LAA02300@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: daw@cs.berkeley.edu (David Wagner) Cc: ipsec@ex.tis.com Subject: Re: Proposed changes to ESP (andf a little AH too) In-Reply-To: daw's message of 24 Mar 1997 22:33:06 -0800. <5h7rj2$ng6@joseph.cs.berkeley.edu> Date: Tue, 25 Mar 1997 11:56:26 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > > The main argument against doing encryption first and auth second would > > be - generally speaking there is no guarantee even if you verified the > > CIPHERTEXT correctly, that the PLAINTEXT finally obtained is the same > > as was sent. > > That's a robustness argument against authenticating the ciphertext, > and a pretty good one if the decryption routine is complicated. > > However, if the decryption is simple & easy to analyze, we can (mostly) > put to rest those fears about authenticating ciphertext. It's also the case that the bulk of the protocols which will likely be used inside ESP (IP, UDP, TCP) already use a simple 16-bit checksum, which will cause most garbled traffic to be dropped. If we assume that errors where the ciphertext is authenticated but the decryption is garbled will most likely occur during debugging of new code or manual keying, then that would seem to be an acceptable risk; the operator(s) will interpret 99.998% packet loss as 100% packet loss and start debugging.. We merely need to specify that the IP checksum MUST be supplied on transmission and verified on receipt for packets nested inside ESP. - Bill From owner-ipsec Tue Mar 25 14:39:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA12164 for ipsec-outgoing; Tue, 25 Mar 1997 14:38:26 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.16.19970325133743.373f1152@pop3.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Mar 1997 14:44:50 -0500 To: Rodney Thayer From: Stephen Kent Subject: Re: replay mandatory? Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Rodney, I think I see the source of your confusion. Anti-replay is not designed to ensure that TCP receives packets in order. The ordering of packets for delivery to an application is a TCP function and we should not try to usurp that function at the IP layer. Our only goal for anti-replay in AH and ESP is to detect and reject (authentic) packets that we have already received. We use an integrity-protected, monotonically increasing sequence number in AH or ESP for anti-replay purposes. Thus an IPSEC implementation can reject a duplacate packet merely by examining the sequence number and comparing it to the window maintained for the SA via which the packet arrived. By choosing windows that are 32-bit multiples, one can mainatin a bit map to easily track pacets that arrive outr of order, but within the (trailing, sliding) window. See Jim Hughes code in one of his I-Ds for details. Thus we can achieve the anti-replay goal without buffering ANY packets in IPSEC. TCP still needs to buffer packets, to allow for out-of-order arrival, but the buffer pool arrangemetts should be the same as before. That's a TCP, not an IP, function, and anti-replay will not change this buffering and re-oredering task for TCP. However, TCP already does this just fine and IPsec anti-replay will protect TCP implementations from having to buffer bogus packets. Steve From owner-ipsec Thu Mar 27 15:16:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA00687 for ipsec-outgoing; Thu, 27 Mar 1997 15:07:17 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 27 Mar 1997 15:12:55 -0500 To: ipsec@tis.com From: Stephen Kent Subject: new I-Ds, etc. Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, Extensively revised versions of the AH and ESP specs have been submitted as I-Ds. I'll send out the formatted versions to the list as well, to help speed up the distribution process. Please forgive the receipt of moderately large documents later today. The changes to the documents represent an attempt to unify the document structure for IPsec (to do away with the proliferation of "transform" documents), and to make some substantive changes that promise better efficiency and effectiveness, and simplier impelmentations. For example, the new AH spec should suffice, with its reference to HMAC and the indirect references to MD5 and SHA-1, to encopmass all of the previously described AH transforms. Any new algorithms that might be added for AH use can be described in very brief documents that need not reproduce packet syntax, etc. Similarly, the new ESP spec attempts to capture all of the essential features of all of the proposed ESP transforms. (No inclusion of compression for now, but it will be easy to add the necessary placeholders if the WG elects to do so.) We do need a revised spec for DES CBC, with explicit and implicit IVs but without reference to all the other fields, and then the transition to the revised spec format shold be complete (for the default algorithm sets). New algorithms should be described in short, focused documents that need not describe the rest of the packet, other security services, etc. Combinations of services and algorithms are definbed through the ISAKMP negotiations, thus doing away with the need for additional documents to describe all the precommended combinations of services and algorithms. If nothing else, we will save lots of trees (and electrons?) through this consolidation strategy. Implementors will have fewer documents to read and there will be fewer opportunities for inconsistency. All of the sunstantive changes to the AH and ESP specs have been discussed on the list, and most were briefed at the last WG meeting, in San Jose. Although I will not be in Memphis, Nina Yuan has worked with me on these specs and will be there to provide briefings on the I-Ds and on the architecture document (see below). We look forward to receiving any feedback that will further improve the quality of these important specs. We hope for speed approval by the WG, so that we can move to last call and issue new RFCs that reflect the nature of the current, evolved AH and ESP designs and implementations. I am sorry to say that the architecture document is not among the newly released I-Ds. I have decided to re-write this document from scratch: (zero-based budgeting?). This decision was motivated by several observations: - the extensive changes in the AH and ESP documents - descovery of a number of architectural issues that need to be addressed but were not included in previous versions of the document (and some of which have not received extensive discussion on the mailing list) In this latter category are several important issues that we will be raising on the list (after Memphis). The plan is to propose language for the architecture document for each major issue, with supporting analysis for the proposal, and to reach concensus before incorporating the text (or a revised verison of the text) into the new document. The list of issues to be addressed in this fashion include: - proper handling of the DF bit and processing of ICMP PMTU messages - requirements for selectors (filters) for SA bundles, in integrated host, bump-in-the-stack, bump-in-the-wire and security gateway implementations - header and option copying in tunnel mode, for both inbound and outbound traffic, in hosts and gateways - a uniform mechanism for extracting autehntication and/or encryption keys for use with AH and ESP, based on ISAKMP exchanges - a mechanism for discovering and verifying the authorization of security gateways As you can see, we have a few things to discuss and resolve before we can calim to have a complete architecture for IPsec, even though we have made a lot of progress so far and we have nailed down a number of architectural issues. As noted above, we will begin sedning out messages (one per topic) for each of these issues, after Memphis, with the intent to having resolution of the issues and a new architecture I-D well before Munich. Steve From owner-ipsec Thu Mar 27 15:22:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA00796 for ipsec-outgoing; Thu, 27 Mar 1997 15:21:58 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="============_-1352627887==_============" Date: Thu, 27 Mar 1997 15:22:08 -0500 To: ipsec@tis.com From: Stephen Kent Subject: new AH spec (big message) Sender: owner-ipsec@ex.tis.com Precedence: bulk --============_-1352627887==_============ Content-Type: text/plain; charset="us-ascii" --============_-1352627887==_============ Content-Type: text/plain; name="AH_Final_(formatted)"; charset="us-ascii" Content-Disposition: attachment; filename="AH_Final_(formatted)" Network Working Group Stephen Kent, BBN Corp Internet Draft Randall Atkinson, @Home Network draft-ietf-ipsec-auth-04.txt 26 March 1997 IP Authentication Header 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 its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of 6 months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. This particular Internet Draft is a product of the IETF's IPng and IPsec Working Groups. It is intended that a future version of this draft will be submitted for consideration as a standards-track document. Distribution of this document is unlimited. Kent, Atkinson [Page 1] Internet Draft IP Authentication Header 26 March 1997 Table of Contents 1. Introduction......................................................3 2. Authentication Header Format......................................4 2.1 Next Header...................................................4 2.2 Payload Length................................................4 2.3 Reserved......................................................4 2.4 Security Parameters Index (SPI)...............................5 2.5 Sequence Number...............................................5 2.6 Authentication Data ..........................................5 3. Authentication Header Processing..................................5 3.1 Authentication Header Location...............................5 3.2 Outbound Packet Processing...................................8 3.2.1 Security Association Lookup.............................8 3.2.2 Sequence Number Field...................................8 3.2.3 Integrity Check Value Calculation.......................8 3.2.3.1 Handling Mutable Fields............................8 3.2.3.1.1 ICV Computation for IPv4......................9 3.2.3.1.2 ICV Computation for IPv6......................9 3.2.3.2 Padding...........................................10 3.2.3.2.1 Authentication Data Padding..................10 3.2.3.2.2 Implicit Packet Padding......................10 3.2.3.3 Authentication Algorithms.........................10 3.2.4 Fragmentation..........................................11 3.3 Inbound Packet Processing...................................11 3.3.1 Reassembly.............................................11 3.3.2 Security Association Lookup............................11 3.3.3 Sequence Number Verification...........................11 3.3.4 Integrity Check Value Verification.....................12 4. Conformance Requirements.........................................13 5. Security Considerations..........................................13 Acknowledgements....................................................13 References..........................................................14 Disclaimer..........................................................15 Author Information..................................................15 Kent, Atkinson [Page 2] Internet Draft IP Authentication Header 26 March 1997 1. Introduction The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams (hereafter referred to as just "authentication"), and to provide protection against replays. This latter, optional service may be selected when a Security Association is established. AH provides authentication for as much of the IP header as possible, as well as for upper level protocol data. However, some IP header fields may change in transit and the value of these fields, when the packet arrives at the receiver, may not be predictable by the transmitter. The values of such fields cannot be protected by AH. Thus the protection provided to the IP header by AH is somewhat piecemeal. AH may be applied alone, in combination with the IP Encapsulating Security Payload (ESP) [KA97b], or in a nested fashion through the use of tunnel mode (see below). Security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. ESP may be used to provide the same security services, and it also provides an optional confidentiality (encryption) service. The primary difference between ESP and AH, when used for authentication, is the extent of the coverage. Specifically, ESP does not protect any IP header fields unless those fields are encapsulated by ESP. For more details on how to use AH and ESP in various network environments, see "Security Architecture for the Internet Protocol" [KA97a]. It is assumed that the reader is familiar with the terms and concepts described in the document "Security Architecture for the Internet Protocol" [KA97a]. In particular, the reader should be familiar with the definitions of security services offered by AH (and by ESP), the concept of Security Associations, the different key management options available for AH (and ESP), and the ways in which AH can be used in conjunction with ESP. Kent, Atkinson [Page 3] Internet Draft IP Authentication Header 26 March 1997 2. Authentication Header Format +---------------+---------------+---------------+---------------+ | Next Header(8)| Payload Len(8)| RESERVED (16) | +---------------+---------------+---------------+---------------+ | Security Parameters Index (32) | +---------------+---------------+---------------+---------------+ | Sequence Number Field (32) | +---------------+---------------+---------------+---------------+ | | + Authentication Data (variable number of 32-bit words) | | | +---------------+---------------+---------------+---------------+ 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 The following subsections define the fields that comprise the AH format. "Optional" means that the field is omitted if the option is not selected, i.e., it is present in neither the packet as transmitted nor as formatted for computation of the Integrity Check Value (ICV). Whether or not an option is selected is defined as part of the Security Association. In contrast, "mandatory" fields are always present in the AH format. 2.1 Next Header The Next Header is an 8-bit field that identifies the type of the next payload after the Authentication Header. The value of this field is chosen from the set of IP Protocol Numbers defined in the most recent "Assigned Numbers" [STD-2] RFC from the Internet Assigned Numbers Authority (IANA). The Next Header field is mandatory. 2.2 Payload Length This 8-bit field specifies the length of AH, in 32-bit words (4-byte units), minus "2," i.e., the fixed portion of AH is not counted. The minimum value is 0, which is used only in the degenerate case of a "null" authentication algorithm. The Payload Length field is mandatory. *** Do we want to retain a null authentication algorithm as part of the *** spec at this point? What purpose does it serve? 2.3 Reserved This 16-bit field is reserved for future use. It MUST be set to "zero." (Note that the value is included in the Authentication Data calculation, but is otherwise ignored by the recipient.) The Kent, Atkinson [Page 4] Internet Draft IP Authentication Header 26 March 1997 Reserved field is mandatory. 2.4 Security Parameters Index (SPI) The SPI is an arbitrary 32-bit value identifying the Security Association for this datagram (relative to the destination IP address contained in the IP header with which this security header is associated). The set of SPI values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use; a reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC. A value of zero indicates that no Security Association exists. The SPI field is mandatory. It is ordinarily selected by the destination system upon establishment of an SA (see "Security Architecture for the Internet Protocol" [KA97a] for more details). *** Under what circumstances will a zero SPI be employed? Is this *** still relevant or is it vestigial? 2.5 Sequence Number This unsigned 32-bit field contains a monotonically increasing counter value (sequence number). The counter is initialized to 1 when an SA is established. The sequence number must never be allowed to cycle; thus, it MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of 2^32-1 packets on an SA. The Sequence Number field is optional. It is included only if the anti- replay service (a form of loose sequence integrity) is selected as a security service for the SA. 2.6 Authentication Data This is a variable-length field that contains the Integrity Check Value (ICV) for this packet. The field must be an integral multiple of 32 bits in length. The details of the ICV computation are described in Section 3.2.3 below. This field may include explicit padding. This padding is included to ensure that the length of the AH header is an integral multiple of 32 bits (IPv4) or 64 bits (IPv6). All implementations MUST support such padding. Details of how to compute the required padding length are provided in Section 3.2.3.2.1 below. The Authentication Data field is mandatory. 3. Authentication Header Processing 3.1 Authentication Header Location Like ESP, AH may be employed in two ways: transport mode or tunnel mode. The former mode is applicable only to host implementations and Kent, Atkinson [Page 5] Internet Draft IP Authentication Header 26 March 1997 provides protection for upper layer protocols, in addition to selected IP header fields. In this mode, AH is inserted after the IP header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. In the context of IPv4, this calls for placing AH after the IP header (and any options that it contains), but before the upper layer protocol. (Note that the term "transport" mode should not be misconstrued as restricting its use to TCP and UDP. For example, an ICMP message MAY be sent using either "transport" mode or "tunnel" mode.) The following diagram illustrates AH transport mode positioning for a typical IPv4 packet, on a "before and after" basis. BEFORE APPLYING AH ---------------------------- IPv4 |orig IP hdr | | | |(any options)| TCP | Data | ---------------------------- AFTER APPLYING AH --------------------------------- IPv4 |orig IP hdr | | | | |(any options)| AH | TCP | Data | --------------------------------- |<------ authenticated ------->| except for mutable fields In the IPv6 context, AH is viewed as an end-to-end payload, and thus should appear after hop-by-hop, routing, and fragmentation extension headers. The destination options extension header(s) could appear either before or after the AH header depending on the semantics desired. The following diagram illustrates AH transport mode positioning for a typical IPv6 packet. Kent, Atkinson [Page 6] Internet Draft IP Authentication Header 26 March 1997 BEFORE APPLYING AH --------------------------------------- IPv6 | | ext hdrs | | | | orig IP hdr |if present| TCP | Data | --------------------------------------- AFTER APPLYING AH ------------------------------------------------------------ IPv6 | |hxh,rtg,frag| dest | | dest | | | |orig IP hdr |if present**| opt* | AH | opt* | TCP | Data | ------------------------------------------------------------ |<-------------------- authenticated --------------------->| except for mutable fields * = if present, could be before AH, after AH, or both ** = hop by hop, routing, fragmentation headers Tunnel mode AH may be employed in either hosts or security gateways. When AH is implemented in a security gateway (to protect subscriber transit traffic), tunnel mode must be used. In tunnel mode, the "inner" IP header carries the ultimate source and destination addresses, while an "outer" IP header may contain distinct IP addresses, e.g., addresses of security gateways. In tunnel mode, AH protects the entire inner IP packet, including the entire inner IP header. The position of AH in tunnel mode, relative to the outer IP header, is the same as for AH in transport mode. The following diagram illustrates AH tunnel mode positioning for typical IPv4 and IPv6 packets. ------------------------------------------------ IPv4 | new IP hdr* | | orig IP hdr* | | | |(any options)| AH | (any options) |TCP | Data | ------------------------------------------------ |<---------------- authenticated ------------->| except for mutable fields -------------------------------------------------------------- IPv6 | | ext hdrs*| | | ext hdrs*| | | |new IP hdr*|if present| AH |orig IP hdr*|if present|TCP|Data| -------------------------------------------------------------- |<---------------------- authenticated --------------------->| except for mutable fields * = construction of outer IP hdr/extensions and modification of inner IP hdr/extensions is discussed below. Kent, Atkinson [Page 7] Internet Draft IP Authentication Header 26 March 1997 3.2 Outbound Packet Processing In transport mode, the transmitter inserts the AH header after the IP header and before an upper layer protocol header, as described above. In tunnel mode, the outer and inner IP header/extensions can be inter-related in a variety of ways. The construction of the outer IP header/extensions during the encapsulation process is described in the document, "Security Architecture for the Internet Protocol". 3.2.1 Security Association Lookup AH is applied to an outbound packet only after an IPsec implementation determines that the packet is associated with an SA that calls for AH processing. The process of determining what, if any, IPsec processing is applied to outbound traffic is described in the document, "Security Architecture for the Internet Protocol". 3.2.2 Sequence Number Field If the anti-replay service has been selected for this SA, the transmitter increments the sequence number for this SA, checks to ensure that the counter has not cycled, and inserts the new value into the Sequence Number Field. A transmitter MUST not send a packet on an SA if doing so would cause the sequence number to cycle. 3.2.3 Integrity Check Value Calculation 3.2.3.1 Handling Mutable Fields The AH ICV is computed over IP header fields that are either immutable in transit or that are predictable in value upon arrival at the endpoint for the AH SA. The ICV also encompasses the upper level protocol data, which is assumed to be immutable in transit. If a field is modified during transit, the value of the field is set to zero for purposes of the ICV computation. If a field is mutable, but its value at the (IPsec) receiver is predictable, then that value is inserted into the field for purposes of the ICV calculation. The Authentication Data field also is set to zero in preparation for this computation. (Note that by replacing each field's value with zero, rather than omitting the field, alignment is preserved for the ICV calculation.) DISCUSSION: For IPv4 (unlike IPv6), there is no mechanism for tagging options as mutable in transit. Hence the IPv4 options are explicitly listed here and classified as either mutable or immutable. For IPv4, the entire option is viewed as a unit; so even though the Kent, Atkinson [Page 8] Internet Draft IP Authentication Header 26 March 1997 type and length fields within most options are immutable in transit, if an option is classified as mutable, the entire option is zeroed for ICV computation purposes. The mutable IPv4 header fields also are enumerated below. The ICV calculation is restricted to the immutable options and (base) header fields. 3.2.3.1.1 ICV Computation for IPv4 The IPv4 base header fields "Time to Live", "Header Checksum", "Offset", "Flags", and "Type of Service" are zeroed prior to the computation of the ICV. (The TOS field is included here because some routers are known to change the value of this field, even though the IP specification does not consider TOS to be a mutable header field.) *** What about OFFSET and FLAGS. Since reassembly takes place before *** AH processing why are these fields omitted from the ICV *** computation? The following IPv4 options are mutable: record route, timestamp, loose source routing, and strict source routing. These options are treated as zero-filled for purposes of the ICV computation. The IP Security Options, BSO and ESO (RFC-1038, RFC-1108) and the CIPSO (option number 134) option are included in the ICV calculation and are not zeroed. 3.2.3.1.2 ICV Computation for IPv6 In IPv6, the "Hop Limit" field in the IPv6 base header is zeroed prior to performing the ICV calculation. IPv6 options contain a bit that indicates whether the option might change during transit. For any option for which contents may change en-route, the entire "Option Data" field must be treated as zero-valued octets when computing or verifying the ICV. The Option Type and Opt Data Len are included in the ICV calculation. All other options are also included in the ICV calculation. See the IPv6 specification [DH95] for more information. Note that the IPv6 Routing Header "Type 0" will rearrange the address fields within the packet during transit from source to destination. However, the contents of the packet as it will appear at the receiver are known to the sender and to all intermediate hops. Hence, the IPv6 Routing Header "Type 0" is included in the Authentication Data calculation as an immutable option. The transmitter must order the field so that it appears as it will at the receiver, prior to performing the ICV computation. *** Do we want to make any recommendation for what an AH implementation *** should do if it encounters an unfamiliar IPv6 extension header, Kent, Atkinson [Page 9] Internet Draft IP Authentication Header 26 March 1997 *** e.g., Routing Header "Type 1" (aka Nimrod)? 3.2.3.2 Padding 3.2.3.2.1 Authentication Data Padding As mentioned in section 2.6, the Authentication Data field explicitly includes padding to ensure that the AH header is a multiple of 32 bits (IPv4) or 64 bits (IPv6). If padding is required, its length is determined by three factors: - the presence or absence of the Sequence Number field - the length of the ICV - the IP protocol context (v4 or v6) For example, if the Sequence Number field is present and a default, 96-bit truncated HMAC algorithm is selected, no padding is required for either IPv4 nor IPv6. In contrast, if the anti-replay service is not selected, and a default 96-bit truncated HMAC algorithm is selected, no padding is required for IPv4, but 4 bytes of padding are required for IPv6. The content of the padding field is arbitrarily selected by the sender. (The padding is arbitrary, but need not be random to achieve security.) These bytes are included in the Authentication Data calculation, counted as part of the Payload Length, and transmitted at the end of the Authentication Data field to enable the receiver to perform the ICV calculation. 3.2.3.2.2 Implicit Packet Padding For some authentication algorithms, the byte string over which the ICV computation is performed must be a multiple of a blocksize specified by the algorithm. If the IP packet length (including AH) does not match the blocksize requirements for the algorithm, implicit padding MUST be appended to the end of the packet, prior to ICV computation. The padding octets MUST have a value of zero. The blocksize (and hence the length of the padding) is specified by the algorithm specification. This padding is not transmitted with the packet. 3.2.3.3 Authentication Algorithms The authentication algorithm employed for the ICV computation is specified by the SA. For point-to-point communication, suitable authentication algorithms include keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (e.g., DES) or on one-way hash functions (e.g., MD5 or SHA-1). For multicast communication, one-way hash algorithms combined with asymmetric signature algorithms are suitable. As of this writing, the mandatory-to-implement authentication algorithms are based on the Kent, Atkinson [Page 10] Internet Draft IP Authentication Header 26 March 1997 former class, i.e., HMAC [KBC97] with SHA-1 [SHA] or HMAC with MD5 [Riv92]. The output of the HMAC computation is truncated to (the leftmost) 96 bits. Other algorithms, possibly with different ICV lengths, MAY be supported. 3.2.4 Fragmentation If required, IP fragmentation occurs after AH processing within an IPsec implementation. However, an IP packet to which AH has been applied may itself be fragmented by routers en route, including security gateways that may apply AH or ESP (tunnel mode) to the already-protected packet or fragments. 3.3 Inbound Packet Processing 3.3.1 Reassembly If required, reassembly is performed prior to AH processing. 3.3.2 Security Association Lookup Upon receipt of a packet containing an IP Authentication Header, the receiver determines the appropriate (unidirectional) SA, based on the destination IP address and the SPI. (This process is described in more detail in the document, "Security Architecture for the Internet Protocol".) The SA will indicate whether the Sequence Number field should be present, will specify the algorithm(s) employed for ICV computation, and will indicate the key(s) required to validate the ICV. If no valid Security Association exists for this session (e.g., the receiver has no key), the receiver MUST discard the packet and the failure MUST be recorded in an audit log. The log entry SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID. The log entry MAY also include other identifying data. There is no requirement for the receiver to transmit any message to the purported transmitter in response to receipt of such packets (because of the potential to induce denial of service via such actions). 3.3.3 Sequence Number Verification If the anti-replay service has been selected for this SA, the receiver MUST verify that the packet contains a Sequence Number that does not duplicate the Sequence Number of any other packets received during the life of this SA. This SHOULD be the first AH check applied to a packet after it has been matched to an SA, to speed rejection of duplicate packets. Kent, Atkinson [Page 11] Internet Draft IP Authentication Header 26 March 1997 Duplicates are rejected through the use of a sliding receive window. (How the window is implemented is a local matter, but the following text describes the functionality that the implementation must exhibit.) The default window size is 32 and all AH implementations MUST support this window size. A larger window size MAY be established during SA negotiation. If a larger window size is negotiated it MUST be a multiple of 32. The "right" edge of the window represents the highest, validated Sequence Number value received on this SA. Packets that contain Sequence Number values lower than the "left" edge of the window are rejected. Packets falling within the window are checked against a list of received packets within the window. An efficient means for performing this check, based on the use of a bit mask, is described in [KA97a]. If the received packet falls within the window, then the receiver proceeds to ICV verification. If the ICV validation fails, the receiver MUST discard the received IP datagram as invalid and MUST record the authentication failure in an audit log. If such a failure occurs, the log entry MUST include the SPI value, date/time received, Sending Address, Destination Address, and (in IPv6) Flow ID. The log data MAY also include other information about the failed packet. The window is updated only if the ICV verification succeeds. DISCUSSION: Note that if the packet is either inside the window and new, or outside the window on the "right" side, the receiver MUST authenticate the Sequence Number field before updating the bit mask (either turning on a bit or updating the "right" side of the window). 3.3.4 Integrity Check Value Verification The receiver computes the ICV over the appropriate fields of the packet, using the specified authentication algorithm, and verifies that it is the same as the ICV included in the Authentication Data field of the packet. Details of the computation are provided below. If the computed and received ICV's match, then the datagram is valid, and it is accepted. If the test fails, then the receiver MUST discard the received IP datagram as invalid and MUST record the authentication failure in an audit log. The log data MUST include the SPI value, date/time received, Source Address, Destination Address, and (in IPv6) the Flow ID. The log data also MAY include other information about the failed packet. Kent, Atkinson [Page 12] Internet Draft IP Authentication Header 26 March 1997 DISCUSSION: Begin by saving the ICV value and replacing it (but not any Authentication Data padding) with zero. Zero all other fields that may have been modified during transit. (See section 3.2.3.1 for a discussion of which fields are zeroed before performing the ICV calculation.) Check the overall length of the packet, and if it requires implicit padding based on the requirements of the authentication algorithm, append zero-filled bytes to the end of the packet as required. Now perform the ICV computation and compare the result with the received value. (If a digital signature and one-way hash are used for the ICV computation, the matching process is more complex and will be described in the algorithm specification.) 4. Conformance Requirements Implementations that claim conformance or compliance with this specification MUST fully implement the AH syntax and processing described here and MUST comply with all requirements of the "Security Architecture for the Internet Protocol." Note that support for manual key distribution is required, but its use is inconsistent with the anti-replay service, and thus a compliant implementation must not negotiate this service in conjunction with SAs that are manually keyed. A compliant AH implementation MUST support the following mandatory-to-implement algorithms (specified in [KBC97]): - HMAC with MD5 - HMAC with SHA-1 5. Security Considerations Security is central to the design of this protocol, and this security considerations permeate the specification. Additional security- relevant aspects of using IPsec protocol are discussed in the document, "Security Architecture for the Internet Protocol". Acknowledgements For over 2 years, this document has evolved through multiple versions and iterations. During this time, many people have contributed significant ideas and energy to the process and the documents themselves. The authors would like to thank the members of the IPsec and IPng working groups, with special mention of the efforts of (in alphabetic order): Steve Bellovin, Steve Deering, Francis Dupont, Phil Karn, Frank Kastenholz, Perry Metzger, David Mihelcic, Hilarie Kent, Atkinson [Page 13] Internet Draft IP Authentication Header 26 March 1997 Orman, and William Simpson. In addition, Charlie Lynn, Karen Seo, and Nina Yuan provided extensive help in the review and editing of this version of the specification. References [BCCH94] R. Braden, D. Clark, S. Crocker, & C.Huitema, "Report of IAB Workshop on Security in the Internet Architecture", RFC- 1636, 9 June 1994, pp. 21-34. [Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, No. 2, March 1989. [CER95] Computer Emergency Response Team (CERT), "IP Spoofing Attacks and Hijacked Terminal Connections", CA-95:01, January 1995. Available via anonymous ftp from info.cert.org in /pub/cert_advisories. [DH95] Steve Deering & Bob Hinden, "Internet Protocol version 6 (IPv6) Specification", RFC-1883, December 1995. [GM93] James Galvin & Keith McCloghrie, Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2), RFC-1446, April 1993. [KBC97] Hugo Krawczyk, Mihir Bellare, and Ran Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC-2104, February 1997. [Ken91] Steve Kent, "US DoD Security Options for the Internet Protocol", RFC-1108, November 1991. [KA96a] Steve Kent, Randall Atkinson, "Security Architecture for the Internet Protocol", Internet Draft, ?? 1997. [KA96b] Steve Kent, Randall Atkinson, "IP Encapsulating Security Payload (ESP)", Internet Draft, March 1997. [KA96c] Steve Kent, Randall Atkinson, "IP Authentication Header", Internet Draft, March 1997. [Riv92] Ronald Rivest, MD5 Digest Algorithm, RFC-1321, April 1992. [SHA] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995 [STD-1] J. Postel, "Internet Official Protocol Standards", STD-1, Kent, Atkinson [Page 14] Internet Draft IP Authentication Header 26 March 1997 March 1996. [STD-2] J. Reynolds & J. Postel, "Assigned Numbers", STD-2, 20 October 1994. Disclaimer The views and specification here are those of the authors and are not necessarily those of their employers. The authors and their employers specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this specification. Author Information Stephen Kent BBN Corporation 70 Fawcett Street Cambridge, MA 02140 USA Telephone: +1 (617) 873-3988 Randall Atkinson @Home Network 385 Ravendale Drive Mountain View, CA 94043 USA Kent, Atkinson [Page 15] --============_-1352627887==_============-- From owner-ipsec Thu Mar 27 15:26:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA00835 for ipsec-outgoing; Thu, 27 Mar 1997 15:26:33 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Date: Thu, 27 Mar 1997 15:22:38 -0500 To: ipsec@tis.com From: Stephen Kent Subject: new ESP spec (bigger message) Sender: owner-ipsec@ex.tis.com Precedence: bulk --============_-1352627881==_============ Content-Type: text/plain; charset="us-ascii" --============_-1352627881==_============ Content-Type: text/plain; name="ESP_final_(formatted)"; charset="us-ascii" Content-Disposition: attachment; filename="ESP_final_(formatted)" Network Working Group Stephen Kent, BBN Corp Internet Draft Randall Atkinson, @Home Network draft-ietf-ipsec-esp-03.txt 26 March 1997 IP Encapsulating Security Payload (ESP) 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 its working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of 6 months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as "work in progress". This particular Internet Draft is a product of the IETF's IPng and IPsec working groups. It is intended that a future version of this draft be submitted to the IPng Area Directors and the IESG for possible publication as a standards-track protocol. Kent, Atkinson [Page 1] Internet Draft IP Encapsulating 26 March 1997 Security Payload (ESP) Table of Contents 1. Introduction......................................................3 2. Encapsulating Security Payload Packet Format......................4 2.1 Security Parameters Index....................................4 2.2 Sequence Number .............................................5 2.3 Initialization Vector........................................5 2.4 Payload Data.................................................5 2.5 Padding (for encryption).....................................6 2.6 Pad Length...................................................6 2.7 Next Header..................................................6 2.8 Authentication Data..........................................6 3. Encapsulating Security Protocol Processing........................7 3.1 ESP Header Location..........................................7 3.2 Outbound Packet Processing...................................9 3.2.1 Security Association Lookup.............................9 3.2.2 Anti-replay Service.....................................9 3.2.3 Packet Encryption.......................................9 3.2.3.1 Scope of Encryption.................................9 3.2.3.2 Encryption Algorithms..............................10 3.2.4 Integrity Check Value Calculation......................10 3.2.4.1 Scope of Authentication Protection................10 3.2.4.2 Authentication Padding............................10 3.2.4.3 Authentication Algorithms.........................11 3.2.5 Fragmentation..........................................11 3.3 Inbound Packet Processing...................................11 3.3.1 Pre-ESP Processing Overview............................11 3.3.2 Security Association Lookup............................11 3.3.3 Anti-replay Service....................................12 3.3.4 Integrity Check Value Verification.....................13 3.3.5 Packet Decryption......................................13 4. Conformance Requirements.........................................14 5. Security Considerations..........................................14 Acknowledgements....................................................14 References..........................................................15 Disclaimer..........................................................17 Author Information..................................................17 Kent, Atkinson [Page 2] Internet Draft IP Encapsulating 26 March 1997 Security Payload (ESP) 1. Introduction The Encapsulating Security Payload (ESP) header is designed to provide a mix of optional security services in IPv4 and IPv6. ESP may be applied alone, in combination with the IP Authentication Header (AH) [KA97b], or in a nested fashion, e.g., through the use of tunnel mode (see below). Security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. For more details on how to use ESP and AH in various network environments, see "Security Architecture for the Internet Protocol" [KA97a]. The ESP header is inserted after the IP header and before the upper layer protocol header (transport mode) or the encapsulated IP header (tunnel mode). These modes are described in more detail below. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, anti-replay service (a form of sequence integrity), and limited traffic flow confidentiality. The set of services provided depends on options selected at the time of Security Association establishment and the implementation placement. Confidentiality may be selected independent of all other services. Data origin authentication and connectionless integrity are joint services (hereafter referred to jointly as "authentication), independent of confidentiality. An anti-replay service may be selected only if data origin authentication is selected, but it is independent of confidentiality. Traffic flow confidentiality depends on confidentiality, and requires selection of tunnel mode. It is assumed that the reader is familiar with the terms and concepts described in the document "Security Architecture for the Internet Protocol" [KA97a]. In particular, the reader should be familiar with the definitions of security services offered by ESP (and by AH), the concept of Security Associations, the different key management options available for ESP (and AH), and the ways in which ESP can be used in conjunction with the Authentication Header (AH). Kent, Atkinson [Page 3] Internet Draft IP Encapsulating 26 March 1997 Security Payload (ESP) 2. Encapsulating Security Payload Packet Format +---------------+---------------+---------------+---------------+ ---- | Security Parameters Index (SPI), (32 bits) | ^ +---------------+---------------+---------------+---------------+ | | Sequence Number (32 bits) | | +---------------+---------------+---------------+---------------+ Auth/ | Initialization Vector (variable) | Integrity + + Coverage | | | +---------------+---------------+---------------+---------------+ | ----- | Payload Data (variable) | | ^ - - | | | | | | + +---------------+---------------+---------------+ | Confid. | | Padding (0-255 bytes) | | Coverage +---------------+ +---------------+---------------+ | | | | Pad Length(8) | Next Header(8)| v v +---------------+---------------+---------------+---------------+ -------- | Authentication Data (variable) | - - | | +---------------+---------------+---------------+---------------+ 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 The following subsections define the fields in the header format. "Optional" means that the field is omitted if the option is not selected, i.e., it is present in neither the packet as transmitted nor as formatted for computation of an ICV. Whether or not an option is selected is defined as part of Security Association (SA) establishment. Thus the format of ESP packets for a given SA is fixed, for the duration of the SA. In contrast, "mandatory" fields are always present in the ESP packet format, for all SAs. 2.1 Security Parameters Index The SPI is an arbitrary 32-bit value identifying the Security Association for this datagram (relative to the destination IP address contained in the IP header with which this security header is associated). The set of SPI values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use; a reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC. A value of zero indicates that no Security Association exists. (Note that the SPI is similar to the SAID used in other security protocols. The name has been changed because the semantics used here are not exactly the same as those used in other security protocols.) Kent, Atkinson [Page 4] Internet Draft IP Encapsulating 26 March 1997 Security Payload (ESP) ***Under what circumstances will a zero SPI be employed? Is this ***vestigial, or is there still a use for a zero SPI? Is it a SKIP ***support feature of some sort? The SPI field is mandatory, and its value is ordinarily selected by the destination system upon establishment of an SA (see "Security Architecture for the Internet Protocol" for more details.) 2.2 Sequence Number This unsigned 32-bit field contains a monotonically increasing counter value (sequence number). The counter is initialized to 1 when an SA is established. The Sequence Number must never be allowed to cycle; thus, it MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of 2^32-1 packets on an SA. The Sequence Number is optional. It is only included if the anti- replay service is selected as a security service for the SA. Since the anti-replay service requires selection of the authentication service as well, the Sequence Number MUST not be present in the absence of the Authentication Data field (described below.) 2.3 Initialization Vector This is a variable-length field used only when an explicit IV is required by the selected encryption algorithm, mode or device. The length of the IV is dependent upon the choice of encryption algorithm, and is established during SA negotiation. The IV field is optional, but all implementations must be capable of generating and processing this field if they support algorithms or devices that require an explicit IV. 2.4 Payload Data Payload Data is a variable-length field containing data described by the Next Header field. This field is an integral number of bytes in length. The Payload Data field is mandatory. ***We have a potential IPv6 alignment problem here, that may have ***been present for some time. Ignoring the presence or absence of an ***iv, the payload data will not be aligned on an 8-byte boundary if ***the Sequence Number is omitted. This may cause a problem for ***efficient crypto data transfer. If the IV is present, and the ***Sequence Number is omitted, the same problem arises, starting with ***the IV, unless the IV is of a compensating size. The decryption ***process can fix the problem for higher layer protocols, because the ***output buffer from decryption is usually distinct from the input Kent, Atkinson [Page 5] Internet Draft IP Encapsulating 26 March 1997 Security Payload (ESP) ***buffer, but that still causes potential problems for transfer of ***data to the crypto module. Also, if encryption is not employed, ***this becomes a potential problem for authentication data being ***passed up. We could solve this by adding an optional alignment ***field to the ESP header, when required for IPv6. What do people think? 2.5 Padding (for Encryption) If the confidentiality service has been selected, the Padding field is used to fill the Payload Data to a multiple of the blocksize required by the encryption algorithm. This blocksize requirement is a parameter of the algorithm negotiated during SA establishment. If encryption has not been selected, the Padding field is used to align the Next Header field so that the last bit of that field ends on a 32-bit boundary. The Padding bytes SHOULD be initialized with random data and they are transmitted. The transmitter can add 0-255 bytes of padding. Padding beyond that required for encryption algorithm blocksize alignment may be used to conceal the actual length of the payload, in support of traffic flow confidentiality. However, inclusion of such additional padding has adverse bandwidth implications and thus its use should be undertaken with care. The Padding field is optional, but all implementations MUST support generation and consumption of padding. 2.6 Pad Length The Pad Length field indicates the number of pad bytes immediately preceding it. The range of valid values is 0-255, where a value of zero indicates that the byte immediately preceding the pad length field is the last byte of the payload. The Pad Length field is mandatory. 2.7 Next Header The Next Header is an 8-bit field that identifies the type of data contained in the Payload Data field, e.g., an extension header in IPv6 or an upper layer protocol identifier. The value of this field is chosen from the set of IP Protocol Numbers defined in the most recent "Assigned Numbers" [STD-2] RFC from the Internet Assigned Numbers Authority (IANA). The Next Header field is mandatory. 2.8 Authentication Data The Authentication Data is a variable-length field containing an Integrity Check Value (ICV) computed over the ESP packet minus the Kent, Atkinson [Page 6] Internet Draft IP Encapsulating 26 March 1997 Security Payload (ESP) Authentication Data. The length of the field depends upon the authentication function selected. The mandatory-to-implement authentication algorithms, HMAC with MD5 or SHA-1, both yield 96-bit ICVs because of the truncation convention adopted for use in IPsec. The Authentication Data field is optional. 3. Encapsulating Security Protocol Processing 3.1 ESP Header Location Like AH, ESP may be employed in two ways: transport mode or tunnel mode. The former mode is applicable only to host implementations and provides protection for upper layer protocols, but not the IP header. In this mode, ESP is inserted after the IP header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. In the context of IPv4, this translates to placing ESP after the IP header (and any options that it contains), but before the upper layer protocol. (Note that the term "transport" mode should not be misconstrued as restricting its use to TCP and UDP. For example, an ICMP message MAY be sent using either "transport" mode or "tunnel" mode.) The following diagram illustrates ESP transport mode positioning for a typical IPv4 packet, on a "before and after" basis. (The "ESP trailer" encompasses any Padding, plus the Pad Length, and Next Header fields.) BEFORE APPLYING ESP ---------------------------- IPv4 |orig IP hdr | | | |(any options)| TCP | Data | ---------------------------- AFTER APPLYING ESP ------------------------------------------------- IPv4 |orig IP hdr | | | | ESP | ESP| |(any options)| ESP | TCP | Data | Trailer |Auth| ------------------------------------------------- |<----- encrypted ---->| |<------ authenticated ----->| In the IPv6 context, ESP is viewed as an end-to-end payload, and thus should appear after hop-by-hop, routing, and fragmentation extension headers. The destination options extension header(s) could appear either before or after the ESP header depending on the semantics desired. However, since ESP protects only fields after the ESP header, it generally may be desirable to place the destination options header(s) after the ESP header. The following diagram illustrates ESP transport mode positioning for a typical IPv6 packet. Kent, Atkinson [Page 7] Internet Draft IP Encapsulating 26 March 1997 Security Payload (ESP) BEFORE APPLYING ESP --------------------------------------- IPv6 | | ext hdrs | | | | orig IP hdr |if present| TCP | Data | --------------------------------------- AFTER APPLYING ESP --------------------------------------------------------- IPv6 | orig |hxh,rtg,frag|dest| |dest| | | ESP | ESP| |IP hdr|if present**|opt*|ESP|opt*|TCP|Data|Trailer|Auth| --------------------------------------------------------- |<---- encrypted ---->| |<---- authenticated ---->| * = if present, could be before AH, after AH, or both ** = hop by hop, routing, fragmentation headers Tunnel mode ESP may be employed in either hosts or security gateways. When ESP is implemented in a security gateway (to protect subscriber transit traffic), tunnel mode must be used. In tunnel mode, the "inner" IP header carries the ultimate source and destination addresses, while an "outer" IP header may contain distinct IP addresses, e.g., addresses of security gateways. In tunnel mode, ESP protects the entire inner IP packet, including the entire inner IP header. The position of ESP in tunnel mode, relative to the outer IP header, is the same as for ESP in transport mode. The following diagram illustrates ESP tunnel mode positioning for typical IPv4 and IPv6 packets. ----------------------------------------------------------- IPv4 | new IP hdr* | | orig IP hdr* | | | ESP | ESP| |(any options)| ESP | (any options) |TCP|Data|Trailer|Auth| ----------------------------------------------------------- |<--------- encrypted ---------->| |<----------- authenticated ---------->| --------------------------------------------------------------- IPv6 | new* | ext hdrs*| | orig*| ext hdrs*| | | ESP | ESP| |IP hdr|if present|ESP|IP hdr|if present|TCP|Data|Trailer|Auth| --------------------------------------------------------------- |<---------- encrypted ----------->| |<----------- authenticated ---------->| * = construction of outer IP hdr/extensions and modification of inner IP hdr/extensions is discussed below. Kent, Atkinson [Page 8] Internet Draft IP Encapsulating 26 March 1997 Security Payload (ESP) 3.2 Outbound Packet Processing In transport mode, the transmitter encapsulates the upper layer protocol information in the ESP header/trailer, and retains the specified IP header (and any IP extension headers in the IPv6 context). In tunnel mode, the outer and inner IP header/extensions can be inter-related in a variety of ways. The construction of the outer IP header/extensions during the encapsulation process is described in the document, "Security Architecture for the Internet Protocol". 3.2.1 Security Association Lookup ESP is applied to an outbound packet only after an IPsec implementation determines that the packet is associated with an SA that calls for ESP processing. The process of determining what, if any, IPsec processing is applied to outbound traffic is described in the document, "Security Architecture for the Internet Protocol". 3.2.2 Anti-replay Service If the anti-replay service has been selected for this SA, the transmitter increments the Sequence Number for this SA, checks to ensure that the counter has not cycled, and inserts the new value into the Sequence Number field. A transmitter MUST NOT send a packet on an SA if doing so would cause the Sequence Number to cycle. As mentioned in section 2.2, the anti-replay service requires the selection of the authentication services thus the Sequence Number field MUST NOT be present in the absence of the Authentication Data field (described below.) 3.2.3 Packet Encryption 3.2.3.1 Scope of Encryption In transport mode, if encryption has been selected, the transmitter encapsulates the original upper layer protocol information into the ESP payload field, adds any necessary padding, and encrypts the result (Payload Data, Padding, Pad Length, and Next Header) using the key, encryption algorithm, and algorithm mode indicated by the SA. In tunnel mode, the transmitter encapsulates and encrypts the the entire original IP datagram (plus the Padding, Pad Length, and Next Header). If both encryption and authentication have been selected, encryption is performed first, before the authentication and the encryption does Kent, Atkinson [Page 9] Internet Draft IP Encapsulating 26 March 1997 Security Payload (ESP) not encompass the Authentication Data field. This order of processing facilitates rapid detection and rejection of replayed or bogus packets by the receiver, prior to decrypting the packet, hence potentially reducing the impact of denial of service attacks. It also allows for the possibility of parallel processing of packets at the receiver, i.e., decryption can take place in parallel with authentication. Note that since the Authentication Data is not protected by encryption, a keyed authentication algorithm must be employed to compute the ICV. 3.2.3.2 Encryption Algorithms If confidentiality is selected, the encryption algorithm employed is specified by the SA. ESP is designed for use with symmetric encryption algorithms. Because IP packets may arrive out of order, each packet must carry either an explicit Initialization Vector (IV) that allows the receiver to establish cryptographic synchronization for decryption, or data derived from the packet header must suffice to generate an IV at the receiver. Since ESP makes provision for padding of the plaintext, encryption algorithms employed with ESP may exhibit either block or stream mode characteristics. At the time of writing, one mandatory-to-implement encryption algorithm and mode has been defined for ESP. It is based on the Data Encryption Standard (DES) [NIST77] in Cipher Block Chaining Mode [NIST80]. Details of use of this mode are contained in [need a new I-D with DES-CBC and implicit IV generation, but no overlap with this document]. 3.2.4 Integrity Check Value Calculation 3.2.4.1 Scope of Authentication Protection If authentication is selected for the SA, the transmitter computes the ICV over the ESP packet minus the Authentication Data. Thus the SPI, Sequence Number (if present), Initialization Vector (if present), Payload Data, Padding (if present), Pad Length, and Next Header are all encompassed by the ICV computation. If encryption has been selected, the last 4 fields will be in ciphertext form. 3.2.4.2 Authentication Padding For some authentication algorithms, the byte string over which the ICV computation is performed must be a multiple of a blocksize specified by the algorithm. If the length of this byte string does not match the blocksize requirements for the algorithm, implicit padding MUST be appended to the end of the ESP packet, prior to ICV Kent, Atkinson [Page 10] Internet Draft IP Encapsulating 26 March 1997 Security Payload (ESP) computation. The padding octets MUST have a value of zero. The blocksize (and hence the length of the padding) is specified by the algorithm specification. This padding is not transmitted with the packet. 3.2.4.3 Authentication Algorithms The authentication algorithm employed for the ICV computation is specified by the SA. For point-to-point communication, suitable authentication algorithms include keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (e.g., DES) or on one-way hash functions (e.g., MD5 or SHA-1). For multicast communication, one-way hash algorithms combined with asymmetric signature algorithms are suitable. As of this writing, the mandatory-to-implement authentication algorithms are based on the former class, i.e., HMAC [KBC97] with SHA-1 [SHA] or HMAC with MD5 [Riv92]. The output of the HMAC computation is truncated to (the leftmost) 96 bits. Other algorithms, possibly with different ICV lengths, MAY be supported. 3.2.5 Fragmentation If necessary, fragmentation is performed after ESP processing within an IPsec implementation. However, an IP packet to which ESP has been applied may itself be fragmented by routers en route, including security gateways that may apply AH or ESP (tunnel mode) to the already-protected packet or fragments. 3.3 Inbound Packet Processing 3.3.1 Pre-ESP Processing Overview If required, reassembly is performed prior to ESP processing. 3.3.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 and the SPI. (This process is described in more detail in the document, "Security Architecture for the Internet Protocol".) The SA indicates whether the Sequence Number, Initialization Vector, and Authentication Data fields should be present, and it will specify the algorithms and keys to be employed for decryption and ICV computations (if applicable). If no valid Security Association exists for this session (for example, the receiver has no key), the receiver MUST discard the Kent, Atkinson [Page 11] Internet Draft IP Encapsulating 26 March 1997 Security Payload (ESP) packet and the failure MUST be recorded in an audit log. The log entry MUST include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the cleartext Flow ID. The log entry MAY also include other identifying data. There is no requirement for the receiver to transmit any message to the purported transmitter in response to receipt of such packets (because of the potential to induce denial of service via such actions). 3.3.3 Anti-replay Service If the anti-replay service has been selected for this SA, the receiver MUST verify that the packet contains a Sequence Number value that does not duplicate the Sequence Number of any other packet received during the life of this SA. This SHOULD be the first AH check applied to a packet after it has been matched to an SA, to speed rejection of duplicate packets. Duplicates are rejected through the use of a sliding receive window. (How the window is implemented is a local matter, but the following text describes the functionality that the implementation must exhibit.) The default window size is 32 and all AH implementations MUST support this window size. A larger window size MAY be established during SA negotiation. If a larger window size is negotiated it MUST be a multiple of 32. The "right" edge of the window represents the highest, validated Reply Protection value received on this SA. Packets that contain Sequence Numbers lower than the "left" edge of the window are rejected. Packets falling within the window are checked against a list of received packets within the window. An efficient means for performing this check, based on the use of a bit mask, is described in [KA97a]. If the received packet falls within the window, then the receiver proceeds to ICV verification. If the ICV validation fails, the receiver MUST discard the received IP datagram as invalid and MUST record the authentication failure in an audit log. If such a failure occurs, the log entry MUST include the SPI value, date/time received, Sending Address, Destination Address, and (in IPv6) Flow ID. The log data MAY also include other information about the failed packet. The window is updated only if the ICV verification succeeds. DISCUSSION: Note that if the packet is either inside the window and new, or outside the window on the "right" side, the receiver MUST authenticate the Sequence Number before updating the Sequence Kent, Atkinson [Page 12] Internet Draft IP Encapsulating 26 March 1997 Security Payload (ESP) Number window data. 3.3.4 Integrity Check Value Verification If authentication has been selected, the receiver computes the ICV over the ESP packet minus the Authentication Data using the specified authentication algorithm and verifies that it is the same as the ICV included in the Authentication Data field of the packet. Details of the computation are provided below. If the computed and received ICV's match, then the datagram is valid, and it is accepted. If the test fails, then the receiver MUST discard the received IP datagram as invalid and MUST record the authentication failure in an audit log. The log data MUST include the SPI value, date/time received, Source Address, Destination Address, and (in IPv6) the clear-text Flow ID. The log data MAY also include other information about the failed packet. DISCUSSION: Begin by removing and saving the ICV value (Authentication Data field). Next check the overall length of the ESP packet minus the Authentication Data. If implicit padding is required, based on the blocksize of the authentication algorithm, append zero-filled bytes to the end of the ESP packet directly after the Next Header field. Perform the ICV computation and compare the result with the received value. (If a digital signature and one-way hash are used for the ICV computation, the matching process is more complex and will be described in the algorithm specification.) 3.3.5 Packet Decryption If data confidentiality was selected, the receiver decrypts the ESP Payload Data, Padding, Pad Length, and Next Header using the session key that has been established for this traffic. If an explicit IV is present, it is input to the decryption algorithm as per the algorithm specification. If an implicit IV is employed, a local version of the IV is constructed and input to the decryption algorithm as per the algorithm specification. (Decryption may take place in parallel with authentication, but care must be taken to avoid possible race conditions with regard to packet access and reconstruction of the decrypted packet.) After decryption, the original IP datagram is reconstructed and processed per the normal IP protocol specification. The exact steps for reconstructing the original datagram depend on the mode (tunnel Kent, Atkinson [Page 13] Internet Draft IP Encapsulating 26 March 1997 Security Payload (ESP) vs transport) and are described in the document, "Security Architecture for the Internet Protocol." Note that there are two ways in which the decryption can "fail". The selected SA may not be correct or the encrypted ESP packet could be corrupted. (The latter case would be detected if authentication is selected for the SA, as would tampering with the SPI. However, an SA mismatch might still occur due to tampering with the IP Destination Address.) In either case, the erroneous result of the decryption operation (an invalid IP datagram or transport-layer frame) will not necessarily be detected by IPsec, and is the responsibility of later protocol processing. 4. Conformance Requirements Implementations that claim conformance or compliance with this specification MUST implement the ESP syntax and processing described here and MUST comply with all requirements of the "Security Architecture for the Internet Protocol." Note that support for manual key distribution is required, but its use is inconsistent with anti-replay service, and thus a compliant implementation must not negotiate this service in conjunction with SAs that are manually keyed. A compliant ESP implementation MUST support the following mandatory-to-implement algorithms (specified in [KBC97] and in [need a new I-D with DES-CBC and implicit IV generation, but no overlap with this document]. - DES in CBC mode - HMAC with MD5 - HMAC with SHA-1 5. Security Considerations Security is central to the design of this protocol, and this security considerations permeate the specification. Additional security- relevant aspects of using IPsec protocol are discussed in the document, "Security Architecture for the Internet Protocol". Acknowledgements Many of the concepts embodied in this specification were derived from or influenced by the US Government's SP3 security protocol, ISO/IEC's NLSP, or from the proposed swIPe security protocol. [SDNS89, ISO92 IB93]. For over 2 years, this document has evolved through multiple versions Kent, Atkinson [Page 14] Internet Draft IP Encapsulating 26 March 1997 Security Payload (ESP) and iterations. During this time, many people have contributed significant ideas and energy to the process and the documents themselves. The authors would like to thank the members of the IPSEC and IPng working groups, with special mention of the efforts of (in alphabetic order): Steve Bellovin, Steve Deering, Phil Karn, Perry Metzger, David Mihelcic, Hilarie Orman, and William Simpson. In addition, Charlie Lynn, Karen Seo, and Nina Yuan provided extensive help in the review and editing of this version of the specification. References [Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, No. 2, March 1989. [CERT95] Computer Emergency Response Team (CERT), "IP Spoofing Attacks and Hijacked Terminal Connections", CA-95:01, January 1995. Available via anonymous ftp from info.cert.org. [DH95] Steve Deering & Robert Hinden, Internet Protocol Version 6 (Ipv6) Specification, RFC 1883, December 1995. [IB93] John Ioannidis & Matt Blaze, "Architecture and Implementation of Network-layer Security Under Unix", Proceedings of the USENIX Security Symposium, Santa Clara, CA, October 1993. [ISO92] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, International Standards Organisation, Geneva, Switzerland, 29 November 1992. [KBC97] Hugo Krawczyk, Mihir Bellare, and Ran Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC-2104, February 1997. [Ken91] Steve Kent, "US DoD Security Options for the Internet Protocol (IPSO)", RFC-1108, November 1991. [KA97a] Steve Kent, Randall Atkinson, "Security Architecture for the Internet Protocol", Internet Draft, ?? 1997. [KA97b] Steve Kent, Randall Atkinson, "IP Authentication Header", Internet Draft, March 1997. [MS95] Perry Metzger & W.A. Simpson, "The ESP DES-CBC Transform", RFC-1829, August 1995. Kent, Atkinson [Page 15] Internet Draft IP Encapsulating 26 March 1997 Security Payload (ESP) [NIST77] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46, January 1977. [NIST80] US National Bureau of Standards, "DES Modes of Operation" Federal Information Processing Standard (FIPS) Publication 81, December 1980. [NIST81] US National Bureau of Standards, "Guidelines for Implementing and Using the Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 74, April 1981. [NIST88] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46-1, January 1988. [Riv92] Ronald Rivest, MD5 Digest Algorithm, RFC-1321, April 1992. [SHA] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995 [STD-2] J. Reynolds and J. Postel, "Assigned Numbers", STD-2, 20 October 1994. [Sch94] Bruce Schneier, Applied Cryptography, John Wiley & Sons, New York, NY, 1994. ISBN 0-471-59756-2 [SDNS89] SDNS Secure Data Network System, Security Protocol 3, SP3, Document SDN.301, Revision 1.5, 15 May 1989, as published in NIST Publication NIST-IR-90-4250, February 1990. Kent, Atkinson [Page 16] Internet Draft IP Encapsulating 26 March 1997 Security Payload (ESP) Disclaimer The views and specification here are those of the authors and are not necessarily those of their employers. The authors and their employers specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this specification. Author Information Stephen Kent BBN Corporation 70 Fawcett Street Cambridge, MA 02140 USA Telephone: +1 (617) 873-3988 Randall Atkinson @Home Network 385 Ravendale Drive Mountain View, CA 94043 USA Kent, Atkinson [Page 17] --============_-1352627881==_============-- From owner-ipsec Thu Mar 27 17:43:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA01775 for ipsec-outgoing; Thu, 27 Mar 1997 17:41:49 -0500 (EST) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199703272247.OAA00326@kebe.eng.sun.com> Subject: Re: new AH spec To: kent@bbn.com (Stephen Kent) Date: Thu, 27 Mar 1997 14:47:11 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: from "Stephen Kent" at Mar 27, 97 03:22:08 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 I guess someone has to toss out the first feedback. > IP Authentication Header > 1. Introduction Looks good so far. The bit about "piecemeal" might be a bit strong, but that's really hairsplitting. > 2. Authentication Header Format > *** Do we want to retain a null authentication algorithm as part of the > *** spec at this point? What purpose does it serve? Mostly, the NULL authentication algorithm is used for testing of protocol plumbing. I don't expect any shipping product to have a null authentication algorithm. I do expect AH implementations that are in their nascent stages to have a null authentication algorithm. Interpret this data as you will w.r.t. how the spec should read. > 2.4 Security Parameters Index (SPI) > A value of zero indicates that no Security Association exists. The SPI > field is mandatory. It is ordinarily selected by the destination > system upon establishment of an SA (see "Security Architecture for > the Internet Protocol" [KA97a] for more details). > > *** Under what circumstances will a zero SPI be employed? Is this > *** still relevant or is it vestigial? A zero SPI is useful for any number of implementation-specific aids. An example I can think of off the top of my head is that if my getassocybyendpoint() call for an outgoing datagram returns an association with a zero SPI, I can interpret this as any number of results (including, "I just kicked key management in the rear, I'll get back to you.") > 2.5 Sequence Number > > This unsigned 32-bit field contains a monotonically increasing > counter value (sequence number). The counter is initialized to 1 > when an SA is established. The sequence number must never be allowed > to cycle; thus, it MUST be reset (by establishing a new SA and thus a > new key) prior to the transmission of 2^32-1 packets on an SA. The > Sequence Number field is optional. It is included only if the anti- > replay service (a form of loose sequence integrity) is selected as a > security service for the SA. I know certain people who have issues about having this field NOT being present. I don't have a problem with this, but I suspect the people who have these issues will speak up. See the newly issued HMAC-96 drafts for details. > 3. Authentication Header Processing > > 3.1 Authentication Header Location > > Like ESP, AH may be employed in two ways: transport mode or tunnel > mode. The former mode is applicable only to host implementations and > provides protection for upper layer protocols, in addition to > selected IP header fields. In this mode, AH is inserted after the IP > header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. BTW, ESP is one of these upper-layer protocol fields. In fact, lemme return to this upper-layer protocol idea in a bit. > In the IPv6 context, AH is viewed as an end-to-end payload, and thus > should appear after hop-by-hop, routing, and fragmentation extension > headers. The destination options extension header(s) could appear > either before or after the AH header depending on the semantics > desired. The following diagram illustrates AH transport mode > positioning for a typical IPv6 packet. > > BEFORE APPLYING AH > --------------------------------------- > IPv6 | | ext hdrs | | | > | orig IP hdr |if present| TCP | Data | > --------------------------------------- > > AFTER APPLYING AH > ------------------------------------------------------------ > IPv6 | |hxh,rtg,frag| dest | | dest | | | > |orig IP hdr |if present**| opt* | AH | opt* | TCP | Data | > ------------------------------------------------------------ > |<-------------------- authenticated --------------------->| > except for mutable fields > > * = if present, could be before AH, after AH, or both > ** = hop by hop, routing, fragmentation headers This isn't _quite_ accurate. Destination options CAN appear before or after AH. But the semantic of destination options is very precise. From RFC 1883... IPv6 | Hop-by-Hop | Destination | Routing | Fragment.... If Destination options appear before AH, they appear before the routing header. The semantics being that the destination options are parsed on each hop specified in the routing header. This might be hairsplitting, but others who are IPv6/IPsec implementors might get confused. > The position of AH in tunnel mode, relative to the outer IP > header, is the same as for AH in transport mode. This sentence is more important than is apparent at first. An implementation can look at the inner IP header as JUST ANOTHER UPPER LAYER. This helps reduce some of the special-casing for IP as the inner payload. It doesn't _ELIMINATE_ it, but it can reduce it. (For example, if you have A->B with the inner IP saying A->B, you can make stronger assertions than if the inner packet says something else.) > 3.2 Outbound Packet Processing > > In transport mode, the transmitter inserts the AH header after the IP > header and before an upper layer protocol header, as described above. > In tunnel mode, the outer and inner IP header/extensions can be > inter-related in a variety of ways. The construction of the outer IP > header/extensions during the encapsulation process is described in > the document, "Security Architecture for the Internet Protocol". ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Hmmm. I'm looking forward to this. > 3.2.1 Security Association Lookup > > AH is applied to an outbound packet only after an IPsec > implementation determines that the packet is associated with an SA > that calls for AH processing. The process of determining what, if > any, IPsec processing is applied to outbound traffic is described in > the document, "Security Architecture for the Internet Protocol". Once again, I'm looking forward to this. As an aside, I'd strongly encourage to look at the current implementations out there, as well as some of the analysis literature. I suspect you've already done your homework on this front and will be drawing on their experience when you finish rewhacking the architecture document. > 3.2.2 Sequence Number Field > > If the anti-replay service has been selected for this SA, the > transmitter increments the sequence number for this SA, checks to > ensure that the counter has not cycled, and inserts the new value > into the Sequence Number Field. A transmitter MUST not send a packet > on an SA if doing so would cause the sequence number to cycle. Do you have any recommendations for when the sequence number cycles? (Kick key mgmt. in the pants, logging, tuning future SAs to expire sooner, etc.) > 3.2.3 Integrity Check Value Calculation > > 3.2.3.1 Handling Mutable Fields > 3.2.3.1.1 ICV Computation for IPv4 > *** What about OFFSET and FLAGS. Since reassembly takes place before > *** AH processing why are these fields omitted from the ICV > *** computation? Except for perhaps DF, these FLAGS and OFFSET SHOULD be zero anyway after reassembly! The question of DF is perhaps why the decision was made to just zero out that bit too. > 3.2.3.1.2 ICV Computation for IPv6 > *** Do we want to make any recommendation for what an AH implementation > *** should do if it encounters an unfamiliar IPv6 extension header, > *** e.g., Routing Header "Type 1" (aka Nimrod)? IMHO, new IPv6 extensions should document their own AH properties. Keep in mind this is IMHO only. > 3.2.3.2 Padding > > 3.2.3.2.1 Authentication Data Padding > > As mentioned in section 2.6, the Authentication Data field explicitly > includes padding to ensure that the AH header is a multiple of 32 > bits (IPv4) or 64 bits (IPv6). If padding is required, its length is > determined by three factors: > - the presence or absence of the Sequence Number field > - the length of the ICV > - the IP protocol context (v4 or v6) > > For example, if the Sequence Number field is present and a default, > 96-bit truncated HMAC algorithm is selected, no padding is required > for either IPv4 nor IPv6. In contrast, if the anti-replay service is > not selected, and a default 96-bit truncated HMAC algorithm is > selected, no padding is required for IPv4, but 4 bytes of padding are > required for IPv6. The content of the padding field is arbitrarily > selected by the sender. (The padding is arbitrary, but need not be > random to achieve security.) These bytes are included in the > Authentication Data calculation, counted as part of the Payload > Length, and transmitted at the end of the Authentication Data field > to enable the receiver to perform the ICV calculation. Thank you! We in IPv6-land appreciate this. > 3.2.3.3 Authentication Algorithms > > The authentication algorithm employed for the ICV computation is > specified by the SA. For point-to-point communication, suitable > authentication algorithms include keyed Message Authentication Codes > (MACs) based on symmetric encryption algorithms (e.g., DES) or on > one-way hash functions (e.g., MD5 or SHA-1). For multicast > communication, one-way hash algorithms combined with asymmetric > signature algorithms are suitable. As an aside, has anyone tackled this? A lightweight digital signature algorithm would be perfect in a multicast environment with a small number of senders compared with an arbitrary number of receivers. LARGE number of senders, however, requires Real Work (TM). > As of this writing, the mandatory-to-implement authentication algorithms > are based on the former class, i.e., HMAC [KBC97] with SHA-1 [SHA] or > HMAC with MD5 [Riv92]. The output of the HMAC computation is truncated > to (the leftmost) 96 bits. Other algorithms, possibly with different > ICV lengths, MAY be supported. Like I mentioned before, as currently written, these I-Ds _always_ include the replay counter. The replay counter is set to 0 for associations that don't use replay. > 3.3 Inbound Packet Processing > 3.3.3 Sequence Number Verification > > If the anti-replay service has been selected for this SA, the > receiver MUST verify that the packet contains a Sequence Number that > does not duplicate the Sequence Number of any other packets received > during the life of this SA. This SHOULD be the first AH check > applied to a packet after it has been matched to an SA, to speed > rejection of duplicate packets. Ummm, what if I live in a multithreaded world? I can theoretically get two packets near-concurrently with the same sequence number. If the bogus one arrives first, do I trash the good one just because one with the same replay number arrived first? Or do I not count a sequence number as "good" until I've authenticated? Or is this just an implementation detail? Or is this why it says SHOULD rather than MUST? > DISCUSSION: > > Note that if the packet is either inside the window and new, or > outside the window on the "right" side, the receiver MUST > authenticate the Sequence Number field before updating the bit > mask (either turning on a bit or updating the "right" side of the > window). Ahhhh, I get it now. I left the questions in because this is how some might think as they read it. I guess that's it for pass one. As I see more things, I'll report them. Dan From owner-ipsec Thu Mar 27 17:52:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA01881 for ipsec-outgoing; Thu, 27 Mar 1997 17:52:23 -0500 (EST) From: touch@isi.edu Date: Thu, 27 Mar 1997 14:57:40 -0800 Posted-Date: Thu, 27 Mar 1997 14:57:40 -0800 Message-Id: <199703272257.AA18146@ash.isi.edu> To: kent@bbn.com, Dan.McDonald@Eng.sun.com Subject: Re: new AH spec Cc: ipsec@tis.com X-Auto-Sig-Adder-By: faber@isi.edu Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Dan.McDonald@eng.sun.com (Dan McDonald) > > 2.4 Security Parameters Index (SPI) > > > A value of zero indicates that no Security Association exists. The SPI > > field is mandatory. It is ordinarily selected by the destination > > system upon establishment of an SA (see "Security Architecture for > > the Internet Protocol" [KA97a] for more details). > > > > *** Under what circumstances will a zero SPI be employed? Is this > > *** still relevant or is it vestigial? > > A zero SPI is useful for any number of implementation-specific aids. An > example I can think of off the top of my head is that if my > getassocybyendpoint() call for an outgoing datagram returns an association > with a zero SPI, I can interpret this as any number of results (including, "I > just kicked key management in the rear, I'll get back to you.") But under what circumstances would you set the SPI in the outgoing datagram to zero - wouldn't you wait?? (I can't send it and hope to resolve it later - what if I have several pending key mgt requests, then I can't distinguish which packets use which associations later) Joe ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/ From owner-ipsec Thu Mar 27 17:54:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA01896 for ipsec-outgoing; Thu, 27 Mar 1997 17:53:54 -0500 (EST) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199703272259.OAA00476@kebe.eng.sun.com> Subject: Re: new AH spec To: touch@isi.edu Date: Thu, 27 Mar 1997 14:59:11 -0800 (PST) Cc: kent@bbn.com, Dan.McDonald@Eng.sun.com, ipsec@tis.com In-Reply-To: <199703272257.AA18146@ash.isi.edu> from "touch@ISI.EDU" at Mar 27, 97 02:57:40 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 > But under what circumstances would you set the SPI in the outgoing datagram > to zero - wouldn't you wait?? Oops, my bad. On the WIRE you'll NEVER see a zero SPI. I was arguing that the value 0 should continue to be reserved. Pardon the confusion, folks! Dan From owner-ipsec Thu Mar 27 18:29:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA02041 for ipsec-outgoing; Thu, 27 Mar 1997 18:29:07 -0500 (EST) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199703272334.PAA00564@kebe.eng.sun.com> Subject: Re: new ESP spec (bigger message) To: kent@bbn.com (Stephen Kent) Date: Thu, 27 Mar 1997 15:34:28 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: from "Stephen Kent" at Mar 27, 97 03:22:38 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 Note that many of my questions were covered in AH already. > IP Encapsulating Security Payload (ESP) > 2. Encapsulating Security Payload Packet Format > 2.1 Security Parameters Index > 2.4 Payload Data > > Payload Data is a variable-length field containing data described by > the Next Header field. This field is an integral number of bytes in > length. The Payload Data field is mandatory. > > ***We have a potential IPv6 alignment problem here, that may have > ***been present for some time. Ignoring the presence or absence of an > ***iv, the payload data will not be aligned on an 8-byte boundary if > ***the Sequence Number is omitted. This may cause a problem for > ***efficient crypto data transfer. If the IV is present, and the > ***Sequence Number is omitted, the same problem arises, starting with > ***the IV, unless the IV is of a compensating size. The decryption > ***process can fix the problem for higher layer protocols, because the > ***output buffer from decryption is usually distinct from the input > ***buffer, but that still causes potential problems for transfer of > ***data to the crypto module. Also, if encryption is not employed, > ***this becomes a potential problem for authentication data being > ***passed up. We could solve this by adding an optional alignment > ***field to the ESP header, when required for IPv6. What do people think? This isn't a real problem for IPv6. The reason for the 8-byte alignment drive in IPv6 was to make fast-path processing faster. (Those of us with UltraSPARC appreciate this.) Since ESP is already beating down the slow path, this isn't as huge of a deal as one might think at first. Also, a properly formed IPv6 datagram will be 8-byte aligned once you strip out the ESP cruft after decryption. There's always crypto-algorithm alignment issues, but I leave those to the crypto wizards. > 3. Encapsulating Security Protocol Processing See my previous note about IPv6 destination option semantics, tunnel-mode not being all that different, and outbound SA selection. > 3.2.3 Packet Encryption > > 3.2.3.1 Scope of Encryption > > In transport mode, if encryption has been selected, the transmitter > encapsulates the original upper layer protocol information into the > ESP payload field, adds any necessary padding, and encrypts the > result (Payload Data, Padding, Pad Length, and Next Header) using the > key, encryption algorithm, and algorithm mode indicated by the SA. > In tunnel mode, the transmitter encapsulates and encrypts the the > entire original IP datagram (plus the Padding, Pad Length, and Next > Header). > > If both encryption and authentication have been selected, encryption > is performed first, before the authentication and the encryption does > not encompass the Authentication Data field. This order of > processing facilitates rapid detection and rejection of replayed or > bogus packets by the receiver, prior to decrypting the packet, hence > potentially reducing the impact of denial of service attacks. It > also allows for the possibility of parallel processing of packets at > the receiver, i.e., decryption can take place in parallel with > authentication. Note that since the Authentication Data is not > protected by encryption, a keyed authentication algorithm must be > employed to compute the ICV. You've seen my comments on this (reversing the order of authentication and encryption) already. > 3.2.4.3 Authentication Algorithms > > The authentication algorithm employed for the ICV computation is > specified by the SA. For point-to-point communication, suitable > authentication algorithms include keyed Message Authentication Codes > (MACs) based on symmetric encryption algorithms (e.g., DES) or on > one-way hash functions (e.g., MD5 or SHA-1). For multicast > communication, one-way hash algorithms combined with asymmetric > signature algorithms are suitable. As of this writing, the > mandatory-to-implement authentication algorithms are based on the > former class, i.e., HMAC [KBC97] with SHA-1 [SHA] or HMAC with MD5 > [Riv92]. The output of the HMAC computation is truncated to (the > leftmost) 96 bits. Other algorithms, possibly with different ICV > lengths, MAY be supported. Is the HMAC trunctated for use in ESP?!? I hadn't heard any movement to do so, but I sometimes miss these things. > 3.3 Inbound Packet Processing You've seen some comments about things in here in the AH comments. > 3.3.5 Packet Decryption > > If data confidentiality was selected, the receiver decrypts the ESP > Payload Data, Padding, Pad Length, and Next Header using the session > key that has been established for this traffic. If an explicit IV is > present, it is input to the decryption algorithm as per the algorithm > specification. If an implicit IV is employed, a local version of the > IV is constructed and input to the decryption algorithm as per the > algorithm specification. (Decryption may take place in parallel with > authentication, but care must be taken to avoid possible race > conditions with regard to packet access and reconstruction of the > decrypted packet.) > > After decryption, the original IP datagram is reconstructed and > processed per the normal IP protocol specification. The exact steps > for reconstructing the original datagram depend on the mode (tunnel > vs transport) and are described in the document, "Security > Architecture for the Internet Protocol." Ahh, the stripping of the ESP cruft I was talking about before... :) That's it for this one, Dan From owner-ipsec Thu Mar 27 22:19:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA03208 for ipsec-outgoing; Thu, 27 Mar 1997 22:18:12 -0500 (EST) Message-Id: <199703280320.WAA04052@relay.hq.tis.com> Date: Thu, 27 Mar 97 22:21:16 EST From: Charles Lynn To: ipsec@tis.com cc: Dan McDonald Subject: Re: new AH spec Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, > This isn't _quite_ accurate. > > Destination options CAN appear before or after AH. But the semantic of > destination options is very precise. From RFC 1883... > > IPv6 | Hop-by-Hop | Destination | Routing | Fragment.... > > If Destination options appear before AH, they appear before the routing > header. The semantics being that the destination options are parsed on each > hop specified in the routing header. This might be hairsplitting, but others > who are IPv6/IPsec implementors might get confused. >From RFC 1883: < IPv6|Hop-by-Hop|Destination|Routing|Fragment|AH|ESP|Destination|ULP When Destination options appear before the Routing Header, they are processed at each cluster contained in the Routing Header (including the final destination), as described. When they appear after any AH or ESP, they are only processed by the final destination after the AH and/or ESP processing. The text in the draft is pointing out an extensibility issue. It is often hard to foresee what evolution may happen in the future. Some option, which may be defined in the future, may have an effect that alters how the AH or ESP is to be processed by the final destination. Such an option could not appear before the Routing Header (as it should not be processed at each cluster), and could not appear after the AH and/or ESP as that would be too late to have the intended effect. For example, there is a Destination option that effectively alters the "source" and "destination" "addresses" which are to be use further up the protocol stack, e.g., as used in TCP or UDP "pseudo headers". As currently defined, the SPI is relative to the "destination address". There is no restriction on how an implementor must manage the SPI number space. I.e., an implementor may have a single SPI space per box, or may have one per interface, or even separate spaces for link addresses and global addresses, etc., and then there is multihoming, and the idea of having border routers rewriting addresses of packets that pass through them. There are many issues to be worked out (hopefully we can get the spec out before they are all resolved :-). Lets not write extra code to eliminate flexibility that we might find we want further down the road. Charlie From owner-ipsec Thu Mar 27 22:58:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA03379 for ipsec-outgoing; Thu, 27 Mar 1997 22:58:18 -0500 (EST) Message-Id: <199703280400.XAA04513@relay.hq.tis.com> Date: Thu, 27 Mar 97 23:01:11 EST From: Charles Lynn To: ipsec@tis.com cc: Dan McDonald Subject: Re: new ESP spec (bigger message) Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, +=========+ > > ***We have a potential IPv6 alignment problem | ver ... | > > here, that may have | ESP | ... | src ... | > | | > This isn't a real problem for IPv6. The reason | | > for the 8-byte alignment drive in IPv6 was to make | | > fast-path processing faster. (Those of us with | dst ... | > UltraSPARC appreciate this.) Since ESP is already | | > beating down the slow path, this isn't as huge of | | > a deal as one might think at first. Also, a | | > properly formed IPv6 datagram will be 8-byte +=========+ > aligned once you strip out the ESP cruft after | SPI | > decryption. | IV ... | | | I was under the impression that the 8-byte alignment +---------+ drive was to make processing not incur a lot of | ver ... | address alignment faults when processing IPv6 | TCP | packets. I also heard a desire that IPsec be | src ... | "friendly" to both hardware and software based | | algorithms. If one uses a software algorithm that | | decrypts in place, and have an IPv6 packet that | | begins as shown to the left, then the tunneled IPv6 | dst ... | header, etc., is not aligned, relative to the outer | | one. | | | | One argument for not needing alignment is that +---------+ decryption in place won't be common, as a hardware | TCP Hdr | decryption will "copy" the packet and can be made to | Data | do realignment in the process. | +----+ | |n|IP| Another is that IPv6 header alignment on 64-bit +----+----+ boundaries is not a "requirement", just a "guide line". I do not see any justification why AH and ESP should differ in their requirements to preserve alignment across their headers. Comments anyone? Charlie From owner-ipsec Fri Mar 28 13:03:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA07923 for ipsec-outgoing; Fri, 28 Mar 1997 13:00:35 -0500 (EST) Message-Id: <3.0.32.19970328100436.00925300@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 28 Mar 1997 10:04:37 -0800 To: ipsec@tis.com From: Bob Monsour Subject: Internet Draft on compression Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk All, The attached draft was submitted on Wednesday. Since there is a delay between draft submission and draft annoucement, I wanted to get this in front of the group so you would have enough time to review it. Please feel free to provide comments prior to Memphis. Regards, -Bob Internet Draft March 1997 (Expires September 1997) R. Monsour, Hi/fn Inc. M. Sabin, Consultant A. Shacham, Cisco Systems S. Anand, Microsoft Corporation R. Thayer, Sable Technology Compression in IP Security 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 its 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 (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This draft is intended provide input to the IP Security working group as it sorts through the debate regarding the incorporation of lossless data compression into the IP Security architecture. Comments about this draft should be submitted to the authors or to the IPSEC mailing list (ipsec@tis.com). Abstract This memo discusses the application of lossless compression technology to the IP Security Architecture [IPSecArch]. Over the last few several months, a number of lively debates on this topic have been held on IPSec mailing list. This memo discusses the issues raised, the alternatives available to resolve them and provides a set of recommendations to bring resolution to the issue. The goals of the draft are to: (1) define the problem solved by the use of compression in the context of IPSec, (2) review the use of compression and security technologies as they have been applied in other layers of the protocol stack, (3) outline a set of Monsour, et al [Page 1] INTERNET DRAFT Compression in IP Security March 1996 requirements for applying compression to IPSec, (4) discuss alternative methods which can be implemented to meet the requirements, and (4) propose a set of recommendations for consideration by the working group. Acknowledgments The authors wish to acknowledge the many contributors to the compression debate on the IPSec mailing list. In addition, the concept of compressing prior to encrypting data is drawn from several prior sources, including Rodney Thayer's draft [Thayer], the ECP/CCP protocols under PPP and the TLS protocol (better known as SSL). Table of Contents 1. Introduction 2. Compression in IPSec - Problem Definition 3. Review of Other Protocols Using Compression and/or Security 3.1 Overview 3.2 The Encryption Control Protocol (ECP) 3.3 Transport Layer Security (TLS) 3.4 Application Layer Security 4. Does Compression Fall Within the Scope of the Working Group? 5. Requirements for Applying Compression to IPSec 5.1 Negotiated Algorithm 5.2 Stateless AND Stateful Compression 5.3 Compressed Packet Indicator 5.4 Compatibility with Existing and Emerging Implementations 5.5 Optional Use of Compression 5.6 Ability to Optimize Compression Across Protocol Layers 5.7 Anti-Expansion of Payload Data 6. Alternative Approaches to the Use of Compression in IPSec 6.1 Layered Architecture Using a Separate Compression Header 6.2 Optional Feature of ESP 6.3 Comparison of the Two Approaches 7. Which Approach Meets the Proposed Requirements? 7.1 Negotiated Algorithm 7.2 Stateless AND Stateful Compression 7.3 Compressed Packet Indicator 7.4 Compatibility with Existing and Emerging Implementations 7.5 Optional Use of Compression 7.6 Ability to Optimize Compression Across Protocol Layers 7.7 Anti-Expansion of Payload Data 8. Conclusions 9. Recommendations 10. Security Considerations 11. References 12. Authors' Addresses Monsour, et al [Page 2] INTERNET DRAFT Compression in IP Security March 1996 1. Introduction Encrypted data is random in nature and not compressible. When an IP datagram is encrypted, compression methods used at lower protocol layers -- e.g., the PPP Compression Control Protocol [RFC1962] -- no longer work. If both compression and encryption are desired, compression must be performed first. The IPSec working group of the IETF has been debating the topic of incorporating lossless data compression into the IPSec architecture for the past several months. In fact, the initial introduction of the topic goes as far back as 1994, when Jim Hughes of Network Systems presented the idea at the San Jose meeting of the IPSec working group [Dec96WG]. Following that initial presentation, Network Systems, as well as a handful of other companies have implemented proprietary methods for compressing IP datagrams prior to encrypting them. This memo takes that work, and analyzes similar work done in other security protocols, and proposes a negotiable, interoperable method for applying lossless data compression to the IPSec protocol. The first compression-related drafts were developed in 1996 and three of those drafts were discussed at the December 1996 IPSec working group meeting in San Jose [Thayer][Sabin1][Sabin2]. 2. Compression in IPSec - Problem Definition The widespread use of the internet has resulted in equally widespread use of point-to-point (PPP) connections between hosts as well as between routers. Lossless compression technology has been deployed in the PPP environment in the form of a sub-protocol known as the Compression Control Protocol (CCP). PPP is a connection-oriented protocol. Many lossless compression technologies have the capability to retain state across each "packet" of data that is compressed. Hence, in a connection-oriented protocol such as PPP, compression can be applied to the continuing stream of "packets". The principal advantage to such a stateful mechanism is a higher compression ratio. Another important aspect of the CCP is the negotiability of the compression algorithm for each PPP connection. Today, PPP is the predominant method for end-user hosts to connect to the internet. Compression in CCP provides end users with significant improvements in bandwidth utilization. In a different environment, today's routers that support connections in the T1 range AND use lossless compression technology, provide great economic value to their users. For example, a corporate user Monsour, et al [Page 3] INTERNET DRAFT Compression in IP Security March 1996 employing a leased T1 line can save thousands of dollars per month in line charges through the use of compression technology. The use of encryption technologies at protocol layers higher than the data-link/PPP layer, renders PPP compression ineffective. With the strong demand for secure communications, encryption is actively being deployed at various layers in the protocol stack to meet the security requirements of various environments. The is the core problem which has driven the compression debate in the IPSec working group. 3. Review of Other Protocols Using Compression and/or Security This section provides an overview of several examples of other protocols and applications involving the use of lossless compression technology. Some of the protocols described use compression in conjunction with encryption. 3.1 Overview The diagram below depicts the OSI reference model for data communications protocol layers along with various internet protocols and/or products which incorporate the use of compression and/or security capabilities. These are just a few examples of the technologies being deployed to meet the security and bandwidth requirements of various classes of users and systems. Protocols and/or Protocol Layers Products Compression Security ------------------ ----------- ------------- ------------ +----------------+ | Application | PGPmail yes yes |----------------| | Presentation | HTTPv1.1* yes no |----------------| | Session | TLS/SSL yes yes |----------------| | Transport | TCP** no no |----------------| | Network | IPSec no yes |----------------| | Data Link | PPP/CCP/ECP yes yes |----------------| | Physical | link encryptors no yes +----------------+ link compressors yes no *[RFC2068] Monsour, et al [Page 4] INTERNET DRAFT Compression in IP Security March 1996 **Note: There is discussion within the IETF of taking up work in this area. 3.2 The Encryption Control Protocol (ECP) At the same time that the Compression Control Protocol was defined, a sister protocol, the Encryption Control Protocol (ECP) [RFC1968], was defined. In the ECP protocol, it is clearly noted that if compression has been negotiated for a connection, compression must be performed prior to encryption. As far as the authors can tell at this time, the ECP has not been widely deployed. However, it should also be noted that the PPP Extensions working group [PPPEXT] is currently working on additional security protocols in the areas of authentication and public key technologies. 3.3 Transport Layer Security (TLS) TLS [TLS] (formerly/better known as SSL, the Secure Socket Layer) is a security protocol originally defined and implemented by Netscape Communications Corporation. In the initial draft of TLS 1.0, the use of compression is defined as an optional data transformation which can be used prior to encryption for each packet. In TLS, the selection of compression algorithm is a negotiated property of the session. Since TLS is a connection-oriented protocol, compression state can be maintained from one packet to the next, thereby improving compression ratio. 3.4 Application Layer Security There are several examples of application layer security. Clearly, any application which has requirements for confidentiality in its data flow can implement encryption technology to meet such a security requirement. One example of this is an email application. A secure email client is capable of encrypting messages sent from one host to another. PGPmail [PGPMan], a security add-on to many popular email client products, is one such example. PGPmail provides the capability to compress mail prior to encrypting it. No doubt, this is due to the realization of its developers that subsequent attempts to compress the data at lower layers in the protocol stack will be rendered ineffective. 4. Does Compression Fall Within the Scope of the Working Group? There are several issues which surround the question of whether the IPSec working group should directly consider the issue of applying compression to the IPSec protocols. The IPSec working group charter specifically states: Monsour, et al [Page 5] INTERNET DRAFT Compression in IP Security March 1996 A security protocol in the network layer will be developed to provide cryptographic security services that will flexibly support combinations of authentication, integrity, access control, and confidentiality. The protocol formats for the IP Authentication Header (AH) and IP Encapsulating Security Payload (ESP) will be independent of the cryptographic algorithm. The preliminary goals will specifically pursue host-to-host security followed by subnet-to- subnet and host-to-subnet topologies. Protocol and cryptographic techniques will also be developed to support the key management requirements of the network layer security. The Internet Key Management Protocol (IKMP) will be specified as an application layer protocol that is independent of the lower layer security protocol. The problem definition in section 2 describes the "problem" in terms of the affect of IPSec on a lower-layer protocol. While this is indeed true, it is unclear whether the obligation to provide the detailed protocol "fix" to correct the problem lies within the scope of the IPSec working group. While progress is being made, it is also true that the IPSec specifications have been not been stable and available in a manner to support widespread interoperable implementations (as has been noted by various members of the working group). The user community has indicated their requirement that compression capabilities be "supported" by IPSec implementations. The specific methods used to provide such support are clearly in the scope of the working group to decide. There is currently discussion underway (within the IETF) to explore the application of compression in TCP. This raises a question regarding the potential to provide a consistent mechanism for supporting compression across these two closely- related protocols (TCP & IP). 5. Requirements for Applying Compression to IPSec As noted earlier, the use of encryption at any protocol layer above the data link layer renders PPP compression ineffective. This leads to the need to support the use of compression in the context of IPSec. The question then becomes one of how to provide this support. An understanding of the problem, the approaches taken in other protocol environments, the emerging discussion of compression support in TCP, and the discussions on the mailing list lead to the definition of the following requirements for the technical Monsour, et al [Page 6] INTERNET DRAFT Compression in IP Security March 1996 approaches to support compression in IPSec. 5.1 Negotiated Algorithm Regardless of the protocol for which compression support is provided, a method is required for the two communicating parties to negotiate both the use and the type of compression to be applied to the packets. 5.2 Stateless AND Stateful Compression Since IP is a connectionless/stateless protocol, it is important that each compressed packet be capable of being decompressed independently of any other packet; i.e., the successful decompression of a packet must not depend on the contents of any other packet(s), nor should it depend on order of receipt of any other packet(s). The development of a consistent approach to providing compression capabilities to both IPSec and TCP should support the use of stateful compression in the TCP context. TCP's connection orientation can guarantee packet ordering and thus achieve higher compression ratios. 5.3 Compressed Packet Indicator Once the use of compression is negotiated between two communicating parties, the sender must have the flexibility to determine whether or not to compress each packet. Such flexibility requires a per-packet indication of whether or not the packet is compressed. 5.4 Compatibility with Existing and Emerging Implementations Changes to the IPSec protocol definitions to support compression must not not break any existing implementation. This means that for an implementation to be compression-capable, it will have to be modified, but it will remain compliant with the IPSec protocols without the addition of compression support. This requirement becomes more desirable with the passage of time, as more and more implementations are developed and deployed. 5.5 Optional Use of Compression This requirement derives from the previous requirement. If an existing implementation is to be considered compliant with the IPSec protocol, then it MUST NOT be required to provide support for compression. Monsour, et al [Page 7] INTERNET DRAFT Compression in IP Security March 1996 5.6 Ability to Optimize Compression Across Protocol Layers The use of compression at several layers in the protocol stack can cause inefficiencies in the processing by sending systems. For example, in an environment where application layer compression is in use, it is desirable to communicate to the lower layer protocols that the data is already compressed and that the lower layers need not attempt to compress (read as "waste cycles"). Thus, support for compression in IPSec shall be provide the capability for "turning compression on or off" through some mechanism of inter-layer communication. 5.7 Anti-Expansion of Payload Data It is not possible in all instances to pre-determine if a payload has already been compressed at a higher layer. Future protocol changes could support such a pre-determination. Until then, a mechanism for detecting the expansion of data and optionally sending the original uncompressed payload is required. 6. Alternative Approaches to the Use of Compression in IPSec Two general technical approaches to meet the requirements outlined in previous section have been presented to the working group and subsequently debated on the mailing list. These two approaches are described below along with their relative advantages and disadvantages. 6.1 Layered Architecture Using a Separate Compression Header This approach involves the use of a separate compression header which would follow the IP header and precede the AH and/or ESP header(s). The header would provide all the fields necessary to support compression of either AH and/or ESP payloads as well as support for compression in TCP. 6.2 Optional Feature of ESP This approach is based on the fact that it is the encryption of ESP payloads which renders downstream compression techniques ineffective. This approach is limited to only compressing ESP payloads and does not extend naturally to any upper layer protocols. 6.3 Comparison of the Two Approaches Below is a comparison of the advantages and disadvantages of the two approaches. Monsour, et al [Page 8] INTERNET DRAFT Compression in IP Security March 1996 Advantages Disadvantages ----------------------------------------------------------------- Layered not tied to use some delay in getting Architecture of encryption; i.e., to a standard works with AH payloads as well can be applied to upper layer protocols such as TCP in addition to IPSec routers can more easily determine if a packet is compressed without knowledge of IPSec protocol details Optional Easily defined due to doesn't map well for Feature its limited scope use in upper layer protocols of ESP tied to use of security protocols requires routers to know IPSec to avoid compression processing overhead 7. Which Approach Meets the Proposed Requirements? This section describes how the two approaches described in the previous section meet each of the requirements defined in section 5. 7.1 Negotiated Algorithm Both approaches meet this requirement. ISAKMP provides a method for algorithm negotiation which can easily be extended to support the negotiation of the use and type of compression. In the TCP context, TCP negotiation would be extended to negotiate the use and type of compression. 7.2 Stateless AND Stateful Compression IPSec compression MUST be stateless. Both approaches support this concept. TCP, as a connection-oriented protocol, can support stateful compression and achieve higher compression ratios as a result. The use of the layered architecture approach makes stateful TCP compression possible. Monsour, et al [Page 9] INTERNET DRAFT Compression in IP Security March 1996 7.3 Compressed Packet Indicator In the layered architecture approach, the compression header would contain a field to indicate whether or not the packet is compressed. In the ESP option approach, the most-significant bit of the pad length field has been proposed to serve this function. 7.4 Compatibility with Existing and Emerging Implementations Since compression is a negotiated option in both approaches, they both meet this requirement. Existing implementations will not negotiate to use compression and will continue to interoperate with new and existing IPSec compliant implementations. 7.6 Ability to Optimize Compression Across Protocol Layers The layered architecture approach meets this requirement. The ESP option approach sacrifices the opportunity to develop a single method for compressing across IP and TCP layer protocol. 7.7 Anti-Expansion of Payload Data Both approaches can meet this requirement. 8. Conclusions The authors have drawn the following conclusions based on discussions with user community members, analysis of the proposed technical approaches, and the emerging need to broaden the use of compression beyond the IPSec context. - The need for compression in the IPSec context exists. The effect of IPSec encryption on downstream compression and the demands by members of the user community demonstrate a clear need for supporting compression in an IPSec context. - The compression topic does not distinctly fall in the charter of the IPSec working group. - A layered architecture approach is a superior approach when compared to the ESP option approach to problem of providing compression capabilities in the IPSec context. 9. Recommendations The authors recommend the following course of action. Monsour, et al [Page 10] INTERNET DRAFT Compression in IP Security March 1996 - Document the IPSec Architecture to Support Optional Compression It is important that the IPSec architecture specification include the notion that payload data of IPSec payloads may optionally be compressed. The draft should note that the specification for providing such compression capabilities will be developed outside of the IPSec working group. - Develop a Layered Architecture Approach to Compression A layered architecture approach, when considered against the ESP option approach has significant advantages which outweigh any potential delays in specification development and subsequent deployment. - Establish a compression working group This group would take on the responsibility for defining a the layered architecture and the separate compression header for use in IPSec as well as other candidate upper layer protocols. The rationale for this recommendation is based on several factors, including (1) the user community as well as the vendor community are under pressure to finalize the IPSec specifications, complete development and begin deployment of IPSec-compliant products. As Hugo put in a recent post to the list, "...further delay of ipsec deployment (which is also a form of denial-of-service attack :)", (2) the desire to support compression in a context broader than IPSec alone (i.e., TCP or other candidate protocols), and 10. Security Considerations This memo discusses the use of lossless compression technology in a security protocol, specifically IPSec. The proposed use of compression within this protocol is not believed to have an effect on the underlying security functionality provide by the protocol; i.e., the use of compression is not known to degrade or alter the nature of the underlying security architecture or the encryption technologies used to implement it. The use of compression does change the length of ESP payloads, in a manner that depends on the data prior to encryption. Thus, the use of compression may have an effect on the ability of an eavesdropper to glean information by analyzing the length of transmitted packets. 11. References [IPSecArch] Atkinson, R., "Security Architecture for the Internet Protocol," November 1996. Monsour, et al [Page 11] INTERNET DRAFT Compression in IP Security March 1996 [Dec96WG] Lambert, P., Minutes of the IPSec Working Group, San Jose December 1994. [Thayer] Thayer, R., "Compression Header for IPSec", draft-thayer-seccomp-00.txt, May, 1996. [Sabin1] Sabin, M., Monsour R., " [Sabin2] Sabin, M., Monsour R., " [RFC1962] Rand, D., "The PPP Compression Control Protocol (CCP)," RFC-1962, June 1996. [RFC2068] ????, "Hypertext Transport Protocol version 1.1", January, 1997. [RFC1968] ????, "The PPP Encryption Control Protocol (ECP)", June 1996. [PPPEXT] Point-to-Point Protocol Extensions Working Group Charter. [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", draft-ietf-tls-protocol-01.txt, March 1997. [PGPMan] ????, "PGPmail Reference Manual" [AH] Atkinson, R., "IP Authentication Header" [ESP] Atkinson, R., "IP Encapsulating Security Payload," June 1996. [DOI] Piper, D., "IPSec Domain of Interpretation", March 1997. [Calgary] Text Compression Corpus, University of Calgary, available at ftp://ftp.cpsc.ucalgary.ca/pub/projects/text.compression.corpus. 8. Authors' Addresses Robert Monsour Hi/fn Inc. 12636 High Bluff Drive San Diego, CA 92130 Email: rmonsour@hifn.com Michael Sabin 883 Mango Avenue Sunnyvale, CA 94087 Email: mike.sabin@worldnet.att.net Monsour, et al [Page 12] INTERNET DRAFT Compression in IP Security March 1996 Abraham Shacham Cisco Systems 101 Cooper Street Santa Cruz, CA 95060 Email: shacham@cisco.com Sanjay Anand Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 Email: sanjayan@microsoft.com Rodney Thayer Sable Technology 246 Walnut Street Newton, MA 02160 Email: rodney@sabletech.com Monsour, et al [Page 13] From owner-ipsec Fri Mar 28 13:42:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08361 for ipsec-outgoing; Fri, 28 Mar 1997 13:42:19 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199703272334.PAA00564@kebe.eng.sun.com> References: from "Stephen Kent" at Mar 27, 97 03:22:38 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Mar 1997 13:47:06 -0500 To: Dan.McDonald@Eng.sun.com (Dan McDonald) From: Stephen Kent Subject: Re: new ESP spec (bigger message) Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, >> 2.4 Payload Data >This isn't a real problem for IPv6. The reason for the 8-byte alignment >drive in IPv6 was to make fast-path processing faster. (Those of us with >UltraSPARC appreciate this.) Since ESP is already beating down the slow >path, this isn't as huge of a deal as one might think at first. Also, a >properly formed IPv6 datagram will be 8-byte aligned once you strip out the >ESP cruft after decryption. > >There's always crypto-algorithm alignment issues, but I leave those to the >crypto wizards. Good to hear that view from an IPv6 perspective, but we are crypto people too! >> 3.2.4.3 Authentication Algorithms >Is the HMAC trunctated for use in ESP?!? I hadn't heard any movement to do >so, but I sometimes miss these things. We were going for consistency here. There's no reason to believe that if 96 bits is good enough for authentication/integrity in AH that it isn't good enough for the same services in ESP. Steve From owner-ipsec Fri Mar 28 13:44:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08381 for ipsec-outgoing; Fri, 28 Mar 1997 13:44:50 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199703272247.OAA00326@kebe.eng.sun.com> References: from "Stephen Kent" at Mar 27, 97 03:22:08 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Mar 1997 13:47:45 -0500 To: Dan.McDonald@Eng.sun.com (Dan McDonald) From: Stephen Kent Subject: Re: new AH spec Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, >Looks good so far. The bit about "piecemeal" might be a bit strong, but >that's really hairsplitting. I'm not trying to be negative, just accurate in my description of the way in which Ah is computed over portions of the IP header, zero-filling others, etc. >Mostly, the NULL authentication algorithm is used for testing of protocol >plumbing. I don't expect any shipping product to have a null authentication >algorithm. I do expect AH implementations that are in their nascent stages >to have a null authentication algorithm. Interpret this data as you will >w.r.t. how the spec should read. I think if NULL is used only for testing, it would be better not to have it as a cited transform/algorithm. >A zero SPI is useful for any number of implementation-specific aids. An >example I can think of off the top of my head is that if my >getassocybyendpoint() call for an outgoing datagram returns an association >with a zero SPI, I can interpret this as any number of results (including, "I >just kicked key management in the rear, I'll get back to you.") As above, if a zero SPI will never appear on the wire (fiber?), I'd rather not specify it here. What you describe is a local interface matter. >I know certain people who have issues about having this field NOT being >present. I don't have a problem with this, but I suspect the people who have >these issues will speak up. Yes, documents have clearly diverged re the presence or absence of this field and I'm going with the interpretation we adopted for ESP, i.e., if the servuce is not negotiated, the field is absent. >BTW, ESP is one of these upper-layer protocol fields. In fact, lemme return >to this upper-layer protocol idea in a bit. Yep! We'll add ESP as an obvious additional example. I'll leave the resolution of IPv6 header element ordering to those more knowledgable in the intricacies of that protocol. >This sentence is more important than is apparent at first. An implementation >can look at the inner IP header as JUST ANOTHER UPPER LAYER. This helps >reduce some of the special-casing for IP as the inner payload. It doesn't >_ELIMINATE_ it, but it can reduce it. > >(For example, if you have A->B with the inner IP saying A->B, you can make >stronger assertions than if the inner packet says something else.) We can emphasize this point if you think it's important and does not receive enough attention here. >As an aside, I'd strongly encourage to look at the current implementations >out there, as well as some of the analysis literature. I suspect you've >already done your homework on this front and will be drawing on their >experience when you finish rewhacking the architecture document. The implementations I have seen so far do not seem to provide the sort of granularity that Ran's previous architecture I-D called for, and that I called for in my talk at the last IETF WG, etc. But I am going on what I've seen at the trade shows, not the bakeoffs, so I hope we are closer than I fear. >Do you have any recommendations for when the sequence number cycles? (Kick >key mgmt. in the pants, logging, tuning future SAs to expire sooner, etc.) I'm tempted to say that cycling is an error, and that key managememtn should have been kicked sooner. The architecture document can address this in more detail, or we can say something more definite here is there is concensus. >Except for perhaps DF, these FLAGS and OFFSET SHOULD be zero anyway after >reassembly! The question of DF is perhaps why the decision was made to just >zero out that bit too. I think we agree on the basic premise. Note that if a security gateway fragments a packet with AH applied already, it will be using tunnel mode, so the DF bit covered by the inner AH is not an issue here. We will be sending out a message iscussion DF and PMTU after Memphis. >IMHO, new IPv6 extensions should document their own AH properties. Keep in >mind this is IMHO only. I like this as an answer; it allows it to reach closure on this document. >Thank you! We in IPv6-land appreciate this. You're welcome. >As an aside, has anyone tackled this? A lightweight digital signature >algorithm would be perfect in a multicast environment with a small number of >senders compared with an arbitrary number of receivers. This is a hard problem is we look for digital signature solutions, but maybe we'll get lucky. ECC signatures are faster and smaller, but ... Are you suggesting solutions that are not digital signature based? I ask only because of your comment re the number of possible senders, which would seem not to be an issue if we use a real signature algorithm. >Like I mentioned before, as currently written, these I-Ds _always_ include >the replay counter. The replay counter is set to 0 for associations that >don't use replay. The I-Ds cited are not ones that inlude references to counters, AH, etc. They are raw algorithms I-Ds, which is just what we want for this style of specification. The issue of the presence or absence of the replay counter should be with separately, in this document. >Ummm, what if I live in a multithreaded world? I can theoretically get two >packets near-concurrently with the same sequence number. If the bogus one >arrives first, do I trash the good one just because one with the same replay >number arrived first? Or do I not count a sequence number as "good" until >I've authenticated? Or is this just an implementation detail? Or is this >why it says SHOULD rather than MUST? We can make mention earlier of the need to authentciate prior to accepting a packet, as you observed later. Steve From owner-ipsec Fri Mar 28 18:51:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA10293 for ipsec-outgoing; Fri, 28 Mar 1997 18:47:09 -0500 (EST) Message-ID: <01BC3B90.23A3D480@nomad16.nomadix.com> From: Andrew Everett To: "'ipsec@tis.com'" Subject: Call for Presentations - SIP & Security for Mobile Users Date: Fri, 28 Mar 1997 15:53:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Speakers are sought for a half-day tutorial on Security for Mobile Users and and a conference session on Secure IP at the upcoming Nomadic 97 conference. The theme of the conference is Enabling Mobility on the Internet and Intranets and will take place August 25-28, 1997 in Santa Clara, California. Interested parties may inquire about speaking opportunities by sending an e-mail to Andrew Everett at aeverett@tticom.com. From owner-ipsec Sun Mar 30 15:19:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA20789 for ipsec-outgoing; Sun, 30 Mar 1997 15:18:35 -0500 (EST) Date: Sun, 30 Mar 97 20:16:52 GMT Daylight Time From: Ran Atkinson Subject: Re: new ESP spec (bigger message) To: Charles Lynn , ipsec@tis.com Cc: Dan McDonald X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199703280400.XAA04513@relay.hq.tis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Charlie, Since the alignment question is one driven by the IPng community, it seems to me that the right approach to this question includes at least: (1) posting a note to both IPsec and IPng lists announcing the new drafts and raising the alignment question (2) asking that all followup notes be cross-posted to both lists so that both communities see all the discussion (3) understanding that consensus in BOTH WGs on this question is a prerequisite for considering this matter resolved. Ran rja@inet.org From owner-ipsec Sun Mar 30 15:19:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA20782 for ipsec-outgoing; Sun, 30 Mar 1997 15:13:36 -0500 (EST) Date: Sun, 30 Mar 97 20:10:09 GMT Daylight Time From: Ran Atkinson Subject: Re: new AH spec To: Dan.McDonald@Eng.sun.com, kent@bbn.com, touch@isi.edu Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199703272257.AA18146@ash.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Joe, "An SPI value of zero indicates no Security Association exists." is a very useful part of the IPsec specificationS. By definition, this SPI value is NEVER used in a packet sent on the wire. It is extremely useful, however, to have a single reserved SPI value that can be optionally used for implementation-specific purposes inside some implementation. In practice, changing or removing this sentence will cause existing fully conforming implementations to become non-conforming (which is something that the IETF does NOT generally do unless the prior statement has some fatal operational flaw, which this reserved value does not). Ran rja@inet.org From owner-ipsec Mon Mar 31 09:58:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA26068 for ipsec-outgoing; Mon, 31 Mar 1997 09:57:01 -0500 (EST) 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-new-esp-00.txt Date: Mon, 31 Mar 1997 09:35:18 -0500 Message-ID: <9703310935.aa04772@ietf.org> 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 : IP Encapsulating Security Payload (ESP) Author(s) : S. Kent, R. Atkinson Filename : draft-ietf-ipsec-new-esp-00.txt Pages : 17 Date : 03/28/1997 The Encapsulating Security Payload (ESP) header is designed to provide a mix of optional security services in IPv4 and IPv6. ESP may be applied alone, in combination with the IP Authentication Header (AH) [KA97b], or in a nested fashion, e.g., through the use of tunnel mode (see below). Security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. For more details on how to use ESP and AH in various network environments, see "Security Architecture for the Internet Protocol" [KA97a]. 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-new-esp-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-new-esp-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-new-esp-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970328110738.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-new-esp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-new-esp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970328110738.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Mar 31 09:58:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA26074 for ipsec-outgoing; Mon, 31 Mar 1997 09:57:31 -0500 (EST) 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-new-auth-00.txt Date: Mon, 31 Mar 1997 09:35:20 -0500 Message-ID: <9703310935.aa04792@ietf.org> 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 : IP Authentication Header Author(s) : S. Kent, R. Atkinson Filename : draft-ietf-ipsec-new-auth-00.txt Pages : 15 Date : 03/28/1997 The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams (hereafter referred to as just "authentication"), and to provide protection against replays. This latter, optional service may be selected when a Security Association is established. AH provides authentication for as much of the IP header as possible, as well as for upper level protocol data. However, some IP header fields may change in transit and the value of these fields, when the packet arrives at the receiver, may not be predictable by the transmitter. The values of such fields cannot be protected by AH. Thus the protection provided to the IP header by AH is somewhat piecemeal. 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-new-auth-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-new-auth-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-new-auth-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970328111608.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-new-auth-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-new-auth-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970328111608.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Mar 31 12:36:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA26978 for ipsec-outgoing; Mon, 31 Mar 1997 12:35:51 -0500 (EST) From: touch@isi.edu Date: Mon, 31 Mar 1997 09:41:01 -0800 Posted-Date: Mon, 31 Mar 1997 09:41:01 -0800 Message-Id: <199703311741.AA01725@ash.isi.edu> To: Dan.McDonald@Eng.sun.com, kent@bbn.com, touch@isi.edu, rja@inet.org Subject: Re: new AH spec Cc: ipsec@tis.com X-Auto-Sig-Adder-By: faber@isi.edu Sender: owner-ipsec@ex.tis.com Precedence: bulk > From rja@inet.org Sun Mar 30 12:19:08 1997 > Date: Sun, 30 Mar 97 20:10:09 GMT Daylight Time > From: Ran Atkinson > Subject: Re: new AH spec > To: Dan.McDonald@eng.sun.com, kent@bbn.com, touch@isi.edu > Cc: ipsec@tis.com > X-Priority: 3 (Normal) > References: <199703272257.AA18146@ash.isi.edu> > > > Joe, > > "An SPI value of zero indicates no Security Association exists." is a > very useful part of the IPsec specificationS. By definition, this SPI > value is NEVER used in a packet sent on the wire. It is extremely useful, > however, to have a single reserved SPI value that can be optionally > used for implementation-specific purposes inside some implementation. Sure - that part is clear. The SPI value of 0 is to the API, but there is never a case when the value needs to be stored in the field. This should be made clear in section 2.4 of the draft. > In practice, changing or removing this sentence will cause existing fully > conforming implementations to become non-conforming (which is something > that the IETF does NOT generally do unless the prior statement has > some fatal operational flaw, which this reserved value does not). Given that there's already a revision of the RFC in progress, this statement is of little significance. Fully conforming to WHICH - the new or old spec? PS - in that vein, why does the new draft have no references to RFC 1826, even though it has the same title? Joe ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/ From owner-ipsec Mon Mar 31 15:51:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA28370 for ipsec-outgoing; Mon, 31 Mar 1997 15:50:32 -0500 (EST) Message-Id: <2.2.32.19970331210326.00bddb34@mailserv-H.ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 31 Mar 1997 16:03:26 -0500 To: Bill Sommerfeld From: Naganand Doraswamy Subject: Re: Proposed changes to ESP (andf a little AH too) Cc: daw@cs.berkeley.edu (David Wagner), ipsec@ex.tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, >We merely need to specify that the IP checksum MUST be supplied on >transmission and verified on receipt for packets nested inside ESP. > I think IPv6 does not do any checksum. It depends on the upper layer protocols to perform checksums. --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) From owner-ipsec Mon Mar 31 15:51:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA28349 for ipsec-outgoing; Mon, 31 Mar 1997 15:45:54 -0500 (EST) Date: Mon, 31 Mar 97 20:43:15 GMT Daylight Time From: Ran Atkinson Subject: Re: new AH spec To: Dan.McDonald@Eng.sun.com, kent@bbn.com, rja@inner.net, touch@isi.edu Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199703311741.AA01725@ash.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Joe, The notion is that the _revised_ AH/ESP specifications should be written such that existing implementations that conform fully to RFC-1825 through RFC-1827 are NOT made non-conforming except for very very good reason (e.g. a specific known cryptographic attack). My understanding from Steve Kent during and since Montreal has always been that his revisions would have the above property -- except as required to fix specific publicly-known attacks on the existing RFCs. Ran rja@inet.org From owner-ipsec Mon Mar 31 17:21:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA28888 for ipsec-outgoing; Mon, 31 Mar 1997 17:20:54 -0500 (EST) From: touch@isi.edu Date: Mon, 31 Mar 1997 14:26:10 -0800 Posted-Date: Mon, 31 Mar 1997 14:26:10 -0800 Message-Id: <199703312226.AA08928@ash.isi.edu> To: Dan.McDonald@Eng.sun.com, kent@bbn.com, rja@inner.net, touch@isi.edu, rja@inet.org Subject: Re: new AH spec Cc: ipsec@tis.com X-Auto-Sig-Adder-By: faber@isi.edu Sender: owner-ipsec@ex.tis.com Precedence: bulk > From rja@inet.org Mon Mar 31 12:51:22 1997 > Date: Mon, 31 Mar 97 20:43:15 GMT Daylight Time > From: Ran Atkinson > Subject: Re: new AH spec > To: Dan.McDonald@eng.sun.com, kent@bbn.com, rja@inner.net, touch@ISI.EDU > Cc: ipsec@tis.com > X-Priority: 3 (Normal) > References: <199703311741.AA01725@ash.isi.edu> > > > Joe, > > The notion is that the _revised_ AH/ESP specifications should be > written such that existing implementations that conform fully to > RFC-1825 through RFC-1827 are NOT made non-conforming except for > very very good reason (e.g. a specific known cryptographic attack). maybe a paragraph indicating this goal would be appropriate, and certainly the revised specs should refer directly to the original specs Joe ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/ From owner-ipsec Mon Mar 31 19:11:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA29445 for ipsec-outgoing; Mon, 31 Mar 1997 19:06:16 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199703312226.AA08928@ash.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 31 Mar 1997 19:11:26 -0500 To: touch@isi.edu, rja@inet.org From: Stephen Kent Subject: Re: new AH spec Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Joe + Ran, It was an oversight on my part that we did not reference the original AH and ESP specs, and that will be remedied in our next round of revisions. We also can add a section to provide a brief overview of format/processing differences between the old and new verisons, to make reading easier for those already familiar with the current RFCs. As per Ran's clarifying comments, we will re-wrod the specs to make clear that an SPI of 0 is for internal use, not for transmission on the wire. Steve From owner-ipsec Mon Mar 31 22:03:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA00507 for ipsec-outgoing; Mon, 31 Mar 1997 22:02:45 -0500 (EST) Message-Id: <199704010307.WAA06277@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: Naganand Doraswamy Cc: daw@cs.berkeley.edu (David Wagner), ipsec@ex.tis.com Subject: Re: Proposed changes to ESP (andf a little AH too) In-Reply-To: naganand's message of Mon, 31 Mar 1997 16:03:26 -0500. <2.2.32.19970331210326.00bddb34@mailserv-H.ftp.com> Date: Mon, 31 Mar 1997 22:07:13 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > I think IPv6 does not do any checksum. It depends on the upper layer > protocols to perform checksums. Right, but TCP-on-IPv6 and UDP-on-IPv6 still include the ones-complement checksum, right? - Bill From owner-ipsec Mon Mar 31 22:34:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA00700 for ipsec-outgoing; Mon, 31 Mar 1997 22:34:05 -0500 (EST) Message-Id: <199704010338.WAA04898@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: Bill Sommerfeld cc: Naganand Doraswamy , daw@cs.berkeley.edu (David Wagner), ipsec@ex.tis.com Subject: Re: Proposed changes to ESP (andf a little AH too) In-reply-to: Your message of "Mon, 31 Mar 1997 22:07:13 EST." <199704010307.WAA06277@thunk.ch.apollo.hp.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 31 Mar 1997 22:38:24 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill Sommerfeld writes: > > I think IPv6 does not do any checksum. It depends on the upper layer > > protocols to perform checksums. > > Right, but TCP-on-IPv6 and UDP-on-IPv6 still include the > ones-complement checksum, right? Yes.