From owner-ipsec Sun Feb 1 01:55:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA00364 for ipsec-outgoing; Sun, 1 Feb 1998 01:53:03 -0500 (EST) Message-Id: <3.0.5.32.19980129161153.009aa450@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 29 Jan 1998 16:11:53 +0000 To: ipsec@tis.com From: Robert Moskowitz Subject: Re: Tunnel Vs Transport In-Reply-To: <3.0.5.32.19980128104538.009af390@homebase.htt-consult.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:45 AM 1/28/98 +0000, Robert Moskowitz wrote: >Timestep has a draft out for the gateway to >assign the inner source address. A number of people have asked me about this ID and it is: draft-ietf-ipsec-isakmp-mode-cfg-01.txt Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Mon Feb 2 06:50:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA09561 for ipsec-outgoing; Mon, 2 Feb 1998 06:39:04 -0500 (EST) To: ipsec@tis.com Subject: Re: IPSEC and NFS References: <199801302105.QAA16381@jekyll.piermont.com> From: Greg Troxel Date: 02 Feb 1998 06:51:32 -0500 In-Reply-To: "Perry E. Metzger"'s message of Fri, 30 Jan 1998 16:05:02 -0500 Message-ID: Lines: 23 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-ipsec@ex.tis.com Precedence: bulk While NFS is broken in that it currently depends on client machines to represent uid, I can think of two ways to fix this, one of which isn't too hard. The first way is very similar to how 'kerberized NFS' worked at MIT Athena. It's fairly easy to add a uid mapping table to an NFS server, so that incoming 'ip addr, uid' values are mapped to something else. One could accept authenticated requests to add mappings, but make the left hand side be 'SA bundle, uid', rather than 'ip addr, uid'. This way, the NFS request would have to be IPSEC-authenticated. This could be made to work with per-host keying for the SA bundle protecting the data traffic, but still require per-user keying to authenticate the request to install the mapping. This would allow reasonable behavior from hosts completely under a user's control (they can access their own files) and also reasonable behavior from multi-user systems. The next way is to require that the SA bundle in the mapping be per-user keying. This would require changing client filesystem implementations to use a different SA for each user. For UDP this might be doable easily, but for NFS over TCP I suspect a separate TCP connection might be required per user. Greg Troxel From owner-ipsec Mon Feb 2 07:36:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA09972 for ipsec-outgoing; Mon, 2 Feb 1998 07:36:07 -0500 (EST) Date: Sun, 1 Feb 1998 10:24:37 +0100 (MET) From: Pierre-Alain Fouque X-Sender: fouque@beru To: ipsec@ans.net Subject: Search draft Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, my name is Pierre-Alain FOuque and I am a student who is making a memo about the security on IP. I search the draft draft-ietf-sipp-esp-03.txt, draft-ietf-sipp-ap-03.txt, and draft-ietf-sipp-sa-02.txt. I have read that Eastlake, Donald E. has made a draft on PIPS Practical IP Security contained in an incomplete draft. I thank you for all this knowledges because I haven't found them on the ietf site. _______________________________________________________________________________ Pierre-Alain Fouque e-mail : fouque@rennes.enst-bretagne.fr tel. : (+033) 2 99 38 96 02 Telecom Bretagne 2,rue de la Chataigneraie - BP 78 35512 CESSON SEVIGNE FRANCE _______________________________________________________________________________ From owner-ipsec Mon Feb 2 07:43:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA10107 for ipsec-outgoing; Mon, 2 Feb 1998 07:43:07 -0500 (EST) Date: Fri, 30 Jan 1998 19:11:55 -0800 (PST) From: "Michael R. Eisler" Reply-To: "Michael R. Eisler" Subject: Re: IPSEC and NFS To: Marcus Leech Cc: "Angelos D. Keromytis" , ipsec@tis.com In-Reply-To: "Your message with ID" <34D21817.11730FC9@nortel.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > Angelos D. Keromytis wrote: > > > > > I've been using NFS over IPsec to protect against outsider attacks for > > a while now, but I don't see how NFS can be made insider-resistant > > without major restructuring of the protocol. There's the implicit > > assumption that the client kernel is behaving. Of course, you didn't > > quite explain what your threat model was (hostile users on the client > > machine I presume -- in which case IPsec+priviledged ports required > > for the client can do wonders). > > Cheers, > Fair enough, I wasn't very clear on the threat model. > > I'm particularly concerned about things like PCs participating in > NFS services, in which it's sooooo easy for the client to "cheat" > in the sense of claiming a uid/gid that it has no "right" to. > I'm afraid that your analysis of NFS requiring major restructuring > to protect agaist this is correct. Secure RPC doesn't appear to ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > be a reasonable fix for this either. Sigh. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ why? > > If I restrict an NFS server to only allowing SAs with hosts it > knows "play by the rules"--in that user processes cannot fake > legitimate NFS protocol (because they can't get a privileged port), not all operating systems support the concept of privileged users having exclusive access to "privileged" ports. > then host-to-host IPSEC works. What a marvellous world it would > be if I could always make that assumption... From owner-ipsec Mon Feb 2 08:40:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA10704 for ipsec-outgoing; Mon, 2 Feb 1998 08:39:06 -0500 (EST) Message-Id: <199802021350.AA15472@world.std.com> To: Pierre-Alain Fouque Cc: ipsec@ans.net, dee@world.std.com Subject: Re: Search draft In-Reply-To: Your message of "Sun, 01 Feb 1998 10:24:37 EST." Date: Mon, 02 Feb 1998 08:50:33 -0500 From: "Donald E. Eastlake 3rd" Sender: owner-ipsec@ex.tis.com Precedence: bulk Frankly, I don't remember doing a "PIPS" draft, whatever it was. Must have been years ago. You might want to look at my draft-eastlake-wato-* draft which I still think is a good idea but probably won't happen due to the restistence of router vendors. Donald From: Pierre-Alain Fouque X-Sender: fouque@beru To: ipsec@ans.net Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk }Hi, my name is Pierre-Alain FOuque and I am a student who is making a memo }about the security on IP. I search the draft draft-ietf-sipp-esp-03.txt, }draft-ietf-sipp-ap-03.txt, and draft-ietf-sipp-sa-02.txt. I have read that }Eastlake, Donald E. has made a draft on PIPS Practical IP Security }contained in an incomplete draft. } }I thank you for all this knowledges because I haven't found them on the }ietf site. } }_______________________________________________________________________________ }Pierre-Alain Fouque }e-mail : fouque@rennes.enst-bretagne.fr }tel. : (+033) 2 99 38 96 02 }Telecom Bretagne }2,rue de la Chataigneraie - BP 78 }35512 CESSON SEVIGNE }FRANCE }_______________________________________________________________________________ From owner-ipsec Mon Feb 2 11:12:52 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA12176 for ipsec-outgoing; Mon, 2 Feb 1998 11:10:16 -0500 (EST) Message-Id: <199802021616.LAA26723@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ippcp@external.cisco.com, ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ippcp-protocol-05.txt Date: Mon, 02 Feb 1998 11:15:59 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Payload Compression Protocol Working Group of the IETF. Title : IP Payload Compression Protocol (IPComp) Author(s) : M. Thomas, R. Monsour, R. Pereira, A. Shacham Filename : draft-ietf-ippcp-protocol-05.txt Pages : 8 Date : 29-Jan-98 This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ippcp-protocol-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ippcp-protocol-05.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-ippcp-protocol-05.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: <19980129174452.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippcp-protocol-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippcp-protocol-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980129174452.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Feb 2 13:43:46 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA13441 for ipsec-outgoing; Mon, 2 Feb 1998 13:42:21 -0500 (EST) Message-ID: <34D615B7.1F71644A@nt.com> Date: Mon, 02 Feb 1998 13:51:35 -0500 From: "Marcus Leech" Organization: Nortel Technology, Messaging and Security Infrastructure X-Mailer: Mozilla 4.03 [en] (X11; I; HP-UX A.09.05 9000/712) MIME-Version: 1.0 To: "Michael R. Eisler" , ipsec@tis.com Subject: Re: IPSEC and NFS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Michael R. Eisler wrote: > > > Angelos D. Keromytis wrote: > > > > > > > > I've been using NFS over IPsec to protect against outsider attacks for > > > a while now, but I don't see how NFS can be made insider-resistant > > > without major restructuring of the protocol. There's the implicit > > > assumption that the client kernel is behaving. Of course, you didn't > > > quite explain what your threat model was (hostile users on the client > > > machine I presume -- in which case IPsec+priviledged ports required > > > for the client can do wonders). > > > Cheers, > > Fair enough, I wasn't very clear on the threat model. > > > > I'm particularly concerned about things like PCs participating in > > NFS services, in which it's sooooo easy for the client to "cheat" > > in the sense of claiming a uid/gid that it has no "right" to. > > I'm afraid that your analysis of NFS requiring major restructuring > > to protect agaist this is correct. Secure RPC doesn't appear to > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > be a reasonable fix for this either. Sigh. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > why? > The last time I looked at the way secure RPC worked, it was, to be polite, less than wonderful. RSA keypairs were limited to some very small size, and private keys were stored on a central server, with encrypted private keys flying over the network, making it easy to launch a passwd-style cracking attack. Unless secure RPC has come a long way since I read about it (a couple of years ago), then I still claim that it isn't a reasonable solution. > > > > If I restrict an NFS server to only allowing SAs with hosts it > > knows "play by the rules"--in that user processes cannot fake > > legitimate NFS protocol (because they can't get a privileged port), > > not all operating systems support the concept of privileged users having > exclusive access to "privileged" ports. Right, but if I restrict my NFS servers to only dealing with operating systems that HAVE that concept, then this kludge works. -- ---------------------------------------------------------------------- Marcus Leech Mail: Dept 8M86, MS 012, FITZ Systems Security Architect Phone: (ESN) 393-9145 +1 613 763 9145 Messaging and Security Infrastructure Fax: (ESN) 395-1407 +1 613 765 1407 Nortel Technology mleech@nortel.ca -----------------Expressed opinions are my own, not my employer's------ From owner-ipsec Tue Feb 3 08:23:01 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA20690 for ipsec-outgoing; Tue, 3 Feb 1998 08:10:22 -0500 (EST) Date: Tue, 3 Feb 1998 13:53:10 +0100 (MET) From: Pierre-Alain Fouque X-Sender: fouque@gadget To: "Donald E. Eastlake 3rd" cc: Pierre-Alain Fouque , ipsec@ans.net Subject: Re: Search draft In-Reply-To: <199802021350.AA15472@world.std.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Donald I am happy to have news about your job. I am actually making a project with HP Labs in Bristol to secure their CMW machine on an IP network. So, I am learning all about the protocols which are running on the IP Layer. I have learn the article from Mark H. Linehan from IBM T.J. Watson Research Center, which dated 29 June 1994 that in the References [4] you have sent an incomplete draft as an e-mail to the ipsec mailing list, which is dated 31 March 1994. This document made by Lineham is called Comparison of Network-Level Security Protocols. Thank you for your help. Best regards, Pierre-Alain _______________________________________________________________________________ Pierre-Alain Fouque e-mail : fouque@rennes.enst-bretagne.fr tel. : (+033) 2 99 38 96 02 Telecom Bretagne 2,rue de la Chataigneraie - BP 78 35512 CESSON SEVIGNE FRANCE _______________________________________________________________________________ On Mon, 2 Feb 1998, Donald E. Eastlake 3rd wrote: > > Frankly, I don't remember doing a "PIPS" draft, whatever it was. Must > have been years ago. You might want to look at my draft-eastlake-wato-* > draft which I still think is a good idea but probably won't happen due to > the restistence of router vendors. > > Donald > > From: Pierre-Alain Fouque > X-Sender: fouque@beru > To: ipsec@ans.net > Mime-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > Sender: owner-ipsec@ex.tis.com > Precedence: bulk > }Hi, my name is Pierre-Alain FOuque and I am a student who is making a memo > }about the security on IP. I search the draft draft-ietf-sipp-esp-03.txt, > }draft-ietf-sipp-ap-03.txt, and draft-ietf-sipp-sa-02.txt. I have read that > }Eastlake, Donald E. has made a draft on PIPS Practical IP Security > }contained in an incomplete draft. > } > }I thank you for all this knowledges because I haven't found them on the > }ietf site. > } > }_______________________________________________________________________________ > }Pierre-Alain Fouque > }e-mail : fouque@rennes.enst-bretagne.fr > }tel. : (+033) 2 99 38 96 02 > }Telecom Bretagne > }2,rue de la Chataigneraie - BP 78 > }35512 CESSON SEVIGNE > }FRANCE > }_______________________________________________________________________________ > From owner-ipsec Tue Feb 3 12:48:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA22733 for ipsec-outgoing; Tue, 3 Feb 1998 12:46:27 -0500 (EST) From: "Alexei V. Vopilov" To: "IPsec MailList" Subject: locating IPsec gateway proposal Date: Tue, 3 Feb 1998 20:56:00 +0300 Message-ID: <01bd30cc$fcbc4360$db253ac3@ppalx> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_005F_01BD30E6.22097B60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ipsec@ex.tis.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_005F_01BD30E6.22097B60 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Attached document describes an approach to solve the following problems - discovering IP address and/or Key of IPsec gateway - locating a backup gateway at the runtime if primary gateway fails. - discovering the chain of nested gateways if there is a number of secured borders protecting a remote server. Comments and critics are welcome. regards, --- Alexei V. Vopilov (alx@elnet.msk.ru), +7(095)5367694 Software Architecture&Development Consultant. --- ------=_NextPart_000_005F_01BD30E6.22097B60 Content-Type: text/plain; name="draft-draft-alx-ipsec-gw-loc.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-draft-alx-ipsec-gw-loc.txt" February 3, 1998 Alexei V. Vopilov Alx@elnet.msk.ru The locating an IPsec gateway algorithm Abstract ----------------------------------------- As any sophisticated and fast growing system, Internet employs various technologies to adopt dynamical changing of it infrastructure. This makes possible to keep connectivity at the high level during both usual expansions of Internet and internal rearrangement of yet deployed Internet components. In fact, incorporation of a security in the Internet network layer in most cases successfully breaks achieved connectivity being sacrificed for the safety of information exchange. One scalability problem with IPsec-based communications arises whenever one networking node delegates to other it network security functions. As the result, a client system has to figure out and keep in consistence information about where such trusted intermediate is located presently and which credentials are to use at the same moment. Current DNS and even proposed DNSSEC technologies do not provide required functionality to solve this task reliably. This document propose a number of considerations that, if taken into effect, increase availability of secured resources while keeping the security level intact. Discussion ----------------------------------------- Proposed scheme is based on yet available ISAKAMP specification. It is not required to change existing ISAKMP payloads format for supporting basic functions described herein. However, inventing additional payloads and exchange types for ISAKMP would provide more usability for algorithm. In general, this document suggests methodology that having been implemented in an IPsec implementation solves the following issues. 1. The later binding between an IP address of remote server and such parameters as the address of IPsec gateway and gateway Key. 2. Discovering, during runtime, secured backup path for an IPsec client when secured server resources can be reached via more than one IPsec gateways. 3. Discovering a chain of trusted intermediate gateways whenever network traffic must be protected by a number of nested Security Associations. Core Idea ----------------------------------------- Suppose that a client IPsec system must protect communications to some remote server with known IP address. Assume also that such information as an IPsec gateway address and probably gateway's Public Key is not supplied with local policy or those parameters can be dynamically changed during runtime. Since current standards require a client system to establish ISAKMP SA prior negotiating of any application level SA, let's suggest for client to enter in ISAKMP SA negotiations. Here are first two tricks: 1. A client system tries negotiate ISAKMP SA right with the remote server it needs to get access to. 2. With an ISAKMP SA request a client associate only two selector parameters such as locally generated Cookie and local IP address. Note that if a client system is not sure which of credentials to use for destination, this information is just omitted in ISAKMP SA request. Whenever the reply on ISAKMP SA request is received, client finds appropriate ISAKMP SA context based on locally generated cookie value included in the ISAKMP SA response. That means the address of a responder in the reply might not correspond to the one used for sending the request. The next trick is: 3. Upon successful negotiation of an ISAKMP SA, a client node uses actual address of ISAKMP SA responder as one representing security gateway for originally requested remote server. Note that proposed scheme, when based just on yet developed specifications does not prove the trustiness of discovered information, though there is a number of ways to get that prove based on available technologies. Note as well that since some parameters previously considered as resided in the local policy are now suggested to be 'negotiable', the logic embedded into implementations becomes more sophisticated and must be clearly defined. The issues, subsequent from two above statements, are discussed in the respective sections hereinafter. The trustiness of discovered information ----------------------------------------- In fact, this document proposes to have such parameters of IPsec configuration as Gateway Address and Remote Party Credentials be optionally discovered online. One might argue that a system followed this approach will become compromised due to simple attacks. For example, if A wants to access B, some malicious intermediate router C can conduct a simple attack by claiming that it represents B and forcing A to encrypt network data using wrong keys. The response on this argument is that information itself and authorization to use it for specific purposes are topics from two different discussion domains. Thus, the address of a router on the path between two nodes is an issue of projection of current network load on the underlined topology. The authentication of IP address and Public Key of a router to represent a trusted intermediate for destination nodes is an administrative policy employed in an organization the destination node belongs to. The authorization to use discovered IP address and key for a gateway is an administrative issue used by security policy on the client side. For example, once the IP address and Key have been discovered by an initiator, the latest can use DNSSEC protocol to prove that or, at least, consult with locally resided (and trusted) database. Protocol implementation details ----------------------------------------- This section presents if-else conditions occurring during IPsec gateway address and key discovering process. Note that by implementing described logic not only control flow but also general design of an IPsec implementation gets affected. Initiator requirements ------------------- 1. The following configuration data of an IPsec implementation are maintained separately. - Authenticated database of Network domains and corresponded IPsec gateway addresses. - Authenticated database of Network domains and Public keys representing gateways from particular domain. 2. Local SPD may not include the gateway address and Key ID values for particular policy entry. 3. For some local SPD entry it is possible to have a list of associated gateway addresses and allowed Keys. 4. The only selectors that represent an ISAKMP SA request for initiator are Initiator's COOKIE value and allocated source UDP port. The same COOKIE must not be possible to generate within a period less than timeout set for ISAKMP SA creation attempt. 5. Multiple ISAKMP SAs with the same remote system must be supported. Responder (IPsec gateway) requirements ------------------- 1. It must be possible to intercept UDP packets going through a gateway to a system protected by that gateway. 2. Multiple ISAKMP SAs with the same remote system must be supported. Starting point ------------------- The protocol starts whenever Initiator needs to create ISAKMP SA with known destination address. Initiator performs: ------------------- 1. Generates Cookie and composes ISAKMP SA request. Note that Initiator may follow to any of ISAKMP modes, specifically: - Initiator ID payload might not be supplied with the request - Responder ID payload might not be supplied with the request 2. Allocates a source UDP port, creates UDP socket, bind the socket to local address. 3. Sets retransmission counter and timeout value for a request. 4. Sends UDP request originated from allocated port and destined for ISAKMP daemon port of remote system. 5. Starts to listen on created socket bundled to allocated source port for 'any' destination IP address. Gateway performs ------------------- 1. Upon intercepting client's request, consults with local policy whether information provided in the request is enough to enter in the ISAKMP SA negotiation. 2. If more information is required, gateway forces a client to follow appropriate ISAKMP mode by sending the reply originated from gateway (tunneling) IP address with Initiator Cookie included. At the same time, at least the gateway COOKIE is supplied. Initiator performs ------------------- 1. If the listening socket has returned Cookie other than was originally sent, silently drops incoming packet. This even should be logged as possible attack attempt. 2. If the address of destination system differs from one used in request, checks out whether gateway discovering is allowed for particular destination system. 3. If local policy prohibits secured gateway discovering, silently drops the packet, continues listen until retransmit counter has been expired. This even must be logged as either the fact of an attack or misconfiguration either of two IPsec systems. 4. Otherwise, initiator continues negotiations until both gateway address and authenticated credentials become available. Before making any further decision, initiator performs checking that discovered information is authorized for using for particular remote server. The authorization is made based on local configuration of a client or through DNSSEC request. Upon successful creation of ISAKMP SA, the resulting address of ISAKMP SA serves as tunnel address during further (application SAs) negotiations. Discovering backup path/gateway ----------------------------------------- This section describes advanced technique if a remote server can be reached through multiple gateways. The issues of primary gateway failure and dynamical switching the routing to point on other entry point of a secured border are covered as well. The most sophisticated environment would be described as followed: - A remote server can be reached through more than one gateway - Some/all of gateways employ the same virtual tunneling address been assigned to belong a subnet protected by gateways border. - The routing is established to carry packets through different gateways considering forward and backward data- flow directions. More detailed gateway-discovering algorithm is as followed: 1. Initiator discovers primary gateway. The following information becomes available locally: - Tunneling address GW_IP_1 - Gateway Key GW_KEY_1 Note that at this step the ISAKMP SA_1 is created between a Client and GW_1 2. Suppose that primary gateway becomes broken. That fact can be discovered by means ether of two events: - ISAKMP SA_1 does not respond on 'keep alive' messages sent by a client. This case reflects an environment where there is only one gateway or GW_IP_1 is NOT shared between multiple gateways. - A client has received request on ISAKMP SA from other gateway but with the same IP address as GW_IP_1. This case characterizes an environment where the secured data flow is affected by dynamic routing. Note that Key ID of a new gateway can be different from previously discovered one. 3. In both cases, a client starts discovering of another gateway while retrying the old one. 4. If protocol has succeeded, ISAKMP SA_2 is created and all ISAKMP SA_1 child-SAs are renegotiated. 5. ISAKMP SA_1, if not responded, is removed afterwards. Different forward and backward server paths ----------------------------------------- Sometime, the routing will cause the forward and backward exchanges with a remote server are destined through different IPsec gateways. As the result, a client IPsec implementation will meet with the fact of additional ISAKMP SA requested after establishment of an application-level SA. After second ISAKMP SA is established, the request to create application-level SA for backward traffic will be made possibly employing the same tunneling address but different gateway Key. A client has to handle this situation correctly by encrypting application data going to remote server using firstly discovered Key and decrypting backward traffic with secondly discovered Key. Unfortunately, current ISAKMP protocol cannot resolve this potential conflict explicitly. To date only the order of ISAKMP SAs creation provides a hint for a client IPsec implementation. Routing flip-flop ----------------------------------------- The worse case than previously described will be for unstable routing path that might cause to a number of ISAKMP SAs be created when discovering IPsec gateway. Configurations where different gateways employ the same gateway address will not work since a client IPsec cannot predict the path packets will go through, so the right gateway's Key cannot be set for outgoing data without modification current ISAKMP spec. If tunneling address is not shared by many gateways, routing flip-flop won't be a problem since encapsulated packets will have real (not virtual) gateway address in their outer headers. Discovering a chain of gateways ----------------------------------------- An organization security policy would require that a server be accessible through multiple nested SAs. There can be two polar cases, specifically: - The inner gateway or server itself requires data to be encrypted. A number of outer gateways perform the authentication of a client traversing nested secured borders. - The outer gateway provides data confidentiality for a client. A number of inner gateways perform authentication and authorization of a client to use specific resource of a server. In either case, the chain of nested SAs has to be built up. If addresses and/or Keys need to be discovered, below is possible algorithm. 1. A client follows to scheme of discovering IPsec gateway as described before. 2. First (outer) IPsec gateway, acting on behalf of remote server, establishes ISKAMP SA with that client. 3. Client requests from just found gateway an application level SA targeted to the ISAKMP daemon port of a remote server. 4. Upon successful creation of above SA, client sends ISAKMP SA request that has to traverse through first (outer) gateway. Outer gateway strips encrypted payload and forwards encapsulated ISAKMP SA request destined to remote server. 5. Second gateway intercepts that request and replies to client claiming to be intermediate to be also taken into effect. 6. The outer gateway now gets the fact of ISAKMP SA reply going to a client, but it's source address does not match just created application-level SA. 7. Since there is no support in present ISAKMP draft for signaling on such a case, a workaround is to add extra logic into IPsec gateway implementation. The logic is based on the following facts: - The gateway provides discovering function for a client - Client has been served, i.e. ISAKMP SA in behalf of remote server has been established by the gateway - Local security policy on the gateway allows propagation of next gateway discovering 8. The same algorithm is applied until remote server has been reached. Note that if the server runs IPsec it just responds with it own address in the reply, thus terminating the algorithm. Otherwise, a gateway closest to remote server, knowing that the server is on non secured wire refuses creation of next ISAKMP SA. 9. Client is now aware of all gateways and its order. Thus, it can start negotiating of an application level SAs nested according to just discovered information. Just described approach can be generalized, so it would work for discovering backup path as well as for completing any of mentioned above tasks. Good stuff to put into IPsecond ----------------------------------------- This section introduces areas of further improvements IPsec technology towards it scalability and functionality. Nevertheless, topics discussed below do not prevent implementation of IPsec gateway discovering functions based on only whatever is available (and standardized) to date. Suggested improvements just make possible IPsec implementation less complex and more straightforward. Address, Key and IPsec Trust Domains ------------------------ The IPsec Trust Domain term represents the authenticated knowledge of IPsec related configuration parameters. The knowledge is separated from policy enforcement. Instead, it can be used as a statement in high-level policy abstraction. Although the detailed explanation of the Trust Domain term is of other document scope, some issues are discussed below. Suppose, Security Administrator of a gateway has RSA key that is used to sign the gateway key. The name of gateway key can be just it IP address. Suppose also that Network Administrator has own RSA key that is used to sign the address of gateway and subnet resided behind this gateway. Both administrators public keys are enclosed in certificates signed by some other party. Both certificates have Trust Domains identifiers and constraints. Trust Domain identifiers correspond to the right of signing gateway keys and gateway addresses respectively. The constraints are hosts or/and subnets list. The party used to sign above certificates has it own certificate containing Trust Domain identifier and constraints. The Trust Domain identifier says that that party can sign certificates of above mentioned Trust Domains. The constraints restrict such privileges to some network domain (XYZ.COM). The party certificate is also signed. The chain ends up with well-known Certificate signed by well-known Authority. An IPsec gateway can have all the chain preloaded and send it to a client through ISAKMP payloads, which are to be invented. A client might have a policy statement constructed from Authority Certificate and Trust Domains to be enforced from it. Explicit signaling of gateway discovering ------------------------ This attribute/payload to be added in ISAKMP spec would simplify the following things: 1. To have separate policy on a gateway, stating the client's right to do nested SAs discovering through multiple secured borders. 2. To simplify authorization on backup gateway to restore client application-level SAs somewhere in the middle of yet established network connections (considering recovering due to primary gateway failure) 3. To reduce number of ISAKMP SAs maintained on the gateway and client, if the last one is trying to discover a gateway for yet another remote server from the same subnet. Explicit notification on changed routing path ------------------------ Suppose, all gateways of secured network border employ the same tunneling address for using by outside. That case greatly improves secured connectivity to inside resources. A client system might have number of ISAKMP SAs being created at the same time with different gateways. The question is which one is to be active at present moment. It is possible to use 'keep alive' message for testing current routing path, but there is no notification type to be returned by a gateway indicating that other ISKAMP SA has to be established/activated on the client side. The notification would include client Cookie identifying the 'keep-alive' message occasionally received by a gateway. The best solution is to provide separate authentication for this notification for a client. Explicit signaling on creation of one-way SA ------------------------ Consider the case when secured data are going different ways in different directions through some network border. For a client, it results to two the same application-level SAs are active simultaneously. A client has to understand which SA is to use for encryption and which one for decryption. The order of SAs creation does not always work, especially when routing is switched during SA lifetime. Authenticated connections list ------------------------ In case, when a client is switching on a backup gateway, the yet established connections list has to be moved to that gateway transparently for applications. Most firewalls implement a connection bootstrap checking. If a client won't have all connections to be reestablished, it must convince the backup gateway that all connections were created before the right way. The problem has simple solution if a client can always present these connections as authenticated by previously used gateway. Authentication can be a digital signature or it can be a hash over connection information keyed by some shared secret available on all gateways forming fault tolerant environment in an organization. Security considerations ----------------------------------------- The described methodology pretends to improve scalability of IPsec implementation by online discovering of IPsec gateway address and/or it key. However, without strong authentication it is just a way to death to use the retrieved data. At lease following authentication scheme must be supported. 1. Check out that discovered address belongs to administrative domain the remote server does. 2. Check out that discovered Key does match to the list of locally deployed keys corresponded to administrative domain the remote server belongs to. 3. Alternatively for key, check out that signature on discovered Key corresponds to the Certificate Authority of administrative domain the remote server belongs to. Author address information ----------------------------------------- Alexei V. Vopilov Post : 103498, Zelenograd, building 420, N 149, Moscow, Russia. Phone : +7(095) 5367694. E-mail: alx@elnet.msk.ru or alexei.vopilov@usa.net ------=_NextPart_000_005F_01BD30E6.22097B60-- From owner-ipsec Wed Feb 4 04:38:51 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA28886 for ipsec-outgoing; Wed, 4 Feb 1998 04:33:34 -0500 (EST) Message-Id: <3.0.5.32.19980204080224.0096e6e0@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 04 Feb 1998 08:02:24 +0000 To: ipsec@tis.com From: Robert Moskowitz Subject: Current vendor attendance list Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Here is the list of vendors that have responded for the March 2nd IPsec workshop. I appologise for the so far lack of information. Cisco tells me that details will be coming out this week. Part of the problem is that I have been on the road this and last week, so we have not been able to coordinate... "C. Harald Koch" "Jeronimo, Michael" Sheila Frankel "John F. Moehrke" "L. Stuart Vance" "Michael Reilly" Prashant Dholakia "Rizwan Mallal" Norio Korekawa Sumit_Vakil/MW/US/3Com@usr.com smamros@newoak.com (Shawn Mamros) "idris a. kothari" Roy Pereira Saroop Mathur William Dixon Bronislav Kavsan Engineering Atsushi INOUE Matt Thomas Wei Xu Tero Mononen Keith Ker Hugh Daniel Bao Phan Chuck Filson Clemen Jue Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Wed Feb 4 09:24:32 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA01133 for ipsec-outgoing; Wed, 4 Feb 1998 09:17:37 -0500 (EST) Message-ID: <19980204142025.18682.qmail@hotmail.com> X-Originating-IP: [195.25.5.201] From: "REUCHE Anthony" To: ipsec@tis.com Subject: ESP Header Format Content-Type: text/plain Date: Wed, 04 Feb 1998 06:20:24 PST Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, The format of ESP Header describe in the RFC 1827 is: - 32 bits for the Security Association Identifier (SPI) - A variable length for the Opaque Transform Data (OTD) I want to know, if in the OTD I must (or I should) indicate a Next Header and the Lenght of this header or not. If someone can respond, please reply me at: areuche@hotmail.com Anthony REUCHE. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-ipsec Wed Feb 4 12:24:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA02614 for ipsec-outgoing; Wed, 4 Feb 1998 12:22:06 -0500 (EST) X-Sender: dnessett@mail.tdc.3com.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipsec@tis.com From: Dan Nessett Subject: Interactions between IPSEC and NAT Cc: nat@livingston.com Date: Wed, 4 Feb 1998 09:04:05 -0800 Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, I haven't been following the NAT discussions real closely, so let me know if this has already come up. There seems to be a real problem for NAT when end to end IPSEC is used. Since the NAT system must look into application data and change embedded IP addresses (e.g., for FTP PORT commands), if the session is encrypted, this is not possible. Further exacerbating the problem is that FTP seems to be unusual in carrying control and data on separate associations, so for many applications you can't even play tricks like not encrypting the control traffic end-to-end, but encrypting the data traffic. This seems to lead to a model where IPSEC tunnels are used from the end system to the NAT box, then from the NAT box to the remote system (or to the remote NAT box, which tunnels to the remote system). These are IPSEC tunnels not PPTP or L2TP tunnels. This imposes a pretty ugly trust model. Anyone thought about this so that they can provide us with a nice clean answer :-) ? Dan From owner-ipsec Wed Feb 4 12:31:22 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA02681 for ipsec-outgoing; Wed, 4 Feb 1998 12:31:08 -0500 (EST) Date: Wed, 4 Feb 1998 17:42:08 +0000 (GMT) From: George Tsirtsis To: Dan Nessett Cc: ipsec@tis.com, nat@livingston.com Subject: Re: (NAT) Interactions between IPSEC and NAT In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Wed, 4 Feb 1998, Dan Nessett wrote: > > This seems to lead to a model where IPSEC tunnels are used from the end > system to the NAT box, then from the NAT box to the remote system (or to > the remote NAT box, which tunnels to the remote system). These are IPSEC > tunnels not PPTP or L2TP tunnels. This imposes a pretty ugly trust model. > > Anyone thought about this so that they can provide us with a nice clean > answer :-) ? > > Dan > Dan, When you have a NAT at the edge of your network the best you can do is to have an IPSEC tunnel between the NAT and the gateway or the NAT of another network. This would secure communications between the two networks. If host to host IPSEC is required then you can do IPSEC from the host to the NAT, which as you say does not look very good (unless you absolutely trust the NAT). The only other solution that I am aware of is to do 'NAT bypass' as described is draft-tsirtsis-nat-bypass-00.txt. The limitation of this proposal is that requires a relatively large network behind the NAT in order to make sense. Regards George ----------------------------- Internet Transport Research | BTLABS | -------------------------------------------------------------------------- Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of British Telecommunications plc. -------------------------------------------------------------------------- From owner-ipsec Wed Feb 4 15:18:06 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA03760 for ipsec-outgoing; Wed, 4 Feb 1998 15:16:23 -0500 (EST) From: Pyda Srisuresh Message-Id: <199802042012.MAA28534@server.livingston.com> Subject: Re: (NAT) Interactions between IPSEC and NAT (fwd) To: ipsec@tis.com Date: Wed, 4 Feb 1998 12:15:42 -0800 (PST) Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Forwarded message: >From owner-nat Wed Feb 4 12:09:27 1998 From: Pyda Srisuresh Message-Id: <199802042008.MAA28067@server.livingston.com> Subject: Re: (NAT) Interactions between IPSEC and NAT To: Dan_Nessett@tdc.3com.com Date: Wed, 4 Feb 1998 12:11:58 -0800 (PST) Cc: ipsec@tic.com, nat@livingston.com, gabriel.montenegro@eng.sun.com, vipul.gupta@eng.sun.com In-Reply-To: from "Dan Nessett" at Feb 4, 98 09:04:05 am Content-Type: text Sender: owner-nat Precedence: bulk Reply-To: Pyda Srisuresh Hi, Please note my comments below. cheers, suresh > > Folks, > > I haven't been following the NAT discussions real closely, so let me know > if this has already come up. There seems to be a real problem for NAT when > end to end IPSEC is used. Since the NAT system must look into application > data and change embedded IP addresses (e.g., for FTP PORT commands), if the > session is encrypted, this is not possible. Further exacerbating the > problem is that FTP seems to be unusual in carrying control and data on > separate associations, so for many applications you can't even play tricks > like not encrypting the control traffic end-to-end, but encrypting the data > traffic. You could play this trick and NAT wouldnt have a problem with it. FTP control and data pkts would traverse transparantly through the NAT router. NAT routers do not look into the payload of FTP data sessions. > > This seems to lead to a model where IPSEC tunnels are used from the end > system to the NAT box, then from the NAT box to the remote system (or to > the remote NAT box, which tunnels to the remote system). These are IPSEC > tunnels not PPTP or L2TP tunnels. This imposes a pretty ugly trust model. > I understand, having a NAT box doing any kind of mods sitting between two end nodes is not acceptable for end-to-end security stand point. A recent draft, titled "NAT bypass for end-2-end sensitive applications", by George Tsirtsis and Alan Oneil () offers an alternative solution where end-2-end security is preserved. To put things in perspective, I think, the above draft has parallels to an entirely different draft from Mobile IP group by G. Montenegro and V. Gupta, titled "Firewall support for Mobile IP" ( Anyone thought about this so that they can provide us with a nice clean > answer :-) ? > > Dan > > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe nat' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-ipsec Wed Feb 4 15:49:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA03935 for ipsec-outgoing; Wed, 4 Feb 1998 15:48:24 -0500 (EST) Message-Id: <199802042059.PAA23774@jekyll.piermont.com> To: Dan Nessett cc: ipsec@tis.com, nat@livingston.com Subject: Re: Interactions between IPSEC and NAT In-reply-to: Your message of "Wed, 04 Feb 1998 09:04:05 PST." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 04 Feb 1998 15:59:59 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan Nessett writes: > Anyone thought about this so that they can provide us with a nice clean > answer :-) ? Yes. If you want security, you can't use NAT, because by definition the thing NAT is trying to do (peek in and/or alter your packets) is what security is designed to prevent. Protocols like SSL have exactly the same issue, btw. Any protocol that protects the contents of your data will have the same issue. This is not fixable -- any "fixes" someone could propose to this would be so horrible as to make the entire point of security moot. Perry From owner-ipsec Wed Feb 4 19:05:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA05143 for ipsec-outgoing; Wed, 4 Feb 1998 19:04:31 -0500 (EST) Message-Id: <199802050015.TAA27199@jekyll.piermont.com> To: Vinod Valloppillil cc: ipsec@tis.com, nat@livingston.com Subject: Re: (NAT) Re: Interactions between IPSEC and NAT In-reply-to: Your message of "Wed, 04 Feb 1998 15:26:10 PST." <5CEA8663F24DD111A96100805FFE658701FDE818@red-msg-51.dns.microsoft.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 04 Feb 1998 19:15:11 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Vinod Valloppillil writes: > that's a pretty large overstatement, IMHO. > > fundamentals of IPSEC/NAT aside, it doesn't seem theoretically impossible to > separate IP addressing from end-to-end payload security. I'm afraid it must be. The alteration of addresses and/or ports has security implications. We in the security community have found, from bitter experience, that "trivial changes" to protocols often have drastic consequences. IPsec secures the entire packet. If we were to declare that the end system address and/or ports were to not be protected, in theory NAT could continue to work. However, were we to do such a thing, I'm almost certain that, given time and effort, I could come up with fascinating new attacks that could be performed upon such packets -- things like convincing legitimate traffic to be sent from a legtimate port to an illegitimate one with grave consequences, for example. If you want end to end security, you can't allow packets to be modified between the endpoints. > HTTPS through a NAT, for example, is perfectly reasonable HTTPS doesn't embed things like ports into the communications stream, so it can be NATed. SSL is the security layer HTTPS uses, but SSL != HTTPS -- other protocols over SSL will not behave so nicely. Perry From owner-ipsec Wed Feb 4 19:38:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA05316 for ipsec-outgoing; Wed, 4 Feb 1998 19:37:31 -0500 (EST) Message-Id: <199802050050.TAA27730@jekyll.piermont.com> To: Vinod Valloppillil cc: "'perry@piermont.com'" , ipsec@tis.com, nat@livingston.com Subject: Re: (NAT) Re: Interactions between IPSEC and NAT In-reply-to: Your message of "Wed, 04 Feb 1998 16:25:03 PST." <5CEA8663F24DD111A96100805FFE658701FDE81E@red-msg-51.dns.microsoft.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 04 Feb 1998 19:50:05 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Vinod Valloppillil writes: > > >> HTTPS through a NAT, for example, is perfectly reasonable > > >HTTPS doesn't embed things like ports into the communications stream, > >so it can be NATed. SSL is the security layer HTTPS uses, but SSL != > >HTTPS -- other protocols over SSL will not behave so nicely. > > But my example of HTTPS through NAT is a case where you both both NAT > features and end-to-end security. My point was to demonstrate the > independance of IP addr/ports from end-end security. You've demonstrated nothing of the sort. All you've shown is that there exists a particular protocol that does okay that way. Unless you are proposing that the only application for the internet is web service over HTTPS, I'm afraid you'll have to accept that some protocols do not and cannot play well with both NAT and end to end security. Perry From owner-ipsec Wed Feb 4 19:44:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA05380 for ipsec-outgoing; Wed, 4 Feb 1998 19:44:30 -0500 (EST) Message-Id: <199802050056.TAA01176@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com CC: vinodv@microsoft.com Subject: Re: (NAT) Re: Interactions between IPSEC and NAT In-reply-to: Your message of "Wed, 04 Feb 1998 16:25:03 PST." <5CEA8663F24DD111A96100805FFE658701FDE81E@red-msg-51.dns.microsoft.com> Date: Wed, 04 Feb 1998 19:55:56 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Vinod" == Vinod Valloppillil writes: >>> HTTPS through a NAT, for example, is perfectly reasonable >> HTTPS doesn't embed things like ports into the communications stream, >> so it can be NATed. SSL is the security layer HTTPS uses, but SSL != >> HTTPS -- other protocols over SSL will not behave so nicely. Vinod> But my example of HTTPS through NAT is a case where you both both Vinod> NAT features and end-to-end security. My point was to demonstrate Vinod> the independance of IP addr/ports from end-end security. - To HTTPS is HTTP over SSL over TCP. So, with HTTPS you get all of the normal denial of service attacks you would expect to see with TCP: - SYN flooding - sequence number prediction - RST on ports - Adjustment of windows so that no data flows - replay of TCP segments with "new" segment numbers (probably causing SSL's MAC to abort the HTTPS transfer, while IPsec would just assume the packet got lost and TCP would retransmit) IPsec tries to defend against all of these. Whether or not ISAKMP's cookie mechanism is strong enough to deal with these attacks has been disputed by a couple of well known people, but, assuming that it isn't strong enough, we can replace (or rev) ISAKMP much easier than we can rev the wire format of the packets. :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON Michael Richardson |Network and security consulting and contract programming Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNNkOEdiXVu0RiA21AQE7dgMAg0E8nkXygRiIjJvOQoM1V1c70+3oDMUm Rg224SBD+U1/vL54Gdq+YpXUY0EUIndtg8udfHmcJuuCXksE2c5U95HsX7qcVbB2 vaxRdUWEOdVpDDbZXpTHzRjpaA5RkKhP =MzxX -----END PGP SIGNATURE----- From owner-ipsec Wed Feb 4 21:53:51 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA06228 for ipsec-outgoing; Wed, 4 Feb 1998 21:52:36 -0500 (EST) Message-Id: <199802050302.WAA27045@postal.research.att.com> To: Vinod Valloppillil cc: "'perry@piermont.com'" , ipsec@tis.com, nat@livingston.com Subject: Re: (NAT) Re: Interactions between IPSEC and NAT Date: Wed, 04 Feb 1998 22:02:33 -0500 From: Steve Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk >> HTTPS through a NAT, for example, is perfectly reasonable >HTTPS doesn't embed things like ports into the communications stream, >so it can be NATed. SSL is the security layer HTTPS uses, but SSL != >HTTPS -- other protocols over SSL will not behave so nicely. But my example of HTTPS through NAT is a case where you both both NAT features and end-to-end security. My point was to demonstrate the independance of IP addr/ports from end-end security. As always, there are tradeoffs. Every form of encryption has its own advantages and disadvantages. Some forms play more nicely with NAT than do others; by the same token, they have their own peculiar limitations. IPsec operates below the transport layer. This means that it protects the entire transport packet -- for TCP or UDP -- including the header. As noted by others, that provides protection against SYN flooding, spurious RST packets, and a host of other ills. Among the interesting fields protected is the transport checksum -- which, in the case of TCP and UDP, would include the pseudo-header. And that, of course, has the source and destination IP addresses. This is a fundamental incompatibility with NAT -- you can't diddle *any* IPsec-protected packet, even if the protocol in question doesn't contain embedded IP addresses. On the other hand, IPsec generally requires kernel-level changes; an application can't implement it for itself on most systems. That's why Netscape introduced SSL -- it was something that an application could do, without modification to the operating system. SSL operates above TCP. This means that you can pass it through a NAT gateway for protocols that don't use embedded IP addresses. The Web is usually clean, though some sites are foolish enough to use IP addresses in URLs or cookies. A more serious drawback to SSL is that in general, one does have to touch every application. While one could conceivably tinker with the libraries -- say, a funky DLL on Windows, or a shared library on UNIX systems -- most protocols don't know how to decline SSL if they weren't designed for such things. Even if they were -- telnet comes to mind -- the negotiation is inherently protocol-specific; a hack that might work for SMTP (say, via ELHO) wouldn't work for NNTP. Web browsers don't even try negotiating at this level, for the obvious reason that it's too messy -- they just use a different port number. And there's no fallback (at least, not in any browser I've seen) -- if no one is hope on port 443, the connection attempt simply fails. Which is better, IPsec or SSL? I don't know; which is better, blue or red? Oranges or apples? Compact or tasty? As always, it's wise to look at our middle name: "engineering". There are tradeoffs; what's best for one situation is not best for another. In general, I like IPsec better, especially because it's so well-suited to gateway-to-gateway or host-to-gateway encryption. That let's a site make its own tradeoffs between economy of deployment and granularity of protection. But there's no doubt that SSL (and ssh, which operates at a similar layer) are protecting far more sessions (and probably bytes) in today's Internet, because they're easier to deploy. Furthermore, they provide even finer-grained protection -- to the level of the individual user. IPsec is supposed to be able to do that, but it's relatively hard to do. I strongly doubt that there are any magic NAT fixes that can make it play more nicely with IPsec. The purpose of NAT is to make unpleasant (but hopefully useful) changes to packets; however, a design goal of IPsec was to prevent any changes, pleasant or not, useful or not. If you must have both, you'll probably have to do both on the same box, in an integrated fashion. That may mean the end systems, of course. (As a teaser, that's not a ridiculous statement. In fact, there are characteristics of IPsec that make co-resident NAT work quite nicely. In my copious free time, I'm trying draft an RFC entitled "IPsec, EIDs, and HostNAT", where EID is "endpoint identifier".) From owner-ipsec Wed Feb 4 22:29:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA06408 for ipsec-outgoing; Wed, 4 Feb 1998 22:29:32 -0500 (EST) Message-Id: <3.0.3.32.19980204194615.0090c100@Netcom.Com> X-Sender: andrade@Netcom.Com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Wed, 04 Feb 1998 19:46:15 -0800 To: perry@piermont.com, Dan Nessett From: Alex Alten Subject: Re: Interactions between IPSEC and NAT Cc: ipsec@tis.com, nat@livingston.com In-Reply-To: <199802042059.PAA23774@jekyll.piermont.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 03:59 PM 2/4/98 -0500, Perry E. Metzger wrote: > >Dan Nessett writes: >> Anyone thought about this so that they can provide us with a nice clean >> answer :-) ? > >Yes. If you want security, you can't use NAT, because by definition >the thing NAT is trying to do (peek in and/or alter your packets) is >what security is designed to prevent. Protocols like SSL have exactly >the same issue, btw. Any protocol that protects the contents of your >data will have the same issue. > >This is not fixable -- any "fixes" someone could propose to this would >be so horrible as to make the entire point of security moot. > >Perry > > This is what bothers me about the direction IPSEC has taken. The addition of security should not break things like trusted NATs. If you define an IP "trusted node" as all hosts, routers, firewalls, NATs, etc., that want to interoperate securely as a secure network. Then the only thing IPSEC should do is secure IP packets, the IP header and payload, between two trusted nodes (actually between two trusted interfaces). The question that remains is whether or not to allow untrustworthy nodes to handle the IP packets. If not, then encrypt the IP header, since all the trusted routers can decrypt it, decide how to route it, and then re-encrypt before transmitting it. If so, then just MAC the IP header (but still encrypt & MAC the payload). In this latter case insecure NATs (and routers which fragment) will not be able to work with the secure nodes, but any insecure node that doesn't adjust the IP packet will work as-is. The really difficult issues of how to establish and control the network of trusted nodes, and how to implement and enforce network-wide policy can then be tackled. - Alex Alex Alten Andrade@Andrade.Com P.O. Box 11406 Pleasanton, CA 94588 USA (510) 417-0159 From owner-ipsec Thu Feb 5 00:58:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA07221 for ipsec-outgoing; Thu, 5 Feb 1998 00:57:34 -0500 (EST) Message-Id: <199802050609.BAA03281@jekyll.piermont.com> To: Alex Alten cc: ipsec@tis.com, nat@livingston.com Subject: Re: Interactions between IPSEC and NAT In-reply-to: Your message of "Wed, 04 Feb 1998 19:46:15 PST." <3.0.3.32.19980204194615.0090c100@Netcom.Com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Thu, 05 Feb 1998 01:09:39 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Alex Alten writes: > This is what bothers me about the direction IPSEC has taken. The > addition of security should not break things like trusted NATs. The function of IPsec is to keep a packet from being touched or read in transit. That is, for good or ill, fundamentally incompatible with the concept of network address translation. As a security weenie, I cannot think of a way to avoid this -- its like asking for a method of contraception that also allows pregnancy. The two don't mix. IPsec protects you against all sorts of nasty attacks like IP address spoofing, but the only reasonable way to do that means that no one in your communications path can fiddle with your packets. With that in place, NAT is impossible. If you remove that, you remove the security. I do not see any way to fix that. I wish to be very clear to the NAT people -- security is not magic. We aren't sadists who are withholding the magic security pixie dust, which, would we just release it, would bring a protocol that makes everything secure and imposes no pain. We aren't hiding some nifty cool way to do things from you to be mean. We don't know of any such solution -- I would go so far as to say, in fact, that there is no such solution. If you want security, you have to suffer certain tradeoffs. If you want people not to be able to do very vicious things to you that will cause you trouble -- vicious things involving spoofing portions of your datagrams -- you need security that prevents people from mucking with your datagrams. Well, that has an obvious impact on doing NAT, for good or ill. > If not, then encrypt the IP header, since all the trusted routers > can decrypt it, decide how to route it, and then re-encrypt before > transmitting it. We don't do that, actually. You can't bring all the routers on the internet into your security perimeter -- that simply won't work. Thus, we don't try. IPsec works via encapsulation -- the outer IP address is in the clear, as it must be for routing to work. For stuff like NAT to work you would need to include all NAT boxes and routers in your security perimeter, and I fundamentally cannot think of a design for this stuff that will work and will involve arbitrary numbers of intermediate nodes on the global internet -- I belive that it just can't be done in practice. Maybe I'm just not bright enough, but I think that instead its an issue of having enough arrows in my back to know better. > The really difficult issues of how to establish and control the > network of trusted nodes, and how to implement and enforce > network-wide policy can then be tackled. When you come up with a functioning protocol, let us know. I don't believe one is possible, but I'm more than willing to listen. Perry From owner-ipsec Thu Feb 5 02:09:09 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA07646 for ipsec-outgoing; Thu, 5 Feb 1998 02:06:35 -0500 (EST) Message-Id: <3.0.3.32.19980204232324.0092e5d0@Netcom.Com> X-Sender: andrade@Netcom.Com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Wed, 04 Feb 1998 23:23:24 -0800 To: perry@piermont.com From: Alex Alten Subject: Re: Interactions between IPSEC and NAT Cc: ipsec@tis.com, nat@livingston.com In-Reply-To: <199802050609.BAA03281@jekyll.piermont.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 01:09 AM 2/5/98 -0500, Perry E. Metzger wrote: > >Alex Alten writes: >> This is what bothers me about the direction IPSEC has taken. The >> addition of security should not break things like trusted NATs. > >The function of IPsec is to keep a packet from being touched or read >in transit. IP packets are designed with routing in mind. There are fields which need to be adjusted between hops. This means IP security can only be designed with a single hop in mind. This also means that IP security must be part of a complete security system, of which IP security is just one component, the component which protects inter-router hops. A secure, trusted NAT can certainly be part of that system. >> If not, then encrypt the IP header, since all the trusted routers >> can decrypt it, decide how to route it, and then re-encrypt before >> transmitting it. > >We don't do that, actually. You can't bring all the routers on the >internet into your security perimeter -- that simply won't work. Thus, >we don't try. IPsec works via encapsulation -- the outer IP address is >in the clear, as it must be for routing to work. This is realistic, I stated this as my alternative. However the outer IP address must be at least be verified somehow, either via a MAC over it or duplicate routing information inside the protected encapsulation area. >For stuff like NAT to work you would need to include all NAT boxes and >routers in your security perimeter, and I fundamentally cannot think >of a design for this stuff that will work and will involve arbitrary >numbers of intermediate nodes on the global internet -- I belive that >it just can't be done in practice. Maybe I'm just not bright enough, >but I think that instead its an issue of having enough arrows in my >back to know better. > I absolutely agree. In fact, regardless of NAT, all the routers must be part of the security system (or security perimeter). For an arbitrary number of insecure routers, then I think only a transport or application level security will work. >> The really difficult issues of how to establish and control the >> network of trusted nodes, and how to implement and enforce >> network-wide policy can then be tackled. > >When you come up with a functioning protocol, let us know. I don't >believe one is possible, but I'm more than willing to listen. > Admittedly it is a tough problem to solve, given the datagram nature of IP and its high performance requirements for routing. It's much easier to do it at the TCP level. - Alex -- Alex Alten Andrade@Netcom.Com P.O. Box 11406 Pleasanton, CA 94588 USA (510) 417-0159 From owner-ipsec Thu Feb 5 02:29:07 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA07755 for ipsec-outgoing; Thu, 5 Feb 1998 02:27:35 -0500 (EST) Message-Id: <199802050739.CAA05166@jekyll.piermont.com> To: Alex Alten cc: ipsec@tis.com, nat@livingston.com Subject: Re: Interactions between IPSEC and NAT In-reply-to: Your message of "Wed, 04 Feb 1998 23:23:24 PST." <3.0.3.32.19980204232324.0092e5d0@Netcom.Com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Thu, 05 Feb 1998 02:39:51 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Alex Alten writes: > At 01:09 AM 2/5/98 -0500, Perry E. Metzger wrote: > > > >Alex Alten writes: > >> This is what bothers me about the direction IPSEC has taken. The > >> addition of security should not break things like trusted NATs. > > > >The function of IPsec is to keep a packet from being touched or read > >in transit. > > IP packets are designed with routing in mind. There are fields which > need to be adjusted between hops. This means IP security can only be > designed with a single hop in mind. Maybe you ought to read the spec. It might answer a lot of your questions. Believe it or not, we did know what we were doing. > In fact, regardless of NAT, all the routers must be part of the > security system (or security perimeter). For an arbitrary number of > insecure routers, then I think only a transport or application level > security will work. Your viewpoint is a wee bit unrealistic -- there is, in practice, no way to make even a tiny fraction of the routers trusted. It is also unneeded -- we know how to provide security in a network where nothing except the endpoints need to be trusted. Might I suggest that you study this topic a bit more in depth before commenting further? Perry From owner-ipsec Thu Feb 5 03:49:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA08247 for ipsec-outgoing; Thu, 5 Feb 1998 03:46:37 -0500 (EST) Message-Id: <3.0.3.32.19980205010331.0091b6f0@Netcom.Com> X-Sender: andrade@Netcom.Com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Thu, 05 Feb 1998 01:03:31 -0800 To: perry@piermont.com From: Alex Alten Subject: Re: Interactions between IPSEC and NAT Cc: ipsec@tis.com, nat@livingston.com In-Reply-To: <199802050739.CAA05166@jekyll.piermont.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 02:39 AM 2/5/98 -0500, Perry E. Metzger wrote: >Maybe you ought to read the spec. It might answer a lot of your >questions. Believe it or not, we did know what we were doing. I have to really question if you knew what you were doing. Go read Rogaway's cryptographic analysis--have you fixed the issues he raised? Are you still seriously considering a PK solution for managing trust? If so, then God help anybody that has to implement it and get a real customer to use it. >Your viewpoint is a wee bit unrealistic -- there is, in practice, no >way to make even a tiny fraction of the routers trusted. It is also >unneeded -- we know how to provide security in a network where nothing >except the endpoints need to be trusted. Unfortunately you have come up with a solution I find cumbersome, slow, difficult to administer, with an awkward trust model, no auditing, and no key recovery. > Might I suggest that you >study this topic a bit more in depth before commenting further? You know Perry, not everyone who studies this field goes off and wastes their time writing RFC's and I-D's. I prefer to apply for patents and sell them. - Alex -- Alex Alten Andrade@Netcom.Com P.O. Box 11406 Pleasanton, CA 94588 USA (510) 417-0159 From owner-ipsec Thu Feb 5 04:52:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA08599 for ipsec-outgoing; Thu, 5 Feb 1998 04:45:35 -0500 (EST) Date: Thu, 5 Feb 1998 09:55:18 +0000 (GMT) From: George Tsirtsis To: bound@zk3.dec.com Cc: Alex Alten , perry@piermont.com, Dan Nessett , ipsec@tis.com, nat@livingston.com Subject: Re: (NAT) Re: Interactions between IPSEC and NAT In-Reply-To: <199802050500.AA03698@wasted.zk3.dec.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Jim, On Thu, 5 Feb 1998 bound@zk3.dec.com wrote: > > I have already figured out to avoid NAT in most cases with IPv6 and now > working on an NNAT for IPv4 if I can find someone who wants to do the > writing? At first I thought DHCPv4 could not do NNAT but now I think it > can though it does not have the Reconfigure msg of DHCPv6 I think we can > do it with Multicast packets. The other option is to use DHCPv6 for > IPv4 nodes too, which is possible. Glad to hear that you desided to work on that. I always thought it was a good idea. > > For those that want IPSEC, but need a temporary address like NAT does, > the goal is to just avoid using NAT and I think this is very doable. Exactly! 'NAT bypass' is one way to do that and I hope you will find out another. > > I am not saying that NAT cannot still be used cause it will at least > until IPv6 is pervasive, but I think we (engineers) are trying to solve > this problem in the wrong way. We should be working on solutions to > avoid NAT when it is not an optimal way to do "business" on the Internet. In all this thread of discussion three solutions for NAT and IPSEC coexistance have been proposed. 1) Implement NAT and IPSEC at the same node. This can give you gateway to gateway security. 2) Do the above plus IPSEC between end-user and NAT. This can only work if the NAT is trusted and will give a kind fo end to end security, thought, a lot of people will argue with this... 3) Try to avoid NAT when IPSEC (or other end-to-end sensitive app.) is required. 'NAT bypass' attempts to do exactly that by building an l2tp tunnel (nothing to do with IPSEC tunnels) between itself and the NAT. The NAT then sends a global IP address through the tunnel and the host can now use the globally valid IP address to do IPSEC end-to-end, bypassing the NAT function. > > Do we discuss such notions here or do we need to have an Avoidance of > NAT BOF and eventual Working Group at the L.A. IETF? > I think NAT BOF (WG?) should be OK for that. I think NAT BOF was not about making NAT work, it was more about addressing the problems that NAT introduces. > Changing IPSEC for NAT is a bad engineering idea IMO. Agree! > > /jim > Best Regards George ----------------------------- Internet Transport Research | BTLABS | -------------------------------------------------------------------------- Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of British Telecommunications plc. -------------------------------------------------------------------------- From owner-ipsec Thu Feb 5 07:27:38 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA09525 for ipsec-outgoing; Thu, 5 Feb 1998 07:26:37 -0500 (EST) From: Cheng_Chen@3com.com X-Lotus-FromDomain: 3COM To: "Perry E. Metzger" cc: Dan Nessett , ipsec@tis.com, nat@livingston.com, paul_douglas@3com.com, raj_bhatia@3com.com, ken_araujo@3com.com Message-ID: <852565A1.0082AA92.00@hqoutbound.ops.3com.com> Date: Wed, 4 Feb 1998 18:55:07 -0500 Subject: Re: Interactions between IPSEC and NAT Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@ex.tis.com Precedence: bulk We all lock our house every morning when we go to work, although we know that any average thief will be able to break it. So many of us pay $3000 to install the home security system, although we know that any average thief will cut your power line to disable the security system before they enter the house. NAT is valuable to many people. As a NAT user, a less than perfect security is better than NO security at all. Don't you lock your front door every morning? Cheng ----- Previous Message ---------------------------------------------------- To: Dan Nessett cc: ipsec @tis.com nat @livingston.com From: "Perry E. Metzger" @ UGATE Date: Wednesday February 4, 1998 03:59 PM Subject: Re: Interactions between IPSEC and NAT --------------------------------------------------------------------------- -------------------------------------------------------------------- ----------------------------------------------- Dan Nessett writes: > Anyone thought about this so that they can provide us with a nice clean > answer :-) ? Yes. If you want security, you can't use NAT, because by definition the thing NAT is trying to do (peek in and/or alter your packets) is what security is designed to prevent. Protocols like SSL have exactly the same issue, btw. Any protocol that protects the contents of your data will have the same issue. This is not fixable -- any "fixes" someone could propose to this would be so horrible as to make the entire point of security moot. Perry From owner-ipsec Thu Feb 5 07:27:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA09533 for ipsec-outgoing; Thu, 5 Feb 1998 07:27:36 -0500 (EST) From: bound@zk3.dec.com Message-Id: <199802050500.AA03698@wasted.zk3.dec.com> To: Alex Alten Cc: perry@piermont.com, Dan Nessett , ipsec@tis.com, nat@livingston.com Subject: Re: (NAT) Re: Interactions between IPSEC and NAT In-Reply-To: Your message of "Wed, 04 Feb 1998 19:46:15 PST." <3.0.3.32.19980204194615.0090c100@Netcom.Com> Date: Thu, 05 Feb 1998 00:00:47 -0500 X-Mts: smtp Sender: owner-ipsec@ex.tis.com Precedence: bulk I think IPSEC has it right, and Perry gave us the bottom line many messages ago. I am talking to my friend Ray at X and I encrypt my packet which is the checksum and all stuff. IPSEC gives me the hope that NO ONE else can see the data including my ISP or routers or NAT boxes I don't even know, between me and Ray. I like the idea of not being violated on the Internet. I have already figured out to avoid NAT in most cases with IPv6 and now working on an NNAT for IPv4 if I can find someone who wants to do the writing? At first I thought DHCPv4 could not do NNAT but now I think it can though it does not have the Reconfigure msg of DHCPv6 I think we can do it with Multicast packets. The other option is to use DHCPv6 for IPv4 nodes too, which is possible. For those that want IPSEC, but need a temporary address like NAT does, the goal is to just avoid using NAT and I think this is very doable. I am not saying that NAT cannot still be used cause it will at least until IPv6 is pervasive, but I think we (engineers) are trying to solve this problem in the wrong way. We should be working on solutions to avoid NAT when it is not an optimal way to do "business" on the Internet. Do we discuss such notions here or do we need to have an Avoidance of NAT BOF and eventual Working Group at the L.A. IETF? Changing IPSEC for NAT is a bad engineering idea IMO. /jim From owner-ipsec Thu Feb 5 10:18:23 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA10805 for ipsec-outgoing; Thu, 5 Feb 1998 10:07:47 -0500 (EST) Message-Id: <199802051516.KAA05652@istari.sandelman.ottawa.on.ca> To: bound@zk3.dec.com, ipsec@tis.com, nat@livingston.com Subject: Re: (NAT) Re: Interactions between IPSEC and NAT In-reply-to: Your message of "Thu, 05 Feb 1998 00:00:47 EST." <199802050500.AA03698@wasted.zk3.dec.com> Date: Thu, 05 Feb 1998 10:15:55 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "bound" == bound writes: bound> I have already figured out to avoid NAT in most cases with IPv6 bound> and now working on an NNAT for IPv4 if I can find someone who bound> wants to do the writing? At first I thought DHCPv4 could not do bound> NNAT but now I think it can though it does not have the bound> Reconfigure msg of DHCPv6 I think we can do it with Multicast bound> packets. The other option is to use DHCPv6 for IPv4 nodes too, bound> which is possible. I think, what you are suggesting, is that: if an end host is going to modified to do IPsec (on board or off board), then it can be modified to do the appropriate NAT as well. This is distributed NAT. IPv6 with its use of DHCP and site local addresses, practically mandates that hosts support using different addresses depending on where the other end of the connection is going to be. The only problem is getting the "external" address allocated, and letting the centralized NAT box know about this so that it can route and/or tunnel packets that match the appropriate "external" address (may include port and SPI in its decision in the case of many-to-one NAT) to the internal box. The solution, I must agree, is not to break IPsec, but to build smarter NAT systems. The Internet was built around stateless routers (some say this is part of its success), while NAT boxes and firewalls are stateful, so they are violating the design architecture. Until one deploys IPsec on the end nodes, NAT and IPsec will have to live on the same box and will have to share state. In my drafts involving multiple firewall (or NAT) traversal, I didn't say where exactly NAT was done, although I was trying to arrange the SA's such that the firewall would be able to audit the packets in one mode, and modify them in another mode. It involve transitive trust, which is hard. :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON Michael Richardson |Network and security consulting and contract programming Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNNnXqdiXVu0RiA21AQFU2gL/Xv6W1aixBSIQs9wj5P0npaz4Gm1+cmoC HrkGBvH967XBv0laXQJoZtdvk36huHo06Buxc3X1vnjpWO+7x8LI8QEbkpbRQKYF QPxsmX3c+pZb56TLSQgJdHmJvwp+PInR =pKf6 -----END PGP SIGNATURE----- From owner-ipsec Thu Feb 5 10:30:02 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA10990 for ipsec-outgoing; Thu, 5 Feb 1998 10:26:41 -0500 (EST) From: owner-ipsec@ex.tis.com To: ipsec@tis.com Message-ID: <862565A2.00520DCA.00@mwgate01.mw.3com.com> Date: Thu, 5 Feb 1998 09:18:31 -0600 Subject: SKEYID lengths and IVs Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi. I had some questions on Appendix B of the Resolution draft: 1. SKEYID length: Appendix B of the resolution draft explains a method to increase the length of the SKEYIDs if the output of the PRF is not long enough. How is the length of the SKEYIDs determined in the first place? Is it 'atleast' 90 bits as per the Oakley draft? Also, if SKEYID_d is going to be derived this way, what is the reason for expanding SKEYID? Is this method for use with SKEYID_d only or would it be used for SKEYID_e also? If it is to be used with SKEYID_e, then why use the key expansion method described later on instead of just expanding SKEYID_e, and then using the required number of octets from it as the encryption key? 2. IV generation for phase 2 messages: Appendix B also describes how to generate IVs for encrypting phase 2 exchanges. It states that the IV for the first phase 2 message is derived from a hash of the concatenation of the last phase 1CBC output block and the phase 2 message id. Since the Aggressive exchange does not encrypt any messages, there would be no phase 1CBC output blocks. How would the phase 2 IV be derived in this case? Should the hash of the concatenation of the two sides' public Diffie-Hellman values be used instead? Thanks, Sumit A. Vakil 3Com, Corp. From owner-ipsec Thu Feb 5 10:40:48 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA11114 for ipsec-outgoing; Thu, 5 Feb 1998 10:40:42 -0500 (EST) Date: Thu, 5 Feb 1998 10:49:44 -0500 (EST) Message-Id: <199802051549.KAA05251@carp.morningstar.com> From: Ben Rogers To: bound@zk3.dec.com Cc: Alex Alten , perry@piermont.com, Dan Nessett , ipsec@tis.com, nat@livingston.com Subject: Re: (NAT) Re: Interactions between IPSEC and NAT In-Reply-To: <199802050500.AA03698@wasted.zk3.dec.com> References: <3.0.3.32.19980204194615.0090c100@Netcom.Com> <199802050500.AA03698@wasted.zk3.dec.com> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk bound@zk3.dec.com writes: > Do we discuss such notions here or do we need to have an Avoidance of > NAT BOF and eventual Working Group at the L.A. IETF? >From the proposed NAT WG charter: The second set of documents will specify NAT friendly application and protocol design guidelines, interactions between NATs and applications such as DNS and protocols such as IP sec and mobile IP. The documents would also be extended to identify areas where NATs or other protocols and applications can be improved to overcome the shortcomings in interoperability or functionality. Due to the importance of the issue, specific attention will be given to the problems created by NATs for security protocols such as IPsec. Which makes it sound as if they're planning to be handling such issues. I know that one of the important points mentioned in the Washington was that if NAT were going to fly as a WG it would need to work around the security interactions by modifications to the way we do NAT instead of modifications to the way we do security. ben From owner-ipsec Thu Feb 5 10:52:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA11227 for ipsec-outgoing; Thu, 5 Feb 1998 10:51:41 -0500 (EST) Message-Id: <199802051604.LAA05486@jekyll.piermont.com> To: Alex Alten cc: perry@piermont.com, ipsec@tis.com, nat@livingston.com Subject: Re: Interactions between IPSEC and NAT In-reply-to: Your message of "Thu, 05 Feb 1998 01:03:31 PST." <3.0.3.32.19980205010331.0091b6f0@Netcom.Com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Thu, 05 Feb 1998 11:04:21 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Alex Alten writes: > At 02:39 AM 2/5/98 -0500, Perry E. Metzger wrote: > >Maybe you ought to read the spec. It might answer a lot of your > >questions. Believe it or not, we did know what we were doing. > > I have to really question if you knew what you were doing. Go [...flamage deleted...] > You know Perry, not everyone who studies this field goes off and wastes > their time writing RFC's and I-D's. I prefer to apply for patents and sell > them. You will pardon me, but I'm going to cut this off now. I really don't think this is going to be productive for people, and most people probably don't want to read any more comments from me, especially as your comments speak for themselves. Nothing I could possibly say was as damaging to you as your own words. Perry From owner-ipsec Thu Feb 5 11:21:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA11422 for ipsec-outgoing; Thu, 5 Feb 1998 11:20:42 -0500 (EST) Message-Id: <199802051632.LAA05572@jekyll.piermont.com> To: Cheng_Chen@3com.com cc: "Perry E. Metzger" , Dan Nessett , ipsec@tis.com, nat@livingston.com, paul_douglas@3com.com, raj_bhatia@3com.com, ken_araujo@3com.com Subject: Re: Interactions between IPSEC and NAT In-reply-to: Your message of "Wed, 04 Feb 1998 18:55:07 EST." <852565A1.0082AA92.00@hqoutbound.ops.3com.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Thu, 05 Feb 1998 11:32:46 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Cheng_Chen@3com.com writes: > We all lock our house every morning when we go to work, although we know > that any average thief will be able to break it. So many of us pay $3000 > to install the home security system, although we know that any average > thief will cut your power line to disable the security system before they > enter the house. NAT is valuable to many people. As a NAT user, a less > than perfect security is better than NO security at all. Don't you lock > your front door every morning? Imagine that you have the choice between a $10 lock that works perfectly and is highly secure, or a $1000 lock that requires that a thief sneeze at it for it to open itself. Which would you choose? IPsec is a simple yet very secure protocol. You are proposing making it complicated and costly in an effort to remove all the protection it would provide. I am not sure that there is a point to that. An IPsec with the ability to modify the packets in flight is like a contraceptive that lets you get pregnant. "All the disadvantages of condoms, with all the disadvantages of pregnancy and and AIDS combined!" Why would anyone want such a thing? Perry From owner-ipsec Thu Feb 5 12:10:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA11817 for ipsec-outgoing; Thu, 5 Feb 1998 12:08:43 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.3.32.19980205010331.0091b6f0@Netcom.Com> References: <199802050739.CAA05166@jekyll.piermont.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 5 Feb 1998 12:21:02 -0500 To: Alex Alten From: Stephen Kent Subject: Re: Interactions between IPSEC and NAT Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Alex, >>Maybe you ought to read the spec. It might answer a lot of your >>questions. Believe it or not, we did know what we were doing. > >I have to really question if you knew what you were doing. Go >read Rogaway's cryptographic analysis--have you fixed the issues >he raised? Are you still seriously considering a PK solution for >managing trust? If so, then God help anybody that has to implement >it and get a real customer to use it. I don't think the current IPsec protocols suffer from any serious cryptographic problems, but a more concrete pointer to the publication in question is always appreciated. The use of PKC with IPsec is for autehntication and key distribution. "Trust" is an overused term and it's not clear that it applies here. This is especially true since IPsec allows for various key management options and it certainly does not require anything like a global key management hierarchy (if that's what you might have been alluding to). >>Your viewpoint is a wee bit unrealistic -- there is, in practice, no >>way to make even a tiny fraction of the routers trusted. It is also >>unneeded -- we know how to provide security in a network where nothing >>except the endpoints need to be trusted. > >Unfortunately you have come up with a solution I find cumbersome, >slow, difficult to administer, with an awkward trust model, no >auditing, and no key recovery. The level of admninistrative difficulty for IPsec will probably be comparable to that of a stateless, pacvket filtering firewall, which is just what one should expect for the prescribed level of access control granularity. As I noted above, I don't think we have a "trust model" here, so I cannot respond to that criticism. Auditing is a requirement for IPsec implementations. Key recovery is not an explicit feature, but can be provided through a variety of arrangements (if the market wants it). Steve From owner-ipsec Thu Feb 5 12:10:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA11818 for ipsec-outgoing; Thu, 5 Feb 1998 12:08:45 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.3.32.19980204232324.0092e5d0@Netcom.Com> References: <199802050609.BAA03281@jekyll.piermont.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 5 Feb 1998 12:13:51 -0500 To: Alex Alten From: Stephen Kent Subject: Re: Interactions between IPSEC and NAT Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Alex, >>> This is what bothers me about the direction IPSEC has taken. The >>> addition of security should not break things like trusted NATs. >> >>The function of IPsec is to keep a packet from being touched or read >>in transit. > >IP packets are designed with routing in mind. There are fields which >need to be adjusted between hops. This means IP security can only be >designed with a single hop in mind. This also means that IP security >must be part of a complete security system, of which IP security is >just one component, the component which protects inter-router hops. >A secure, trusted NAT can certainly be part of that system. Not really true. Use of tunnel mode allows for modification of an outer IP header without violating the security of the encapsulated packet. AH is explicitly design to exempt the mutable fields in an IP header, while providing integrity and authenticity for the remainder of the datagram. IP S/D addresses were not intended to be modified en route (except in the case of source routing, a case that AH knows to accommodate), and it is the assumption of immutability for these addresses that NAT violates and causes problems for IPsec. >>> If not, then encrypt the IP header, since all the trusted routers >>> can decrypt it, decide how to route it, and then re-encrypt before >>> transmitting it. >> >>We don't do that, actually. You can't bring all the routers on the >>internet into your security perimeter -- that simply won't work. Thus, >>we don't try. IPsec works via encapsulation -- the outer IP address is >>in the clear, as it must be for routing to work. > >This is realistic, I stated this as my alternative. However the outer IP >address must be at least be verified somehow, either via a MAC over it or >duplicate routing information inside the protected encapsulation area. Trusting (intermediate) routers in terms or confidentiality, integrity, etc, is a violation of the principle of least privilege, making a hop-by-hop approach generally less desirable. >>For stuff like NAT to work you would need to include all NAT boxes and >>routers in your security perimeter, and I fundamentally cannot think >>of a design for this stuff that will work and will involve arbitrary >>numbers of intermediate nodes on the global internet -- I belive that >>it just can't be done in practice. Maybe I'm just not bright enough, >>but I think that instead its an issue of having enough arrows in my >>back to know better. >> > >I absolutely agree. In fact, regardless of NAT, all the routers must >be part of the security system (or security perimeter). For an >arbitrary number of insecure routers, then I think only a transport >or application level security will work. In general, routers have a secruity role only with regard to denial of service, and, to a lesser extent, traffic flow confidentiality. >>> The really difficult issues of how to establish and control the >>> network of trusted nodes, and how to implement and enforce >>> network-wide policy can then be tackled. >> >>When you come up with a functioning protocol, let us know. I don't >>believe one is possible, but I'm more than willing to listen. >> > >Admittedly it is a tough problem to solve, given the datagram nature of >IP and its high performance requirements for routing. It's much easier >to do it at the TCP level. Security protocols at the transport and higher layers are simpler, but they require end system deployment, which introduces a different set of problems, e.g., management of desktop security. Firewalls are an attractive technology in part because they centralize security administration. IPsec is attractive because it can be deployed on either desktops or in security gateways, and interoperates between both types of implementations, so that one can choose the granularity for deployment. Steve From owner-ipsec Thu Feb 5 12:50:09 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA12123 for ipsec-outgoing; Thu, 5 Feb 1998 12:47:46 -0500 (EST) Date: Thu, 5 Feb 1998 12:47:46 -0500 (EST) From: owner-ipsec@ex.tis.com Message-Id: <199802051648.IAA29194@puli.cisco.com> To: "Perry E. Metzger" cc: Cheng_Chen@3com.com, Dan Nessett ipsec@tis.com, nat@livingston.com, paul_douglas@3com.com, raj_bhatia@3com.com, ken_araujo@3com.com Subject: Re: (NAT) Re: Interactions between IPSEC and NAT In-reply-to: Your message of "Thu, 05 Feb 98 11:32:46 EST." <199802051632.LAA05572@jekyll.piermont.com> Date: Thu, 05 Feb 98 08:48:27 PST From: Yakov Rekhter Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk Perry, > Cheng_Chen@3com.com writes: > > We all lock our house every morning when we go to work, although we know > > that any average thief will be able to break it. So many of us pay $3000 > > to install the home security system, although we know that any average > > thief will cut your power line to disable the security system before they > > enter the house. NAT is valuable to many people. As a NAT user, a less > > than perfect security is better than NO security at all. Don't you lock > > your front door every morning? > > Imagine that you have the choice between a $10 lock that works > perfectly and is highly secure, or a $1000 lock that requires that a > thief sneeze at it for it to open itself. Which would you choose? > > IPsec is a simple yet very secure protocol. You are proposing making > it complicated and costly in an effort to remove all the protection it > would provide. I am not sure that there is a point to that. > > An IPsec with the ability to modify the packets in flight is like a > contraceptive that lets you get pregnant. "All the disadvantages of > condoms, with all the disadvantages of pregnancy and and AIDS > combined!" Why would anyone want such a thing? Let me just say that some of the assumptions that IPsec was designed with don't match reality. On the orthogonal, yet somewhat related topic, it may be wise to remember that "reality has a way of adjusting those who think they can adjust it". Yakov. From owner-ipsec Thu Feb 5 12:58:06 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA12203 for ipsec-outgoing; Thu, 5 Feb 1998 12:57:47 -0500 (EST) Message-ID: From: Greg Carter To: "'ipsec@tis.com'" Subject: RE: SKEYID lengths and IVs Date: Thu, 5 Feb 1998 12:57:43 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, For a keyed hash function such as MD5 the SKEYID is the length of the output, ie 128bits which is an acceptable key length for keyed hashes and so SKEYID can be used as a key input to generate SKEYID_d etc... However for prf functions such as 3DES the key needs to be 192 bits but the output of 3DES prf is only 64bits so SKEYID needs to be expanded to be used as a key to the next prf (SKEYID_d...). For IV of phase two treat the blob generated from the hash of the DH public values as the "last CBC block" and then apply the method described in the appendix. Bye. ---- Greg "Geek Spice" Carter, Entrust Technologies greg.carter@entrust.com >---------- >From: owner-ipsec@ex.tis.com[SMTP:owner-ipsec@ex.tis.com] >Sent: Thursday, February 05, 1998 10:18 AM >To: ipsec@tis.com >Subject: SKEYID lengths and IVs > >Hi. I had some questions on Appendix B of the Resolution draft: > >1. SKEYID length: Appendix B of the resolution draft explains a method to >increase the length of the SKEYIDs if the output of the PRF is not long >enough. How is the length of the SKEYIDs determined in the first place? >Is it 'atleast' 90 bits as per the Oakley draft? Also, if SKEYID_d is >going to be derived this way, what is the reason for expanding SKEYID? Is >this method for use with SKEYID_d only or would it be used for SKEYID_e >also? If it is to be used with SKEYID_e, then why use the key expansion >method described later on instead of just expanding SKEYID_e, and then >using the required number of octets from it as the encryption key? > >2. IV generation for phase 2 messages: Appendix B also describes how to >generate IVs for encrypting phase 2 exchanges. It states that the IV for >the first phase 2 message is derived from a hash of the concatenation of >the last phase 1CBC output block and the phase 2 message id. Since the >Aggressive exchange does not encrypt any messages, there would be no phase >1CBC output blocks. How would the phase 2 IV be derived in this case? >Should the hash of the concatenation of the two sides' public >Diffie-Hellman values be used instead? > >Thanks, > >Sumit A. Vakil >3Com, Corp. > > > > > From owner-ipsec Thu Feb 5 12:58:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA12219 for ipsec-outgoing; Thu, 5 Feb 1998 12:58:52 -0500 (EST) Message-Id: <199802051809.NAA09637@relay.hq.tis.com> To: ben@Ascend.COM (Ben Rogers) cc: bound@zk3.dec.com, Alex Alten , perry@piermont.com, Dan Nessett , ipsec@tis.com, nat@livingston.com Subject: Re: (NAT) Re: Interactions between IPSEC and NAT In-reply-to: Your message of "Thu, 05 Feb 1998 10:49:44 EST." <199802051549.KAA05251@carp.morningstar.com> Date: Thu, 05 Feb 1998 10:08:56 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk >I know that one of the important points mentioned in the Washington was >that if NAT were going to fly as a WG it would need to work around the >security interactions by modifications to the way we do NAT instead of >modifications to the way we do security. There's a good idea! From owner-ipsec Thu Feb 5 14:38:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA12865 for ipsec-outgoing; Thu, 5 Feb 1998 14:35:48 -0500 (EST) From: "Alexei V. Vopilov" To: , , , "Michael C. Richardson" Subject: Re: (NAT) Re: Interactions between IPSEC and NAT Date: Thu, 5 Feb 1998 22:25:57 +0300 Message-ID: <01bd326b$e215a240$db253ac3@ppalx> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id OAA12862 Sender: owner-ipsec@ex.tis.com Precedence: bulk -----Original Message----- From: Michael C. Richardson To: bound@zk3.dec.com ; ipsec@tis.com ; nat@livingston.com Date: 5 ÆÅ×ÒÁÌÑ 1998 Ç. 20:35 Subject: Re: (NAT) Re: Interactions between IPSEC and NAT [ . . .] : The only problem is getting the "external" address allocated, and letting :the centralized NAT box know about this so that it can route and/or tunnel :packets that match the appropriate "external" address (may include port :and SPI in its decision in the case of many-to-one NAT) to the internal :box. Once you have centralized NAT BOX _and_ the wish to have NAT on end node IPsec the problem can be solved: - End Node NAT requests from BOX a public address allocation - End Node does NAT, then IPsec, then IPinIP tunnel to BOX. - BOX either strip tunnel or does one more NAT and IPsec for the outer header. - BOX send data out If BOX runs IPsec, the end node can get address allocation secured with ISAKMP SA (requires ISAKMP modification) or with an app level SA (a job for NAT guys). Since an end node will have NAT on it, the last can be smart enough to release allocated addresses from BOX after using. : : The solution, I must agree, is not to break IPsec, but to build smarter :NAT systems. The Internet was built around stateless routers (some say this :is part of its success), while NAT boxes and firewalls are stateful, so they :are violating the design architecture. Until one deploys IPsec on the end :nodes, NAT and IPsec will have to live on the same box and will have to share :state. How do you consider an IPsec box then, stateless or stateful? [ . . .] --Alexei From owner-ipsec Thu Feb 5 14:49:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA12926 for ipsec-outgoing; Thu, 5 Feb 1998 14:48:48 -0500 (EST) From: "Alexei V. Vopilov" To: "Ben Rogers" , Cc: "Alex Alten" , , "Dan Nessett" , , Subject: Re: (NAT) Re: Interactions between IPSEC and NAT Date: Thu, 5 Feb 1998 22:51:12 +0300 Message-ID: <01bd326f$69090780$db253ac3@ppalx> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id OAA12923 Sender: owner-ipsec@ex.tis.com Precedence: bulk -----Original Message----- From: Ben Rogers To: bound@zk3.dec.com Cc: Alex Alten ; perry@piermont.com ; Dan Nessett ; ipsec@tis.com ; nat@livingston.com Date: 5 ÆÅ×ÒÁÌÑ 1998 Ç. 20:51 Subject: Re: (NAT) Re: Interactions between IPSEC and NAT [ . . .] :Which makes it sound as if they're planning to be handling such issues. :I know that one of the important points mentioned in the Washington was :that if NAT were going to fly as a WG it would need to work around the :security interactions by modifications to the way we do NAT instead of :modifications to the way we do security. : :ben If this is a 'hint', it makes NAT people to just give up with IPsec since they have nothing to do after an IPsec transform is done. If IPsec wg ignores the NAT one, that actually would affect the customer base for both technologies. --Alexei From owner-ipsec Thu Feb 5 15:00:01 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA12995 for ipsec-outgoing; Thu, 5 Feb 1998 14:59:47 -0500 (EST) From: owner-ipsec@ex.tis.com Message-Id: <199802051915.LAA29141@server.livingston.com> Subject: Re: (NAT) Re: Interactions between IPSEC and NAT To: bound@zk3.dec.com Date: Thu, 5 Feb 1998 11:19:24 -0800 (PST) Cc: Andrade@netcom.com, perry@piermont.com, Dan_Nessett@tdc.3com.com, ipsec@tis.com, nat@livingston.com In-Reply-To: <199802050500.AA03698@wasted.zk3.dec.com> from "bound@zk3.dec.com" at Feb 5, 98 00:00:47 am Content-Type: text Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk Jim, > > > I think IPSEC has it right, and Perry gave us the bottom line many > messages ago. > You may be right. There are tradeoffs and limitations to everything including IPSec. Other members of the list including Yakov and Alex ALten pointed this out eloquently. So, I wont go into this. > I am talking to my friend Ray at X and I encrypt my packet which is the > checksum and all stuff. IPSEC gives me the hope that NO ONE else can > see the data including my ISP or routers or NAT boxes I don't even know, > between me and Ray. I like the idea of not being violated on the > Internet. > If you consider NAT as a violation of your rights, you probably ought not use NAT. I can understand. But, you may have no choice if you are communcating with vendors that do use NATs in their setup. NAT has its place in providing solutions to a set of problems. The level of security required is not universal to all. > I have already figured out to avoid NAT in most cases with IPv6 and now > working on an NNAT for IPv4 if I can find someone who wants to do the > writing? At first I thought DHCPv4 could not do NNAT but now I think it > can though it does not have the Reconfigure msg of DHCPv6 I think we can > do it with Multicast packets. The other option is to use DHCPv6 for > IPv4 nodes too, which is possible. > Well, Jim, your proposal is not without its limitations and does not solve the many problems that NAT does. It is not a replacement for NATs and here are some reasons why. a) NATs do address and port translation. Your draft, which is based on DNS and DHCP v6 does not. b) Load Share NATs do session binding and load sharing on a real-time basis. Real-time address updates of DNS, in the past, at best are proved to be slow to adapt and have not been successful. And, your draft does not solve the load share problem that NATs do. c) NATs do flow-based address asignment and translations. Your draft tries to divert flow based address assignment (limited only to sessions originating from V4 to V4+V6 nodes) through DHCP v6 and DNS to V4+V6 nodes. The end nodes must be sensitive to who they are talking to (V4 only or V4+v6 nodes), adapt multiple addresses (for incoming or outgoing sessions) and choose a routing scheme based on who they are talking to etc.. > For those that want IPSEC, but need a temporary address like NAT does, > the goal is to just avoid using NAT and I think this is very doable. > Surely, there are alternatives to meeting the IPSec requirements even with NATs in between. > I am not saying that NAT cannot still be used cause it will at least > until IPv6 is pervasive, but I think we (engineers) are trying to solve > this problem in the wrong way. We should be working on solutions to > avoid NAT when it is not an optimal way to do "business" on the Internet. > The meaning of the terms you use are subject to interpretation. What is "right", what is "optimal" and what it takes to do "business" - all vary considerably from observer to observer. > Do we discuss such notions here or do we need to have an Avoidance of > NAT BOF and eventual Working Group at the L.A. IETF? > This a NAT mailing list and you are airing your thoughts on the list; which I appreciate. We are in the process of trying to form a NAT work group, trying to get the language for charter just right so it is agreeable to IESG, IAB, Area advisors and WG chairs. The process has been slower than I would like; but we are progressing... Why are you advocating boycott of the upcoming NAT BOF and/or NAT WG at LA? Why do you feel the need to avoid the NAT forum. I do not appreciate your doing this. Is that because you believe NATs are the "wrong" way to solve business problems. We went over this in the Munich BOF; And, the majority of people in Munich as well as Washington BOF felt it a good idea to have NAT work group. > Changing IPSEC for NAT is a bad engineering idea IMO. > I refer you to the charter and objectives stated for the BOFs in Munich and Washington, DC. There was no such mention. We dont intend adding this terminology to the eventual Work group charter either. > /jim > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe nat' in the body of the message. > Regards, suresh From owner-ipsec Thu Feb 5 15:22:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13289 for ipsec-outgoing; Thu, 5 Feb 1998 15:21:51 -0500 (EST) Message-Id: <199802052031.PAA18451@postal.research.att.com> To: ipsec@tis.com, nat@livingston.com Subject: Re: (NAT) Re: Interactions between IPSEC and NAT Date: Thu, 05 Feb 1998 15:31:24 -0500 From: Steve Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk If this is a 'hint', it makes NAT people to just give up with IPsec since they have nothing to do after an IPsec transform is done. If IPsec wg ignores the NAT one, that actually would affect the customer base for both technologies. IPsec works the way it does for very sound security reasons. The changes that have been suggested simply won't happen. The challenge is to figure out how to build an IPsec-friendly NAT *environment*. One approach is, as noted, to bundle NAT and IPsec boxes together. At least one vendor that I know of is already doing this. It's a perfectly reasonable approach, since both functions often take place at the boundary. A second approach is to use some form of encapsulation to accomplish NAT-like functionality. That, too, works well, since IPsec supports an encapsulation mode. A third approach -- and it's one I don't like -- is to make the NAT box trusted. In that case, IPsec sessions, inbound and outbound, terminate at the NAT box. Heaven help us all if the NAT box is penetrated, of course -- but much of the early IPsec deployment will be on trusted encryption gateways anyway; the effective loss of trust will be rather small. To do this requires playing games with the security gateway discovery mechanism; since that isn't defined yet, there's room to work. (I'm not even convinced the problem is well-understood yet, I should add.) Broadly speaking -- and with many implied "secure XXX" qualifiers -- the process is similar to the use of MX records for mail delivery. A box that speaks IPsec will ask some sort of server (which may or may not be the DNS) for its peer's security gateway; it will receive back an authenticated reply. If the reply says "talk to the NAT box" and the IPsec speaker believes it, the setup will be transparent. The trick, of course, is to make the reply believable. That probably implies issuing fake certificates from the NAT box, so the IPsec box will have to be told to accept it as a CA. But that's about the same game NAT boxes will have to play with DNSsec. (I should note that the reason I don't like this is that being a security weenie, I prefer end-to-end security. I suspect, though, that it's the most general solution, since I think that it will fool most IPsec boxes that do peer gateway discovery.) The fourth solution is to assume that there isn't a problem. For the next couple of years, I strongly suspect that most IPsec deployment will either be gateway-to-gateway and host-to-gateway, both in support of different flavors of VPN. In either case, we will often see the same -- possibly non-routable -- address space used on the inside of the VPN. And "inside" includes the virtual interface used by the host talking to the gateway. IPsec between arbitrary pairs of hosts is still several years off, I think. (I don't claim that this solves everyone's problems. And I can just hear Bob Moskowitz readying his response about how his former employer really needs more complex topologies with IPsec and NAT.) From owner-ipsec Thu Feb 5 15:39:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13373 for ipsec-outgoing; Thu, 5 Feb 1998 15:37:52 -0500 (EST) Message-Id: <199802052049.UAA09443@orchard.arlington.ma.us> To: Yakov Rekhter cc: "Perry E. Metzger" , Cheng_Chen@3com.com, Dan Nessett , ipsec@tis.com, nat@livingston.com, paul_douglas@3com.com, raj_bhatia@3com.com, ken_araujo@3com.com In-reply-to: Your message of "Thu, 5 Feb 1998 12:47:46 -0500 (EST) ." <199802051648.IAA29194@puli.cisco.com> Date: Thu, 05 Feb 1998 15:48:27 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk Yakov, You seem to be characterizing this as a "ipsec vs. NAT" debate. It's really a "security vs. NAT" debate. Over the past 10 years, I've worked on a number of different systems with integrated crytographic security which, among other things, often cryptographically protect IP addresses from modification... either at the network layer, like ipsec, or above it in the application layer. Every single one of these systems is broken by NAT. Every single one. This says quite a bit about the violence which NAT does to the goal of securing the Internet. - Bill From owner-ipsec Thu Feb 5 16:45:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA13839 for ipsec-outgoing; Thu, 5 Feb 1998 16:40:52 -0500 (EST) From: owner-ipsec@ex.tis.com Message-Id: <199802052140.QAA13839@portal.ex.tis.com> To: Pyda Srisuresh Cc: bound@zk3.dec.com, Andrade@netcom.com, perry@piermont.com, Dan_Nessett@tdc.3com.com, ipsec@tis.com, nat@livingston.com Subject: Re: (NAT) Re: Interactions between IPSEC and NAT In-Reply-To: Your message of "Thu, 05 Feb 1998 11:19:24 PST." <199802051915.LAA29141@server.livingston.com> Date: Thu, 05 Feb 1998 16:35:48 -0500 X-Mts: smtp Sender: owner-ipsec@ex.tis.com Precedence: bulk Suresh, > I think IPSEC has it right, and Perry gave us the bottom line many > messages ago. >You may be right. There are tradeoffs and limitations to everything >including IPSec. Other members of the list including Yakov and Alex >ALten pointed this out eloquently. So, I wont go into this. As someone just said its not an IPSEC vs NAT its Security vs NAT and I would even say Private Addresses vs using real Internet Addresses which is causing NAT. >> I am talking to my friend Ray at X and I encrypt my packet which is the >> checksum and all stuff. IPSEC gives me the hope that NO ONE else can >> see the data including my ISP or routers or NAT boxes I don't even know, >> between me and Ray. I like the idea of not being violated on the >> Internet. >If you consider NAT as a violation of your rights, you probably ought not >use NAT. I can understand. But, you may have no choice if you are >communcating with vendors that do use NATs in their setup. NAT has its >place in providing solutions to a set of problems. The level of security >required is not universal to all. If I do not have the choice to use end to end security on the Internet then a very serious choice for nodes is missing. Once we deploy IPv6 and IPSEC and other forms that do not need private addresses then I agree with Yakov folks will have to change their mind, only my view of where the world will go is far different from Yakov's I think. >> I have already figured out to avoid NAT in most cases with IPv6 and now >> working on an NNAT for IPv4 if I can find someone who wants to do the >> writing? At first I thought DHCPv4 could not do NNAT but now I think it >> can though it does not have the Reconfigure msg of DHCPv6 I think we can >> do it with Multicast packets. The other option is to use DHCPv6 for >> IPv4 nodes too, which is possible. >> >Well, Jim, your proposal is not without its limitations and does not solve >the many problems that NAT does. It is not a replacement for NATs and >here are some reasons why. Of course my draft has limitations I am not clear I agree with you on what the defintion of a limitation is vs an advantage though. > a) NATs do address and port translation. Your draft, which is based on > DNS and DHCP v6 does not. I consider this an advantage. > b) Load Share NATs do session binding and load sharing on a real-time > basis. Real-time address updates of DNS, in the past, at best are > proved to be slow to adapt and have not been successful. And, your > draft does not solve the load share problem that NATs do. Load Share is a side benefit of NAT we can have load shire without NAT. My draft does not prevent load share. > c) NATs do flow-based address asignment and translations. Your draft > tries to divert flow based address assignment (limited only to sessions > originating from V4 to V4+V6 nodes) through DHCP v6 and DNS to > V4+V6 nodes. The end nodes must be sensitive to who they are talking > to (V4 only or V4+v6 nodes), adapt multiple addresses (for > incoming or outgoing sessions) and choose a routing scheme based > on who they are talking to etc.. Yes my draft is to help users not have to have private addresses and can move to the Next Generation Internet Protocol which is IPv6 more expediently and does not require any translation. The only cost is a one time set up. As far as providing flow based or IP Switched benefits that is not a function of NAT and can be provided once the node has a real IPv4 address. But this is a philosophical discussion and not technical so I will stop. Please don't try to tell me that packets can move faster for IPv4 with NAT than if NAT was not needed and the node has a real IPv4 Internet address where NAT is not needed. I don't believe that at all. >> For those that want IPSEC, but need a temporary address like NAT does, >> the goal is to just avoid using NAT and I think this is very doable. >Surely, there are alternatives to meeting the IPSec requirements even with >NATs in between. Well I just read the mobile draft for firewalls. I think its good work but it has much cost and requires some serious security dynamics to provide end-to-end security. In addition it only works public to private now not private to private across the Internet. I will read George's by-pass draft this weekend. I don't think its possible given the "trust" model assumed. We can change the trust model but that gets into philosophy too not engineering. Changing the philosophy of our trust model will take awhile IMO, but thats not in this WG charter and we should probably take that discussion elswhere. >> I am not saying that NAT cannot still be used cause it will at least >> until IPv6 is pervasive, but I think we (engineers) are trying to solve >> this problem in the wrong way. We should be working on solutions to >> avoid NAT when it is not an optimal way to do "business" on the Internet. >The meaning of the terms you use are subject to interpretation. What >is "right", what is "optimal" and what it takes to do "business" - all vary >considerably from observer to observer. Well let me interpret it clearer for you. Laissez-faire. NAT is fine but building alternatives to NAT is fine too. I hope that is clearer. >> Do we discuss such notions here or do we need to have an Avoidance of >> NAT BOF and eventual Working Group at the L.A. IETF? >This a NAT mailing list and you are airing your thoughts on the list; >which I appreciate. We are in the process of trying to form a NAT work >group, trying to get the language for charter just right so it is >agreeable to IESG, IAB, Area advisors and WG chairs. The process has >been slower than I would like; but we are progressing... >Why are you advocating boycott of the upcoming NAT BOF and/or NAT WG at >LA? Why do you feel the need to avoid the NAT forum. I do not appreciate >your doing this. Is that because you believe NATs are the "wrong" way to >solve business problems. We went over this in the Munich BOF; And, the >majority of people in Munich as well as Washington BOF felt it a good >idea to have NAT work group. Your misunderstanding my words. I do think we need a NAT WG and charter. But based on a lot of mail here I also think we in the IETF need to work on alternatives to NAT or translation. The question is should that be part of this WG? I don't know? I go to NAT now (when I don't have other conflicts) and if there is a group doing an alternative to NAT I will go there too. I am not against this work and believe it to be important because it exists in the market. But I believe it better to not use private addresses for many reasons and that is the only reason for NAT in the market I can justify. >> Changing IPSEC for NAT is a bad engineering idea IMO. >I refer you to the charter and objectives stated for the BOFs in >Munich and Washington, DC. There was no such mention. We dont intend >adding this terminology to the eventual Work group charter either. This was just a comment to the list thats all as some suggested if IPSEC don't work with NAT then IPSEC maybe should be changed. So I was responding to that mail. Sincerely, /jim From owner-ipsec Thu Feb 5 17:12:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA14063 for ipsec-outgoing; Thu, 5 Feb 1998 17:11:56 -0500 (EST) Message-ID: <34DA3BEE.500F@cs.umass.edu> Date: Thu, 05 Feb 1998 17:23:42 -0500 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha) MIME-Version: 1.0 To: IP Security List CC: nat@livingston.com Subject: Re: (NAT) Re: Interactions between IPSEC and NAT References: <199802051915.LAA29141@server.livingston.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk [Mailing list software wiped out the email address of "suresh", so I couldn't reply privately to this....] Jim wrote: >>> Do we discuss such notions here or do we need to have an Avoidance >>> of NAT BOF and eventual Working Group at the L.A. IETF? suresh writes: > Why are you advocating boycott of the upcoming NAT BOF and/or NAT WG > at LA? Why do you feel the need to avoid the NAT forum. I do not > appreciate your doing this. I think there's some grammatical confusion here. As I read the message, the previous correspondent was suggesting a BOF on the topic of "Avoidance of NAT". He was NOT suggesting that anyone should "avoid" the NAT BOF, as far as I could tell. At any rate it appears from someone else's description that the NAT BOF will cover "NAT avoidance" issues anyway. -Lewis From owner-ipsec Thu Feb 5 18:21:26 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA14485 for ipsec-outgoing; Thu, 5 Feb 1998 18:19:57 -0500 (EST) Date: Thu, 5 Feb 1998 23:30:40 +0000 (GMT) From: George Tsirtsis To: Steve Bellovin Cc: ipsec@tis.com, nat@livingston.com Subject: Re: (NAT) Re: Interactions between IPSEC and NAT In-Reply-To: <199802052031.PAA18451@postal.research.att.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Thu, 5 Feb 1998, Steve Bellovin wrote: > > A second approach is to use some form of encapsulation to accomplish > NAT-like functionality. That, too, works well, since IPsec supports > an encapsulation mode. Steve, I do not understand how the tunnel-mode of IPSEC will help you here. If you have a NAT at the edge of the network, in order to use the tunnel mode (from the host to the NAT), you will have to get a global address before you set the tunnel up in order to do the encryption calculations. Is that correct? How this address will be allocated? I ask that because it crossed my mind when I was writting the'NAT bypass' draft using L2TP. If you have any ideas how to do that I would be very interested to hear. Regards George ----------------------------- Internet Transport Research | BTLABS | -------------------------------------------------------------------------- Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of British Telecommunications plc. -------------------------------------------------------------------------- From owner-ipsec Fri Feb 6 07:39:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA19346 for ipsec-outgoing; Fri, 6 Feb 1998 07:36:00 -0500 (EST) Message-ID: <19980205190344.16485@hazel> Date: Thu, 5 Feb 1998 19:03:44 -0500 From: Raul Miller To: Steve Bellovin Cc: ipsec@tis.com, nat@livingston.com Subject: Re: (NAT) Re: Interactions between IPSEC and NAT References: <199802052031.PAA18451@postal.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199802052031.PAA18451@postal.research.att.com>; from Steve Bellovin on Thu, Feb 05, 1998 at 03:31:24PM -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve Bellovin wrote: > A third approach -- and it's one I don't like -- is to make the NAT > box trusted. In that case, IPsec sessions, inbound and outbound, > terminate at the NAT box. Heaven help us all if the NAT box is > penetrated, of course -- but much of the early IPsec deployment will > be on trusted encryption gateways anyway; the effective loss of > trust will be rather small. To do this requires playing games with > the security gateway discovery mechanism; since that isn't defined > yet, there's room to work. (I'm not even convinced the problem is > well-understood yet, I should add.) Has anyone done any work on tunnelling ip inside a NAT controlled session? -- Raul From owner-ipsec Fri Feb 6 10:47:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA20841 for ipsec-outgoing; Fri, 6 Feb 1998 10:40:09 -0500 (EST) Date: Fri, 6 Feb 1998 10:52:52 -0500 (EST) Message-Id: <199802061552.KAA11395@carp.morningstar.com> From: Ben Rogers To: ipsec@tis.com Subject: Key lengths for HMAC prf's Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk When I'm using the HMAC version of the Hash function as my pseudo-random number generator, what key length do I use. A quick search of the ISAKMP/Oakley document reveals nothing. Am I supposed to infer a length from the following portion of RFC2104? 2. Definition of HMAC The definition of HMAC requires a cryptographic hash function, which we denote by H, and a secret key K. We assume H to be a cryptographic hash function where data is hashed by iterating a basic compression function on blocks of data. We denote by B the byte-length of such blocks (B=64 for all the above mentioned examples of hash functions), and by L the byte-length of hash outputs (L=16 for MD5, L=20 for SHA-1). The authentication key K can be of any length up to B, the block length of the hash function. Applications that use keys longer than B bytes will first hash the key using H and then use the resultant L byte string as the actual key to HMAC. In any case the minimal recommended length for K is L bytes (as the hash output length). See section 3 for more information on keys. [snip] 3. Keys The key for HMAC can be of any length (keys longer than B bytes are first hashed using H). However, less than L bytes is strongly discouraged as it would decrease the security strength of the function. Keys longer than L bytes are acceptable but the extra length would not significantly increase the function strength. (A longer key may be advisable if the randomness of the key is considered weak.) If so, what should I infer? Dan, can you please add this to IO-RES? If I've once again missed the reference, can you put it somewhere near the text 'prf' or 'pseud-random' so we can do a text search for it? thanks, ben From owner-ipsec Fri Feb 6 12:25:42 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA21581 for ipsec-outgoing; Fri, 6 Feb 1998 12:24:11 -0500 (EST) Message-Id: <199802061736.JAA13312@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: ben@Ascend.COM (Ben Rogers) Cc: ipsec@tis.com Subject: Re: Key lengths for HMAC prf's In-Reply-To: Your message of "Fri, 06 Feb 1998 10:52:52 EST." <199802061552.KAA11395@carp.morningstar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 06 Feb 1998 09:36:19 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Ben, > When I'm using the HMAC version of the Hash function as my pseudo-random > number generator, what key length do I use. A quick search of the > ISAKMP/Oakley document reveals nothing. Am I supposed to infer a length > from the following portion of RFC2104? After the computation of SKEYID the length of the key to the keyed MACs is the output of a previous MAC so you already know the length of the key. The key to generate SKEYID depends on the method of authentication you've negotiated and is either: 1) a concatenation of the two nonces (and you know their lengths); 2) a hash of the concatenation of the two nonces (and you know the length of the digest of the negotiated hash function); or, 3) the pre-shared key, whose length you also know. Of course the "Revised Mode of Public Key Encryption" has additional prf'ing that the others don't (to generate ephemeral keys for a symmetric cipher that encrypts selected payloads) but you know the length of the key there too since it's the length of a particular nonce (I or R) depending on the message (I to R or R to I). > 2. Definition of HMAC [snip] > > 3. Keys [snip] > Dan, can you please add this to IO-RES? If I've once again missed the > reference, can you put it somewhere near the text 'prf' or > 'pseud-random' so we can do a text search for it? I'm sensitive to the difficulty people have reading this draft and would like to add whatever clarifying verbage people feel is necessary. Can you tell me exactly what you'd like me to add? The text I just wrote above? Where? In the notation section where prf is first mentioned? At the point that generation of SKEYID et al is discussed? Dan. P.S. The comments and questions I've received on the IO-RES reminds me of a quote from Idi Amin: "People sometimes mistake what I say for the way I think." From owner-ipsec Fri Feb 6 13:23:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA22091 for ipsec-outgoing; Fri, 6 Feb 1998 13:23:09 -0500 (EST) Message-Id: <3.0.5.32.19980206133550.009e96d0@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 06 Feb 1998 13:35:50 -0500 To: IETF-PKIX@lists.tandem.com, ipsec@tis.com From: Robert Moskowitz Subject: Joint X.509 / IPsec discussion Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk This has been long overdue, and a long time coming, but I am arranging a meeting for CA software companies and IPsec technologists to discuss the issues surrounding use of X.509 certificates by IPsec and the interaction of IPsec products with CA software products. We are planning this meeting for Feb 19th at BBN/GTE's facility in the Boston area. Plan on a full day meeting. I suspect that around 12 CA software companies, averaging 2 people would attend with around 6 - 10 IPsec specialists (space planing for Pat Cain). The goal of this meeting would be to establish the X.509/CA guidelines so that CA software vendors can attend the IPsec workshop the week of March 2nd in Raleigh NC to address product interoperabilty. This meeting will also have as its goal to investigate the realm of CA software certification, ie is the software delivering the security services as specified. An agenda will follow. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Fri Feb 6 13:31:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA22124 for ipsec-outgoing; Fri, 6 Feb 1998 13:30:09 -0500 (EST) Date: Fri, 6 Feb 1998 13:42:30 -0500 Message-Id: <199802061842.NAA24722@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: Reminder concerning the IPSEC implementation list: Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk As a reminder, I am maintaining a list of companies who are implementing (or planning to implement) IPSEC at: http://web.mit.edu/tytso/www/ipsec/companies.html This list is an adjunct to the IPSEC Implementation Survey, which is periodically done by Rodney Thayer at Sable Technology, and which can be found. Rodney's list, along with some other useful IPSEC resources, can be found on the IPSEC page which I maintain at: http://web.mit.edu/tytso/www/ipsec/ The IPSEC company list which I maintain does not contain as much information about the details of the IPSEC implementations as does the implementation survey, but it does contain marketing contacts and is updated more frequently than the Implementation Survey. If your company isn't listed on my IPSEC company list, or the information on the list needs to be updated, please let me know; send e-mail to tytso@mit.edu. Remember: only *you* can prevent cobwebby web pages. :-) Thanks!! - Ted From owner-ipsec Fri Feb 6 14:03:40 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA22546 for ipsec-outgoing; Fri, 6 Feb 1998 14:03:13 -0500 (EST) X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Pat Calhoun" To: lmccarth@cs.umass.edu cc: ipsec@tis.com, nat@livingston.com Message-ID: <862565A3.0057F404.00@mwgate01.mw.3com.com> Date: Fri, 6 Feb 1998 11:07:15 -0600 Subject: Re: (NAT) Re: Interactions between IPSEC and NAT Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Of couse I need to think about this quite a bit, but it seems that SOCKS has some potential in this area. For those that do not know that SOCKS is I can summarize that it can be used as an alternative to NAT (and much more). The way SOCKS works is that a "shim" is placed in all clients on the private network between the application and the network layer. The shim "intercepts" bind and connect requests and forwards these requests as SOCKS messages to a pre-configured Proxy gateway. So all traffic on the public network looks like it is from the SOCKS gateway, much like a NAT server. In the case of a BIND request, which is used for incoming connections from the public network, a respose is sent to the SOCKS client which includes the port allocated by the SOCKS gateway as well as the gateway's bind IP address. A similar mechanism is done for CONNECT requests for clients connecting from the private to the public network. I wonder if a change on the SOCKS client would allow the client to simply use the source IP address and port contained in the BIND or CONNECT request, which is the SOCKS gateway. I think that this proposal would allow end to end encryption AND authentication since the SOCKS gateway would no longer need to change the packet. Note that this is not the current behavior of a SOCKS server, so it would require some changes. Disadvantages: - Requires some changes on the client station. - Complicates troubleshooting on the private network since all packets come from the same IP address. - May have to change any source address filtering if it exists on the private network. Advantages: - Allows encryption and authentication end to end! Thanks, PatC 3Com From owner-ipsec Fri Feb 6 18:23:46 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA24420 for ipsec-outgoing; Fri, 6 Feb 1998 18:22:10 -0500 (EST) From: Pyda Srisuresh Message-Id: <199802062241.OAA22388@server.livingston.com> Subject: Re: (NAT) Re: Interactions between IPSEC and NAT To: bound@zk3.dec.com Date: Fri, 6 Feb 1998 14:45:29 -0800 (PST) Cc: suresh@livingston.com, Andrade@netcom.com, perry@piermont.com, Dan_Nessett@tdc.3com.com, ipsec@tis.com, nat@livingston.com In-Reply-To: <199802052135.AA29211@wasted.zk3.dec.com> from "bound@zk3.dec.com" at Feb 5, 98 04:35:48 pm Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Jim, Thanks for your response and clarifications. Please note my comments below. cheers, suresh > > Suresh, > .... stuff deleted. > >If you consider NAT as a violation of your rights, you probably ought not > >use NAT. I can understand. But, you may have no choice if you are > >communcating with vendors that do use NATs in their setup. NAT has its > >place in providing solutions to a set of problems. The level of security > >required is not universal to all. > > If I do not have the choice to use end to end security on the Internet > then a very serious choice for nodes is missing. Once we deploy IPv6 > and IPSEC and other forms that do not need private addresses then I > agree with Yakov folks will have to change their mind, only my view of > where the world will go is far different from Yakov's I think. > Fair enough. Time will tell. > >> I have already figured out to avoid NAT in most cases with IPv6 and now > >> working on an NNAT for IPv4 if I can find someone who wants to do the > >> writing? At first I thought DHCPv4 could not do NNAT but now I think it > >> can though it does not have the Reconfigure msg of DHCPv6 I think we can > >> do it with Multicast packets. The other option is to use DHCPv6 for > >> IPv4 nodes too, which is possible. > >> > > >Well, Jim, your proposal is not without its limitations and does not solve > >the many problems that NAT does. It is not a replacement for NATs and > >here are some reasons why. > > Of course my draft has limitations I am not clear I agree with you on > what the defintion of a limitation is vs an advantage though. > > > a) NATs do address and port translation. Your draft, which is based on > > DNS and DHCP v6 does not. > > I consider this an advantage. > > > b) Load Share NATs do session binding and load sharing on a real-time > > basis. Real-time address updates of DNS, in the past, at best are > > proved to be slow to adapt and have not been successful. And, your > > draft does not solve the load share problem that NATs do. > > Load Share is a side benefit of NAT we can have load shire without NAT. > My draft does not prevent load share. > > > c) NATs do flow-based address asignment and translations. Your draft > > tries to divert flow based address assignment (limited only to sessions > > originating from V4 to V4+V6 nodes) through DHCP v6 and DNS to > > V4+V6 nodes. The end nodes must be sensitive to who they are talking > > to (V4 only or V4+v6 nodes), adapt multiple addresses (for > > incoming or outgoing sessions) and choose a routing scheme based > > on who they are talking to etc.. > > Yes my draft is to help users not have to have private addresses and can > move to the Next Generation Internet Protocol which is IPv6 more > expediently and does not require any translation. The only cost is a > one time set up. Yes, my point is simply that the proposal in your draft is a solution to a problem, relating to transition from V4 to V6. It has its limitations as well. The solution path you identified in no way is a panacea to all problems NAT purports to solve and as such is far from being a replacement to NAT solution. I think, you agree with with me on this. If so, no need to belabor on this point any further. > As far as providing flow based or IP Switched benefits > that is not a function of NAT and can be provided once the node has a > real IPv4 address. But this is a philosophical discussion and not > technical so I will stop. > Yes, NAT is a flow based address assignment tool (unlike DHCP, which is simply a resource manager). You may be confusing this with flow based switching by IP routers. These are two different things. > Please don't try to tell me that packets can move faster for IPv4 with > NAT than if NAT was not needed and the node has a real IPv4 Internet > address where NAT is not needed. I don't believe that at all. > The session setup latency is certainly much smaller with NATs, which assign addresses dynamically vs. a set up that involves DHCP and DNS record updates. Also, with NAT, routing is transparant to end nodes. > >> For those that want IPSEC, but need a temporary address like NAT does, > >> the goal is to just avoid using NAT and I think this is very doable. > > >Surely, there are alternatives to meeting the IPSec requirements even with > >NATs in between. > > Well I just read the mobile draft for firewalls. I think its good work > but it has much cost and requires some serious security dynamics to > provide end-to-end security. In addition it only works public to > private now not private to private across the Internet. I will read > George's by-pass draft this weekend. > > I don't think its possible given the "trust" model assumed. We can > change the trust model but that gets into philosophy too not > engineering. Changing the philosophy of our trust model will take > awhile IMO, but thats not in this WG charter and we should probably take > that discussion elswhere. > > >> I am not saying that NAT cannot still be used cause it will at least > >> until IPv6 is pervasive, but I think we (engineers) are trying to solve > >> this problem in the wrong way. We should be working on solutions to > >> avoid NAT when it is not an optimal way to do "business" on the Internet. > > >The meaning of the terms you use are subject to interpretation. What > >is "right", what is "optimal" and what it takes to do "business" - all vary > >considerably from observer to observer. > > Well let me interpret it clearer for you. Laissez-faire. NAT is fine > but building alternatives to NAT is fine too. I hope that is clearer. > Exactly my point. Thanks for the clarification. > >> Do we discuss such notions here or do we need to have an Avoidance of > >> NAT BOF and eventual Working Group at the L.A. IETF? > > >This a NAT mailing list and you are airing your thoughts on the list; > >which I appreciate. We are in the process of trying to form a NAT work > >group, trying to get the language for charter just right so it is > >agreeable to IESG, IAB, Area advisors and WG chairs. The process has > >been slower than I would like; but we are progressing... > > >Why are you advocating boycott of the upcoming NAT BOF and/or NAT WG at > >LA? Why do you feel the need to avoid the NAT forum. I do not appreciate > >your doing this. Is that because you believe NATs are the "wrong" way to > >solve business problems. We went over this in the Munich BOF; And, the > >majority of people in Munich as well as Washington BOF felt it a good > >idea to have NAT work group. > > Your misunderstanding my words. I do think we need a NAT WG and > charter. But based on a lot of mail here I also think we in the IETF > need to work on alternatives to NAT or translation. The question is > should that be part of this WG? I don't know? I go to NAT now (when I > don't have other conflicts) and if there is a group doing an alternative > to NAT I will go there too. I am not against this work and believe it > to be important because it exists in the market. But I believe it > better to not use private addresses for many reasons and that is the > only reason for NAT in the market I can justify. > Thanks again for your clarification. Apparantly, I parsed your sentence differently from what you expected. Anyways, here are my thoughts on the subject. We are planning to form NAT work group only because NATs are a reality and solve a set of problems in the real world; This is despite the fact that NATs do not share the mainstream IETF paradigm of "single routing realm". So, in a sense, the rest of IETF is already persuing solutions in the mainstream. And, NAT WG would be persuing a deviation from the mainstream. There are other work groups like "mobile IP" that share some of this theme. So, if you have a solution that is more in the mainstream, there may be already be some work groups in the mainstream that fit the bill. E.g.: ngtrans work group that deals with V4->V6 transition issues > >> Changing IPSEC for NAT is a bad engineering idea IMO. > > >I refer you to the charter and objectives stated for the BOFs in > >Munich and Washington, DC. There was no such mention. We dont intend > >adding this terminology to the eventual Work group charter either. > > This was just a comment to the list thats all as some suggested if IPSEC > don't work with NAT then IPSEC maybe should be changed. So I was > responding to that mail. > OK, I understand. > Sincerely, > /jim > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe nat' in the body of the message. > From owner-ipsec Fri Feb 6 18:24:24 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA24435 for ipsec-outgoing; Fri, 6 Feb 1998 18:24:10 -0500 (EST) From: bound@zk3.dec.com Message-Id: <199802062306.AA11924@wasted.zk3.dec.com> To: Pyda Srisuresh Cc: bound@zk3.dec.com, Andrade@netcom.com, perry@piermont.com, Dan_Nessett@tdc.3com.com, ipsec@tis.com, nat@livingston.com Subject: Re: (NAT) Re: Interactions between IPSEC and NAT In-Reply-To: Your message of "Fri, 06 Feb 1998 14:45:29 PST." <199802062241.OAA22388@server.livingston.com> Date: Fri, 06 Feb 1998 18:06:01 -0500 X-Mts: smtp Sender: owner-ipsec@ex.tis.com Precedence: bulk Suresh, I don't see belaboring these points further. I will agree that we disagree on the values and capabilities of NAT and thats fine, rather than provide anymore counter arguments, because I believe the point of this mail list and group is to develop the specifics that relate to that which can be standardized in the IETF to support NAT technology. So lets start having that discussion because I am an engineer who is interested and will build a NAT implementation as one solution to leave IPv4 and move on to IPv6 and avoid private addresses as ONE customer "choice" to accomplish this task. As far as other solutions that don't use NAT I take your mail this is not the place to work on that, though you put that politically quite well as other comments you have made now and in the past, which is good as your the chair and need to be nice to us. Thank You. Soooo... I will connect offline with a few folks and suggest we have a BOF potentially of alternative solutions to NAT. My work on NNAT is for v4-v6 transition and that clearly belongs in the NGTRANS WG I agree. But my engineering work on this has made me realize as an implementor I can implement alternatives to NAT and I will see if others in our community are interested in, in another forum. Including for IPv4 regardless of IPv6. So now I am also interested in solutions that can avoid NAT in IPv4 too. Others can send me mail PRIVATELY if you interested in such a BOF for the L.A. meeting. thanks for working to clear this up, /jim From owner-ipsec Sun Feb 8 10:53:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA06030 for ipsec-outgoing; Sun, 8 Feb 1998 10:45:12 -0500 (EST) Message-Id: <3.0.32.19980208105656.00b7bb68@bl-mail1.corpeast.baynetworks.com> X-Sender: ndoraswa_pop@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sun, 08 Feb 1998 10:56:58 -0500 To: ipsec@tis.com, mpls@external.cisco.com, ietf-ppp@merit.edu, int-serv@isi.edu From: Naganand Doraswamy Subject: VPN mailing list Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_886971418==_" Sender: owner-ipsec@ex.tis.com Precedence: bulk --=====================_886971418==_ Content-Type: text/plain; charset="us-ascii" I have created VPN mailing list and attached a proposed charter. I would like to start discussion on what the charter of working group should be and what problems we should be working on. We intend to have another BOF at IETF but this time we need to nail down the charter. --=====================_886971418==_ Content-Type: text/plain; charset="us-ascii" VPN BOF ------- Proposed Chairs --------------- Naganand Doraswamy (naganand@baynetworks.com) Robert Moskowitz (rgm3@icsa.net) Area Directors -------------- Thomas Narten (narten@raleigh.ibm.com) Jeffrey Burgan (burgan@home.net) Area Advisor ------------ TBD Mailing Lists ------------- Discussions: vpn@baynetworks.com subscription: majordomo@baynetworks.com. In the body of the message say: subscribe vpn Description of VPN BOF ---------------------- Virtual Priavate Networking (VPN) is a way of extending a private network seamlessly over a public network. However, this raises various issues such as security, Addressing, Quality of Service to name a few as the traffic belonging to the private network traverses a public network. VPN model can be one of many. An organization can build its VPN. An ISP can build and maintain a VPN of an organization. VPN can exist between organizations (extranets). There is a need to define mechanisms to achieve these capabilies. Some of the issues that needs to be addressed are: 1. Security: Security can be achived by restricting the packet flowing in an out of a VPN. In addition the packets can also be encrypted and authenticated. 2. How to provide Quality of Service/Class of service for packets flowing between the edges. In this case, we may not be worried about providing end to end QoS but only between edges. 3. How to handle Network Address Translation issues. Even though NAT's are a kludge, it has been deployed widely and there is a need to address this issue properly. Should we consider extending the concept of private addressing over the Internet? 4. Ease of configuration. 5. Reliability. 6. Management The goals of the VPN BOF are: 1. Decide if there is a need to form a working group to solve some or all of the problems above. 2. Which of the problems above should be addressed by the working group. 3. What will the working group produce. In our opinion, we need to interact with other working groups such as IPsec working group, NAT working group, int-serv working group, and probably routing working group to solve some or all of the problems above. 4. What other problems need to be solved for succesful deployment of VPN's. --=====================_886971418==_ Content-Type: text/plain; charset="us-ascii" --Naganand ----------------------------------------------------------------- Naganand Doraswamy (978)916-1323 (O) Bay Architecture Lab (978)670-0620 (Fax) 3 Federal St, Mail Stop BL3-03 Billerica, MA 01821 --=====================_886971418==_-- From owner-ipsec Mon Feb 9 02:20:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA10972 for ipsec-outgoing; Mon, 9 Feb 1998 02:18:13 -0500 (EST) Message-Id: <3.0.2.32.19980208233017.00838b30@diablo.cisco.com> X-Sender: stuphill@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Sun, 08 Feb 1998 23:30:17 -0800 To: ipsec@tis.com From: Stuart Phillips Subject: IPSEC Interoperability Workshop - March 2nd-6th Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Cisco will be host an IPSec Interopability workshop March 2nd-7th in Raleigh, North Carolina. The purpose event will be to test hardware and software interopability in a realistic setting. All persons interested in interoperability testing are welcome. I am Stuart Phillips. I am a product manager for IOS Security at Cisco. I am the coordinator for this event, and will be on site all week. My contact information is below in my .sig. Please contact me directly if you have any questions. I would also appreciate a email if you are coming, although it is not required, because I am still working on critical issues like how many T-shirts I need to order. The event will be held at: Embassy Suites 201 Harrison Oaks Blvd. Cary, NC 27513 tel: 919-677-1840 fax: 919-677-1841 Which is at the Raleigh Airport. More Information about the hotel is available at: http://www.embassysuites.com/embassydocs/properties/RDUAP-1.html Cisco has reserved 60 rooms at a discounted rate of 135 USD. This includes breakfast and an evening cocktail hour for all guests. These rooms are for you on a first come, first served basis. Due to very high demand for hotels rooms in RTP, these rooms can only be held until 2/13, after that they will be sold to other quests. It is therefore VERY important that you make your reservation by 2/13, asking for the "Cisco Conference Rate", otherwise a room at this hotel might be unavailable. We have reserved a 3100 Square foot ball room which should be available to us 24 hours a day. Cisco will provide a LAN with a 10BaseT routed network with an outside Internet connection. Analog dial lines will also be provided to test dial clients if needed. Cisco engineers will be on site to help with network configuration issues. Please let me know if you need anything special from the network. I recommend you remember to bring powers strips, 10BaseT patch cables, and small 10BaseT hubs if you need them. These always seem to be in short supply. Any equipment that needs to shipped should be sent directly to the hotel. You should expect to be able to start setting up Monday, 3/2, at 9AM. Please let me know how I can help you all get the most from this workshop. Stuart ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | Stuart Phillips - Product Manager .|||. .|||. | IOS Security - Secondary Authentication ..:|||||||:...:||||||:..| VoiceMail ...: 408.527.7668 or x(7)7668 ------------------------| Fax .........: 408.526.4952 Cisco Systems, Inc. | E-mail ......: stuphill@cisco.com 170 West Tasman SJ-F | Pager E-Mail.: stuphill@airnote.net San Jose CA 95134-1706 | Pager........: 800.365.4578 http://www.cisco.com | Meeting Maker: Stuart Phillips ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "The greatest secrets are oft carried in the weakest cyphers" Sir Francis Bacon - 1609 AD ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-ipsec Mon Feb 9 07:35:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA12903 for ipsec-outgoing; Mon, 9 Feb 1998 07:34:11 -0500 (EST) From: Pyda Srisuresh Message-Id: <199802070036.QAA01712@server.livingston.com> Subject: Re: (NAT) Re: Interactions between IPSEC and NAT To: bound@zk3.dec.com Date: Fri, 6 Feb 1998 16:40:24 -0800 (PST) Cc: suresh@livingston.com, Andrade@netcom.com, perry@piermont.com, Dan_Nessett@tdc.3com.com, ipsec@tis.com, nat@livingston.com In-Reply-To: <199802062306.AA11924@wasted.zk3.dec.com> from "bound@zk3.dec.com" at Feb 6, 98 06:06:01 pm Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Jim, Thanks for your understanding. I am not trying to be political, just putting things in perspective. As for solutions that do not include NAT, I am not averse to them. I will certainly try to offer whatever I can towards providing myriad of solutions to customers. Thanks again. cheers, suresh > > Suresh, > > I don't see belaboring these points further. I will agree that we > disagree on the values and capabilities of NAT and thats fine, rather > than provide anymore counter arguments, because I believe the point of > this mail list and group is to develop the specifics that relate to that > which can be standardized in the IETF to support NAT technology. > > So lets start having that discussion because I am an engineer who is > interested and will build a NAT implementation as one solution to leave > IPv4 and move on to IPv6 and avoid private addresses as ONE customer > "choice" to accomplish this task. > > As far as other solutions that don't use NAT I take your mail this is > not the place to work on that, though you put that politically quite > well as other comments you have made now and in the past, which is good > as your the chair and need to be nice to us. Thank You. > > Soooo... I will connect offline with a few folks and suggest we have a > BOF potentially of alternative solutions to NAT. My work on NNAT is for > v4-v6 transition and that clearly belongs in the NGTRANS WG I agree. But > my engineering work on this has made me realize as an implementor I can > implement alternatives to NAT and I will see if others in our > community are interested in, in another forum. Including for IPv4 > regardless of IPv6. So now I am also interested in solutions that can > avoid NAT in IPv4 too. > > Others can send me mail PRIVATELY if you interested in such a BOF for > the L.A. meeting. > > thanks for working to clear this up, > /jim > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe nat' in the body of the message. > From owner-ipsec Mon Feb 9 11:05:32 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA14601 for ipsec-outgoing; Mon, 9 Feb 1998 10:54:17 -0500 (EST) Message-Id: <199802091538.KAA02816@ghostwheel.ncsl.nist.gov> Date: Mon, 9 Feb 1998 10:38:38 -0500 (EST) To: ipsec@tis.com From: rob.glenn@nist.gov Subject: Re-announcing IPsec WIT, the NIST WWW-based IPsec Interop. Tool X-Mailer: Ishmail 1.3.2-970722-linux MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk This is a re-announcement of the NIST WWW-based IPsec Interoperability tool, IPsec-WIT. IPsec-WIT is an interoperability test system built around the NIST Cerberus IPsec reference implementation and commonly available WWW technology. IPsec-WIT allows its users to remotely control and execute series of interoperability tests with the Cerberus prototype. Test case selection, configuration, execution and results analysis are all controlled remotely by WWW browser. IPsec-WIT is a fairly complex, state-driven, interoperability testing tool (the complexity is in its implementation, not in its interface). It has its own simple testing language, retains state information over a user selectable period of time so users can make changes to their configuration and re-test, provides results analysis via web pages and e-mail, and much more. IPsec-WIT is currently operational with tests for IPv4 IPsec protocols with over 60 test cases and will soon support IPv6 as well as ISAKMP key management protocol testing. For access to IPsec-wit and additional information see: http://ipsec-wit.antd.nist.gov. It is recommended that you read through the tutorial before testing for the first time. We are surprised and a bit disappointed in the little use IPsec-WIT has received since our announcement in December 1997. To date, only a few people have looked at and used this tool and we have received no feedback. All you need to use IPsec-WIT is a WWW browser with support for multi-body pages, tables, and forms (Netscape and Internet Explorer both should work fine). Also, the browser should have access to ipsec-wit.antd.nist.gov without going through the IPsec box being tested, otherwise, an interoperability failure will result in no connectivity between the browser and the httpd server. If you do try to use IPsec-WIT and have comments on how to "make it better", please send them to us (either via the "feedback" utility on the web page or to ipsec-wit-dev@mail.antd.nist.gov). IPsec-WIT development is part of a currently active project and we would appreciate any feedback we can get. Over the next few weeks we hope to be adding an ISAKMP prototype to the IPsec-WIT engine along with an additional set of interoperability tests. Best Regards, Rob G. rob.glenn@nist.gov From owner-ipsec Mon Feb 9 11:11:12 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA14665 for ipsec-outgoing; Mon, 9 Feb 1998 11:03:19 -0500 (EST) Date: Mon, 9 Feb 1998 11:16:05 -0500 From: yjj@mci.net (Yuan John Jiang) Message-Id: <199802091616.LAA13744@cletus.> To: ipsec@tis.com Subject: Question: The resolution of ISAKMP with Oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk The second paragraph of Section 5.2 Phase 1 Authenticated With Public Key Encryption " In order to perform the public key encryption, the initiator must^M already have the responder's public key. In the case where the" How do the two parties obtain each other's public key to begin with? John From owner-ipsec Mon Feb 9 15:35:40 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA16960 for ipsec-outgoing; Mon, 9 Feb 1998 15:32:29 -0500 (EST) Message-Id: <3.0.2.32.19980209124249.00866770@diablo.cisco.com> X-Sender: stuphill@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Mon, 09 Feb 1998 12:42:49 -0800 To: ipsec@tis.com From: Stuart Phillips Subject: IPSec Workshop Hotel Issues Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, If you tried to make a hotel reservation before, and were told no conference is planned or special rate available, please call the hotel again. If the hotel took your name and number they will try to contact you directly. I believe this matter is resolved. Due to some internal communications issues at the Embassy Suites, the registration people where unaware of the conference, and the conference people where out for Washington's birthday. I am sorry for any inconvenience this has caused you. I have already gotten a very positive response regarding this workshop, and am working to get back to all of you on your questions. Thanks, Stuart ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | Stuart Phillips - Product Manager .|||. .|||. | IOS Security - Secondary Authentication ..:|||||||:...:||||||:..| VoiceMail ...: 408.527.7668 or x(7)7668 ------------------------| Fax .........: 408.526.4952 Cisco Systems, Inc. | E-mail ......: stuphill@cisco.com 170 West Tasman SJ-F | Pager E-Mail.: stuphill@airnote.net San Jose CA 95134-1706 | Pager........: 800.365.4578 http://www.cisco.com | Meeting Maker: Stuart Phillips ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "The greatest secrets are oft carried in the weakest cyphers" Sir Francis Bacon - 1609 AD ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-ipsec Mon Feb 9 15:35:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA16976 for ipsec-outgoing; Mon, 9 Feb 1998 15:34:29 -0500 (EST) Message-Id: <3.0.32.19980209124726.0097f8f0@192.43.161.2> X-Sender: jburke@192.43.161.2 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 09 Feb 1998 12:47:27 -0800 To: ipsec@tis.com From: John Burke Subject: SPI in ESP+AH key derivations in Oakley Quick Mode Cc: jburke@cylink.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk What is the right rule for using SPI's and generating the AH key, when Quick Mode negotiates a joined pair of Proposals, ESP and AH? Oakley, in 5.5 Phase 2 - Quick Mode, appears to imply that separate KEYMAT's must be computed for the ESP and the AH SA's, since the computation involves protocol and SPI. Is that right? What seems the relevant text: If PFS is not needed, and KE payloads are not exchanged, the new keying material is defined as KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b). [ ... ] In either case, "protocol" and "SPI" are from the ISAKMP Proposal Payload that contained the negotiated Transform. Thanks, John Burke Cylink, Sunnyvale, CA From owner-ipsec Mon Feb 9 17:08:38 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA17743 for ipsec-outgoing; Mon, 9 Feb 1998 17:05:31 -0500 (EST) Date: Mon, 9 Feb 1998 17:18:09 -0500 (EST) Message-Id: <199802092218.RAA08119@carp.morningstar.com> From: Ben Rogers To: ipsec@tis.com Subject: Unnecessarily bloated IV calculation Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk >From [IO-RES] Appendix B: In phase 1, material for the initialization vector (IV material) for CBC mode encryption algorithms is derived from a hash of a concatenation of the initiator's public Diffie-Hellman value and the responder's public Diffie-Hellman value using the negotiated hash algorithm. This is used for the first message only. Each message should be padded up to the nearest block size using bytes containing 0x00. The message length in the header MUST include the length of the pad since this reflects the size of the cyphertext. Subsequent messages MUST use the last CBC encryption block from the previous message as their initialization vector. Why do we need to do so much work to generate this IV? I realize that we want some sort of uniqueness guarantee, but this is absurd. I know this sort of calculation is cheap for many implementors, but it both takes extra CPU cycles and extra code space to implement while adding no additional security. I would suggest using the cookies to generate this IV. The cookies are with us from the beginning, so we don't have to delay this calculation any longer than necessary. (Has anyone tried to produce a state machine for ISAKMP/Oakley?). If not, perhaps an XOR of the two DH values would be okay. Either way, neither end can compromise the security for both ends. Please don't dismiss this message as creating unnecessary changes "at this late date". I have been hearing that for nearly six months, while the WG is seeming to stagnate under the burden of an unnecessarily bloated protocol. There are many simple changes such as this which would make the protocol much more implementor-friendly, while not negatively affecting the security at all. ben From owner-ipsec Mon Feb 9 18:18:44 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA18231 for ipsec-outgoing; Mon, 9 Feb 1998 18:13:38 -0500 (EST) Message-Id: <98Feb9.182626est.11657@janus.tor.securecomputing.com> To: ipsec@tis.com Cc: tytso@MIT.EDU, rgm-sec@htt-consult.com Subject: Standarisation status (was Re: Unnecessarily bloated IV calculation) References: <199802092218.RAA08119@carp.morningstar.com> In-reply-to: Your message of "Mon, 09 Feb 1998 17:18:09 -0500". <199802092218.RAA08119@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: Mon, 9 Feb 1998 18:25:25 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199802092218.RAA08119@carp.morningstar.com>, Ben Rogers writes: > > Please don't dismiss this message as creating unnecessary changes "at > this late date". I have been hearing that for nearly six months, while > the WG is seeming to stagnate under the burden of an unnecessarily > bloated protocol. Speaking of which: WHERE ARE THE FINAL DOCUMENTS? I remember a bug push to get everything ready for the December IETF, and then a promise that they'd be ready shortly thereafter. Are we *ever* going to publish this puppy? -- Harald From owner-ipsec Mon Feb 9 19:41:42 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA18796 for ipsec-outgoing; Mon, 9 Feb 1998 19:40:29 -0500 (EST) Message-ID: <34DFA4C7.167E@cs.umass.edu> Date: Mon, 09 Feb 1998 19:52:23 -0500 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha) MIME-Version: 1.0 To: IP Security List Subject: Re: Unnecessarily bloated IV calculation References: <199802092218.RAA08119@carp.morningstar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Ben Rogers quoted: > >From [IO-RES] Appendix B: > > In phase 1, material for the initialization vector (IV material) > for CBC mode encryption algorithms is derived from a hash of a > concatenation of the initiator's public Diffie-Hellman value and > the responder's public Diffie-Hellman value using the negotiated > hash algorithm. This is used for the first message only. [IORES] Sec. 5.3 actually specifies a different first-payload IV for phase 1 exchanges that are authenticated w/ the revised PK encryption method: If CBC mode is used for the symmetric encryption then the initialization vectors (IVs) are set as follows. The IV for encrypting the first payload following the nonce is set to 0 (zero). The IV for subsequent payloads encrypted with the ephemeral symmetric cipher key, Ke_i, is the last ciphertext block of the previous payload. For these exchanges the parties' public DH values can't be used for first-payload IV derivation, since the first-payload IV must already be available when the initiator encrypts its KE payload. However, to avoid the use of a constant first-payload IV in these exchanges we could derive the first-payload IV from the parties' public keys, e.g. IV = Hash(PubKey_i || PubKey_r). Deriving the first-payload IV from the cookies doesn't seem to work for Aggressive Mode, because the initiator needs the first-payload IV before receiving the responder's cookie. -Lewis From owner-ipsec Mon Feb 9 19:51:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA18890 for ipsec-outgoing; Mon, 9 Feb 1998 19:51:37 -0500 (EST) Message-Id: <199802100103.RAA17086@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: ben@Ascend.COM (Ben Rogers) Cc: ipsec@tis.com Subject: Re: Unnecessarily bloated IV calculation In-Reply-To: Your message of "Mon, 09 Feb 1998 17:18:09 EST." <199802092218.RAA08119@carp.morningstar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 09 Feb 1998 17:03:24 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk >From [IO-RES] Appendix B: > > In phase 1, material for the initialization vector (IV material) for > CBC mode encryption algorithms is derived from a hash of a > concatenation of the initiator's public Diffie-Hellman value and the > responder's public Diffie-Hellman value using the negotiated hash > algorithm. This is used for the first message only. Each message > should be padded up to the nearest block size using bytes containing > 0x00. The message length in the header MUST include the length of the > pad since this reflects the size of the cyphertext. Subsequent > messages MUST use the last CBC encryption block from the previous > message as their initialization vector. > >Why do we need to do so much work to generate this IV? I realize that >we want some sort of uniqueness guarantee, but this is absurd. I know >this sort of calculation is cheap for many implementors, but it both >takes extra CPU cycles and extra code space to implement while adding no >additional security. If you're product can't do an additional hash to generate an IV then the problem isn't this requirement, it's your product. > I would suggest using the cookies to generate this IV. The cookies are > with us from the beginning, so we don't have to delay this calculation > any longer than necessary. (Has anyone tried to produce a state machine > for ISAKMP/Oakley?). If not, perhaps an XOR of the two DH values would > be okay. Either way, neither end can compromise the security for both > ends. "using the cookies" is a particularly vague suggestion: pass. XORing the DH public values is an alternative to hashing the DH public values. I'm not sure, though, how it frees you from the apparent crushing burden this bloated protocol is putting on you. It might save a few CPU cycles but compared to the rest of what you're doing-- Diffie-Hellmen exponentiations, probably 3 public key operations (sign, verify peer's cert, verify peer's signature), etc-- it's noise. You're not the only person writing code for an embedded system that has to run on a variety of platforms each with differing memory and speed constraints. You're just the only one who can't seem to stop whining about it. > Please don't dismiss this message as creating unnecessary changes "at > this late date". I have been hearing that for nearly six months, while > the WG is seeming to stagnate under the burden of an unnecessarily > bloated protocol. There are many simple changes such as this which > would make the protocol much more implementor-friendly, while not > negatively affecting the security at all. I've been hearing that you have these simple, implementor-friendly changes for about the last 8 months. This one is quite pointless, trivial, and unnecessary and even though you said please I can't wait forever to hear the rest: it's too late. For those of you who are wondering, the I-O resolution document will be finished in the next day or two. I have a few editorial changes to make. Just for the record, one of the things I've been waiting on was a simple, generic CBC-MAC paper that a certain vocal I-O resolution document critic had promised to write so I could reference it. Alas, it never materialized and we'll just have to live without it. Dan. From owner-ipsec Mon Feb 9 20:41:49 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA19229 for ipsec-outgoing; Mon, 9 Feb 1998 20:40:32 -0500 (EST) Date: Mon, 9 Feb 1998 20:52:28 -0500 (EST) Message-Id: <199802100152.UAA08541@carp.morningstar.com> From: Ben Rogers To: Daniel Harkins Cc: ben@Ascend.COM (Ben Rogers), ipsec@tis.com Subject: Re: Unnecessarily bloated IV calculation In-Reply-To: <199802100103.RAA17086@dharkins-ss20.cisco.com> References: <199802092218.RAA08119@carp.morningstar.com> <199802100103.RAA17086@dharkins-ss20.cisco.com> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Daniel Harkins writes: > >Why do we need to do so much work to generate this IV? I realize that > >we want some sort of uniqueness guarantee, but this is absurd. I know > >this sort of calculation is cheap for many implementors, but it both > >takes extra CPU cycles and extra code space to implement while adding no > >additional security. > > If you're product can't do an additional hash to generate an IV then the > problem isn't this requirement, it's your product. I'm not claiming it can't do the additional hash, but claiming only that it is unnecessary. Certainly IP could have been written to use the first 16 bits of an MD5 hash instead of a simple checksum, but it doesn't because the checksum gives about the same functionality for far fewer cycles. > > I would suggest using the cookies to generate this IV. The cookies are > > with us from the beginning, so we don't have to delay this calculation > > any longer than necessary. (Has anyone tried to produce a state machine > > for ISAKMP/Oakley?). If not, perhaps an XOR of the two DH values would > > be okay. Either way, neither end can compromise the security for both > > ends. > > "using the cookies" is a particularly vague suggestion: pass. Pardon. I was hoping everyone on this list would be able to draw their own conclusions, or at least ask if it weren't clear. How about an XOR of the cookies. Repeated (perhaps with bitwise NOT's) if necessary to generate a longer IV. Will you pass on this quite so simply? > XORing the DH public values is an alternative to hashing the DH public > values. I'm not sure, though, how it frees you from the apparent crushing > burden this bloated protocol is putting on you. It might save a few CPU > cycles but compared to the rest of what you're doing-- Diffie-Hellmen > exponentiations, probably 3 public key operations (sign, verify peer's cert, > verify peer's signature), etc-- it's noise. Noise tends to add up. Especially in the case of ISAKMP/Oakley. I don't know how many of these sorts of things I've seen, but figured it would be helpful to test the waters with one of the more glaring problems. Moreover, unless you can say with certainty you know the optimizations _every_ implementor might make with respect to certain costly operations (DH, RSA, DSS, etc.), the above statement is logically flawed. I can certainly think of real-world scenarios where the single hash calculation I mentioned would be more expensive than the DH and PK operations combined. For example, on many CPUs, it might be impossible to do the DH calculations in reasonable time, requiring a bignum co-processor for the box to support Key Exchange at all. Since RSA is also bignum based, this can also be offloaded. However, the processor is sufficient to handle the crypto requirements of IPsec and ISAKMP other than the ones I've already mentioned. In this case, an unnecessary HASH calculation isn't as trivial as you might think. [Personal attacks deleted] Dan, It was my intention to only pose the question of why we were doing a completely unnecessary calculation. I didn't intend to make any statements about either your document or your person. I realize that your position is an extremely difficult one to be in. However, you don't need to make it more difficult by taking personal offense from innocent questions and/or starting unnecessary flame wars. ben From owner-ipsec Mon Feb 9 21:46:31 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA19763 for ipsec-outgoing; Mon, 9 Feb 1998 21:45:31 -0500 (EST) Message-Id: <199802100257.SAA17193@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: ben@Ascend.COM (Ben Rogers) Cc: ipsec@tis.com Subject: Re: Unnecessarily bloated IV calculation In-Reply-To: Your message of "Mon, 09 Feb 1998 20:52:28 EST." <199802100152.UAA08541@carp.morningstar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 09 Feb 1998 18:57:41 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Ben, It's way too late to entertain changes such as this. My logic may be flawed and a single hash may be more expensive than a complete Diffie-Hellman exchange and 3 public key operations combined. Fine. Whatever. But this breaks interoperability. It is not backwards compatible. And it's way too late. Had you made this suggestion last year I'm sure it would've been incorporated into the document. We're not going to hold this up for another 6 months just to change a hash to an exclusive or. That would be insane. > [Personal attacks deleted] Me thinks thou protesteth too much. > Dan, > > It was my intention to only pose the question of why we were doing a > completely unnecessary calculation. I didn't intend to make any > statements about either your document or your person. I realize that > your position is an extremely difficult one to be in. However, you > don't need to make it more difficult by taking personal offense from > innocent questions and/or starting unnecessary flame wars. Perhaps I need a beer (as has just been pointed out) but I can't help but think that perhaps the flames wouldn't be so strong if it wasn't for that gasoline. It is particularly difficult to guage tone in email but when you phrase "innocent" questions with things like absurd, unnecessarily bloated, burdensome, etc. it doesn't come out so innocent. Compound that with the observation that you have complained in the past about vagueness and lack of clarity but have failed to follow up on your (accepted) offers of clear, unambiguous verbage. Personal attacks? Me? Nah. Let me remind you that a past criticism you had was that there was no reference for a generic CBC-MAC. You volunteered to write one. If you produce one in the next two days I can reference it and satisfy at least one of the issues you have with the I-O resolution document. But changing a hash to an exclusive or is too little too late with too much impact on existing interoperable implementations. off to drink that beer, Dan. From owner-ipsec Mon Feb 9 22:51:07 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA20158 for ipsec-outgoing; Mon, 9 Feb 1998 22:49:31 -0500 (EST) Message-ID: <34DF73EE.71888B29@nortel.ca> Date: Mon, 09 Feb 1998 22:23:58 +0100 From: "Marcus Leech" Organization: Security Development X-Mailer: Mozilla 2.02 (X11; I; Linux 1.2.13 i486) MIME-Version: 1.0 To: Ben Rogers CC: ipsec@tis.com Subject: Re: Unnecessarily bloated IV calculation References: <199802092218.RAA08119@carp.morningstar.com> <199802100103.RAA17086@dharkins-ss20.cisco.com> <199802100152.UAA08541@carp.morningstar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > > I'm not claiming it can't do the additional hash, but claiming only that > it is unnecessary. Certainly IP could have been written to use the > first 16 bits of an MD5 hash instead of a simple checksum, but it > doesn't because the checksum gives about the same functionality for far > fewer cycles. > To be annoyingly pedantic, your example is cooked. IP has been around for rather longer than cryptographic hash functions have been widely deployed and understood, and it was designed to run fast on hardware of 1970s vintage. I doubt that IPSEC would have been considered as feasible at all in the environment that IP germinated in. > > Moreover, unless you can say with certainty you know the optimizations > _every_ implementor might make with respect to certain costly operations > (DH, RSA, DSS, etc.), the above statement is logically flawed. I can > certainly think of real-world scenarios where the single hash > calculation I mentioned would be more expensive than the DH and PK > operations combined. For example, on many CPUs, it might be impossible > to do the DH calculations in reasonable time, requiring a bignum > co-processor for the box to support Key Exchange at all. Since RSA is > also bignum based, this can also be offloaded. However, the processor > is sufficient to handle the crypto requirements of IPsec and ISAKMP > other than the ones I've already mentioned. In this case, an > unnecessary HASH calculation isn't as trivial as you might think. > Let's take a look at it another way. You'd like to save a couple of MD5 calculations during key negotiation, but are willing to pay for them during per-packet processing. Even if you change keys every 100 packets, your extra MD5 in the key negotiation isn't going to matter very much. I'm certainly unwilling to have a system in which key agreeement is blindingly fast, and per-packet processing is horribly slow, so I propose that we drop both MD5 and anything more sophisticated than ROT13, in the interest of saving underprivileged CPUs from having to work up too much of a sweat :-) From owner-ipsec Tue Feb 10 09:25:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA24097 for ipsec-outgoing; Tue, 10 Feb 1998 09:21:32 -0500 (EST) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64CF523E6@wade.reo.dec.com> From: Stephen Waters To: l2tp@zendo.com, ipsec@tis.com Cc: Stephen Waters Subject: L2TP + IPSEC question Date: Tue, 10 Feb 1998 13:59:46 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Sorry if this subject has already been done-to-death: I've just been reading the draft on using IPSEC to defend L2TP. Of the two models proposed, (compulsory and voluntarily), the 'Voluntarily' options feels safer to me (from a security management point of view). So, if my clients are IP-only, why do I need IPSEC AND L2TP? Why not just IPSEC tunnel? Here are a few cases : 1) PPP on client, L2TP LAC at ISP POP:- Unprotected L2TP exchange not secure, hence the draft. 2) PPP on client, L2TP LAC at ISP POP + IPSEC encapsulation:- L2TP secure, but means sharing security information 3) L2TP on Client :- as for 1) and tunnel server address has to be known by the client, no longer available from the ISP 4) L2TP on Client + IPSEC:- secure, but why use L2TP when PPP in IPSEC would do, and for IP-Only, not even PPP. 5) IPSEC on Client:- secure, but how can the tunnel server address be discovered? Option 5) seems to be the best answer for IP-Only and there seems to be a PPP in IPSEC option for other requirements. If there is a requirement for the tunnel server address to be discovered by the client, no pre-configured, then the ISPs could provide a PPP-based tunnel server address via PPP_IPCP. The IPSEC code could then use DHCP to acquire the Intranet address if not static. If there any comments on this, can someone copy me directly - just joined the distribution lists. Thanks, Steve. From owner-ipsec Tue Feb 10 09:26:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA24119 for ipsec-outgoing; Tue, 10 Feb 1998 09:24:53 -0500 (EST) Message-Id: <3.0.5.32.19980210093228.009d1c20@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 10 Feb 1998 09:32:28 -0500 To: Daniel Harkins From: Robert Moskowitz Subject: Re: Unnecessarily bloated IV calculation Cc: ipsec@tis.com In-Reply-To: <199802100103.RAA17086@dharkins-ss20.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 05:03 PM 2/9/98 -0800, Daniel Harkins wrote: > >Just for the record, one of the things I've been waiting on was a simple, >generic CBC-MAC paper that a certain vocal I-O resolution document critic >had promised to write so I could reference it. Alas, it never materialized >and we'll just have to live without it. Actually, there was an ID on this. It is part of IPsecond, as it did not gather strong backing at Munich. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Tue Feb 10 10:01:26 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA24387 for ipsec-outgoing; Tue, 10 Feb 1998 09:59:38 -0500 (EST) Date: Tue, 10 Feb 1998 10:10:50 -0500 (EST) Message-Id: <199802101510.KAA17177@carp.morningstar.com> From: Ben Rogers To: "Marcus Leech" Cc: ipsec@tis.com Subject: Re: Unnecessarily bloated IV calculation In-Reply-To: <34DF73EE.71888B29@nortel.ca> References: <199802092218.RAA08119@carp.morningstar.com> <199802100103.RAA17086@dharkins-ss20.cisco.com> <199802100152.UAA08541@carp.morningstar.com> <34DF73EE.71888B29@nortel.ca> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Marcus Leech writes: > > > > I'm not claiming it can't do the additional hash, but claiming only that > > it is unnecessary. Certainly IP could have been written to use the > > first 16 bits of an MD5 hash instead of a simple checksum, but it > > doesn't because the checksum gives about the same functionality for far > > fewer cycles. > > > To be annoyingly pedantic, your example is cooked. IP has been around for > rather longer than cryptographic hash functions have been widely deployed > and understood, and it was designed to run fast on hardware of 1970s vintage. > I doubt that IPSEC would have been considered as feasible at all in the > environment that IP germinated in. However, if you were designing IP today, would you design it around hash codes or around a simple checksum? My point (though I seem to have failed in making it very eloquently) was that a hash code or checksum would provide essentially the equivalent functionality. Why add the additional processing requirement when it is not needed? Instead of arguing against a pedantic and cooked example, perhaps you could describe to me the reason that the hash gives us more functionality than the simple XOR I suggested. It certainly takes more procesing power. Yes, we do have more processor to spare than they did in the 1970s, and yes, key negotiation doesn't happen that frequently. However, that is not justification for making the protocol more complicated. I guess I still hold onto the philosophy of "Keep It Simple, Stupid". (No offense is intended for anyone here -- I just don't know a more effective way to express the same concept.) > Let's take a look at it another way. You'd like to save a couple of MD5 calculations > during key negotiation, but are willing to pay for them during per-packet processing. > Even if you change keys every 100 packets, your extra MD5 in the key negotiation > isn't going to matter very much. I'm certainly unwilling to have a system in which > key agreeement is blindingly fast, and per-packet processing is horribly slow, so I > propose that we drop both MD5 and anything more sophisticated than ROT13, in the > interest of saving underprivileged CPUs from having to work up too much of a sweat :-) I'm willing to pay for them during per-packet processing because it is necessary to have a cryptographically strong hash for that purpose. However, I'm not willing to do extra computation _anywhere_ unless I get something in return for it. Can anyone describe to me what we get in return for the extra hash computation? ben From owner-ipsec Tue Feb 10 10:16:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA24517 for ipsec-outgoing; Tue, 10 Feb 1998 10:14:53 -0500 (EST) Date: Tue, 10 Feb 1998 10:19:13 -0500 (EST) Message-Id: <199802101519.KAA17292@carp.morningstar.com> From: Ben Rogers To: Robert Moskowitz Cc: Daniel Harkins , ipsec@tis.com Subject: Re: Unnecessarily bloated IV calculation In-Reply-To: <3.0.5.32.19980210093228.009d1c20@homebase.htt-consult.com> References: <199802100103.RAA17086@dharkins-ss20.cisco.com> <3.0.5.32.19980210093228.009d1c20@homebase.htt-consult.com> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Robert Moskowitz writes: > At 05:03 PM 2/9/98 -0800, Daniel Harkins wrote: > > > >Just for the record, one of the things I've been waiting on was a simple, > >generic CBC-MAC paper that a certain vocal I-O resolution document critic > >had promised to write so I could reference it. Alas, it never materialized > >and we'll just have to live without it. > > Actually, there was an ID on this. It is part of IPsecond, as it did not > gather strong backing at Munich. Bob- I have this draft mostly completed, and can have it under the group's collective scrutiny by tomorrow (Wednesday) evening. My assertion in Washington was that the IO-RES draft is incomplete without it, and I stand by that. (For those who might have missed this -- we use 3DES-CBC-MAC as a REQUIRED prf in IO-RES, and have as a reference only Schneier's book, which is too vague to be building a protocol from.) I don't know however, if the political machine has allowed the time for a new draft to be introduced. Perhaps we can take a poll on the list as to who thinks this is a necessary addition? ben From owner-ipsec Tue Feb 10 11:52:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA25183 for ipsec-outgoing; Tue, 10 Feb 1998 11:40:34 -0500 (EST) Message-ID: From: Roy Pereira To: "'ben@Ascend.COM'" , "'Marcus Leech'" Cc: "'ipsec@tis.com'" Subject: RE: Unnecessarily bloated IV calculation Date: Tue, 10 Feb 1998 12:17:09 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk This is utterly ridiculous! IPSec is done, well-done in my opinion. 1] I'd like to release IPSec products. 2] My customers want me to release IPSec products. 3] The market wants me (and you) to release IPSec products. What the hell are we trying to do at this late stage anyways? And why are we arguing about something that takes less than 1% of the exchange time. Gee, why don't we get rid of DH since it takes way too long to generate secret keys? ;-) Let's close off IPSec and if we want to add or modify anything, then lets do it in IPSecond. >-----Original Message----- >From: Ben Rogers [SMTP:ben@Ascend.COM] >Sent: Tuesday, February 10, 1998 10:11 AM >To: Marcus Leech >Cc: ipsec@tis.com >Subject: Re: Unnecessarily bloated IV calculation > >Marcus Leech writes: >> > >> > I'm not claiming it can't do the additional hash, but claiming only that >> > it is unnecessary. Certainly IP could have been written to use the >> > first 16 bits of an MD5 hash instead of a simple checksum, but it >> > doesn't because the checksum gives about the same functionality for far >> > fewer cycles. >> > >> To be annoyingly pedantic, your example is cooked. IP has been around for >> rather longer than cryptographic hash functions have been widely deployed >> and understood, and it was designed to run fast on hardware of 1970s >>vintage. >> I doubt that IPSEC would have been considered as feasible at all in the >> environment that IP germinated in. > >However, if you were designing IP today, would you design it around hash >codes or around a simple checksum? My point (though I seem to have >failed in making it very eloquently) was that a hash code or checksum >would provide essentially the equivalent functionality. Why add the >additional processing requirement when it is not needed? > >Instead of arguing against a pedantic and cooked example, perhaps you >could describe to me the reason that the hash gives us more >functionality than the simple XOR I suggested. It certainly takes more >procesing power. Yes, we do have more processor to spare than they did >in the 1970s, and yes, key negotiation doesn't happen that frequently. >However, that is not justification for making the protocol more >complicated. I guess I still hold onto the philosophy of "Keep It >Simple, Stupid". (No offense is intended for anyone here -- I just >don't know a more effective way to express the same concept.) > >> Let's take a look at it another way. You'd like to save a couple of MD5 >>calculations >> during key negotiation, but are willing to pay for them during per-packet >>processing. >> Even if you change keys every 100 packets, your extra MD5 in the key >>negotiation >> isn't going to matter very much. I'm certainly unwilling to have a >>system in which >> key agreeement is blindingly fast, and per-packet processing is horribly >>slow, so I >> propose that we drop both MD5 and anything more sophisticated than ROT13, >>in the >> interest of saving underprivileged CPUs from having to work up too much >>of a sweat :-) > >I'm willing to pay for them during per-packet processing because it is >necessary to have a cryptographically strong hash for that purpose. >However, I'm not willing to do extra computation _anywhere_ unless I get >something in return for it. Can anyone describe to me what we get in >return for the extra hash computation? > > >ben > From owner-ipsec Tue Feb 10 13:01:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA25646 for ipsec-outgoing; Tue, 10 Feb 1998 12:58:01 -0500 (EST) Message-Id: <199802101808.KAA17472@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: ben@Ascend.COM (Ben Rogers) Cc: Robert Moskowitz , ipsec@tis.com Subject: Re: Unnecessarily bloated IV calculation In-Reply-To: Your message of "Tue, 10 Feb 1998 10:19:13 EST." <199802101519.KAA17292@carp.morningstar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 10 Feb 1998 10:08:29 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Ben, > I have this draft mostly completed, and can have it under the group's > collective scrutiny by tomorrow (Wednesday) evening. My assertion in > Washington was that the IO-RES draft is incomplete without it, and I > stand by that. (For those who might have missed this -- we use > 3DES-CBC-MAC as a REQUIRED prf in IO-RES, and have as a reference only > Schneier's book, which is too vague to be building a protocol from.) Wow! I did miss that. Please point out where it says that 3DES-CBC-MAC is REQUIRED or MUST or anything like that. > I don't know however, if the political machine has allowed the time for a > new draft to be introduced. The political machine! That's a good one. > Perhaps we can take a poll on the list as to who thinks this is a > necessary addition? That ticking sound you hear is time running out on the clock. How about if you release it, and I reference it. The WG can then hash out :-) any issues it has but the reference remains. Not being tied into The Political Machine can someone who is tell me if this is ok? Can this RFC-bound draft refer to another draft that has not yet been sufficiently analyzed by the WG? Dan. From owner-ipsec Tue Feb 10 13:56:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA26099 for ipsec-outgoing; Tue, 10 Feb 1998 13:53:36 -0500 (EST) Message-ID: From: Roy Pereira To: "'Stephen Waters'" , "'l2tp@zendo.com'" , "'ipsec@tis.com'" Subject: RE: L2TP + IPSEC question Date: Tue, 10 Feb 1998 14:30:55 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk That's a good point. We looked at this dilemma a while back and went with only IPSec tunneling. L2TP is good for when you have other protocols other than IP, but that doesn't happen too often anymore. With IPSec tunnelling you can accomplish almost everything that the layer 2 (L2F, PPTP, L2TP) protocols can and you have real security. >-----Original Message----- >From: Stephen Waters [SMTP:Stephen.Waters@digital.com] >Sent: Tuesday, February 10, 1998 9:00 AM >To: l2tp@zendo.com; ipsec@tis.com >Cc: Stephen Waters >Subject: L2TP + IPSEC question > > >Sorry if this subject has already been done-to-death: > >I've just been reading the draft on using IPSEC to defend L2TP. > >Of the two models proposed, (compulsory and voluntarily), the >'Voluntarily' options feels safer to me (from a security management >point of view). > >So, if my clients are IP-only, why do I need IPSEC AND L2TP? Why not >just IPSEC tunnel? > >Here are a few cases : > > >1) PPP on client, L2TP LAC at ISP POP:- Unprotected L2TP exchange >not secure, hence the draft. >2) PPP on client, L2TP LAC at ISP POP + IPSEC encapsulation:- L2TP >secure, but means sharing security information >3) L2TP on Client :- as for 1) and tunnel server address has to be >known by the client, no longer available from the ISP >4) L2TP on Client + IPSEC:- secure, but why use L2TP when PPP in IPSEC >would do, and for IP-Only, not even PPP. >5) IPSEC on Client:- secure, but how can the tunnel server address be >discovered? > > >Option 5) seems to be the best answer for IP-Only and there seems to be >a PPP in IPSEC option for other requirements. >If there is a requirement for the tunnel server address to be >discovered by the client, no pre-configured, then the ISPs could >provide a PPP-based tunnel server address via PPP_IPCP. The IPSEC code >could then use DHCP to acquire the Intranet address if not static. > >If there any comments on this, can someone copy me directly - just >joined the distribution lists. > >Thanks, Steve. > > > From owner-ipsec Tue Feb 10 14:09:11 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA26199 for ipsec-outgoing; Tue, 10 Feb 1998 14:06:36 -0500 (EST) X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Sumit Vakil" To: Stephen.Waters@digital.com cc: ipsec@tis.com Message-ID: <862565A7.005C149B.00@mwgate01.mw.3com.com> Date: Tue, 10 Feb 1998 12:55:35 -0600 Subject: Re: L2TP + IPSEC question Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk >Sorry if this subject has already been done-to-death: >I've just been reading the draft on using IPSEC to defend L2TP. >Of the two models proposed, (compulsory and voluntarily), the 'Voluntarily' options feels safer to me (from a security management point of view). >So, if my clients are IP-only, why do I need IPSEC AND L2TP? Why not just IPSEC tunnel? 1. AH and ESP are simply headers. ISAKMP is the one IPSec protocol that allows information exchange between communicating parties. There is no defined way to establish outgoing calls (LNS initiated calls) using ISAKMP. 2. L2TP offloads PPP processing (especially CPU consuming CCP and ECP) to the ISP's customer. 3. L2TP allows user authentication and configuration to be left to the ISP's customer. 4. Call statistics can be forwarded from the LAC to the LNS. >Here are a few cases : >1) PPP on client, L2TP LAC at ISP POP:- Unprotected L2TP exchange >not secure, hence the draft. >2) PPP on client, L2TP LAC at ISP POP + IPSEC encapsulation:- L2TP >secure, but means sharing security information I don't think I understand. If the LAC establishes a SA with the LNS, it will not share the SA information with the client. If the client is using AH/ESP to protect its traffic, it will be transparent to the LAC and the LNS since AH/ESP happen at the IP layer. Hence the client does not have to do any security info sharing with the LAC or the LNS. BTW, securing L2TP does not in any way protect the dial-up line. >3) L2TP on Client :- as for 1) and tunnel server address has to be >known by the client, no longer available from the ISP I'm assuming that you mean the dial-up client here. Why would the client do L2TP? L2TP is a layer 2 tunneling protocol that defines how to tunnel PPP packets received from the client. It would not make sense for the client to encapsulate PPP packets in L2TP and then encapsulate L2TP in PPP. The client simply runs PPP and L2TP happens between the LAC and the LNS. Neither the LAC, nor the LNS ever pass the tunnel server endpoint back to the client. >4) L2TP on Client + IPSEC:- secure, but why use L2TP when PPP in IPSEC would do, and for IP-Only, not even PPP. PPP is a layer 2 protocol for point-to-point links. IP is layer 3. How can you run IP directly over, say, a dial-up link? So, you would need PPP. If you want to use ESP with PPP, you'd have to define a new PPP protocol like CCP or ECP. The PPP session would still have to terminate at the ISP's NAS. The NAS would have to extract the layer 3 packet from the PPP packet, and then somehow get it to the tunnel server endpoint. ECP already allows PPP encryption. >5) IPSEC on Client:- secure, but how can the tunnel server address be >discovered? The client does not need to know anything about tunnel servers. It may be doing AH/ESP, but that happens at the IP layer and is hidden from the LAC and LNS. As far as how the client discovers a security gateway, that's still an unresolved issue. The LAC can find the tunnel server (LNS) address in a few different ways: 1. During user authentication, the RADIUS server could return the tunnel server endpoint along with the rest of the user configuration. 2. A NAS port may be hardwired to tunnel all incoming calls to a configured LNS. 3. The DNIS for the incoming call could indicate the LNS address. >Option 5) seems to be the best answer for IP-Only and there seems to be a PPP in IPSEC option for other requirements. >If there is a requirement for the tunnel server address to be discovered by the client, no pre-configured, then the ISPs could provide a PPP-based tunnel server >address via PPP_IPCP. The IPSEC code could then use DHCP to acquire the Intranet address if not static. One way to do things would be for the client to run IPSec end-to-end. L2TP (protected by some security mechanism) would be used to tunnel PPP from the LAC to the LNS. This would protect the dial-up line and the channel between the LAC and the LNS. And, the client would not have to trust the LAC (which may belong to an ISP). >If there any comments on this, can someone copy me directly - just joined the distribution lists. >Thanks, Steve. Sumit A. Vakil Security and Mobility Advanced Development 3Com, Corp. Received: from usr.com (mailgate.usr.com) by robogate2.usr.com with SMTP (IMA Internet Exchange 2.02 Enterprise) id 4E07FF70; Tue, 10 Feb 98 10:27:35 -0600 Received: from portal.ex.tis.com by usr.com (8.8.5/3.1.090690-US Robotics) id KAA24020; Tue, 10 Feb 1998 10:08:34 -0600 (CST) Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA24097 for ipsec-outgoing; Tue, 10 Feb 1998 09:21:32 -0500 (EST) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64CF523E6@wade.reo.dec.com> From: Stephen Waters To: l2tp@zendo.com, ipsec@tis.com Cc: Stephen Waters Subject: L2TP + IPSEC question Date: Tue, 10 Feb 1998 13:59:46 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk From owner-ipsec Tue Feb 10 16:24:24 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA27160 for ipsec-outgoing; Tue, 10 Feb 1998 16:22:39 -0500 (EST) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64CF523EE@wade.reo.dec.com> From: Stephen Waters To: ipsec@tis.com Cc: Stephen Waters Subject: Discovery of tunnel server from ISP POP Date: Tue, 10 Feb 1998 21:24:39 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk A number of short-comings are leveled at IPSEC regarding address assignment mechanisms. The DHCP+ISAKMP draft covers the allocation of an Intranet address, but how does an IPSEC client discover the Internet address of the IPSEC Security Gateway? In the L2TP model, the tunnel is connected by the ISP 'LAC' once the client has been authenticated via PPP PAP/CHAP. The LAC knows where the appropriate tunnel end-point is. For IPSEC, could the ISP also offer security gateway address resolution? For example, an extension to the PPP IPCP NCP could allow the ISP to deliver the Internet address of the IPSEC security Gateway for a given client (identified in the same way, PAP/CHAP). Ideally, this support would allow a list of addresses to be supplied in a similar way to the passing of Primary and Secondary DNS servers via IPCP. This would allow the client to re-connect should a primary server fail or become unreachable. Is this worth a (very short) draft proposing an extension to IPCP? Since this exchange provides Internet addresses, is there any need to protect/encrypt this information? If there is, then things start to get messy (arranging encrypted sessions with the ISP POP). The L2TP LAC model avoids this sticky issue of IPCP exchanges in the clear since PPP encryption has picked in with the tunnel server by the time IPCP starts-up. Regards, Steve. (I'm not getting copied on the dist-list yet, so any reply needs to come direct). From owner-ipsec Tue Feb 10 16:54:19 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA27363 for ipsec-outgoing; Tue, 10 Feb 1998 16:53:41 -0500 (EST) Message-Id: <199802102206.RAA12417@istari.sandelman.ottawa.on.ca> To: Stephen Waters CC: ipsec@tis.com Subject: Re: Discovery of tunnel server from ISP POP In-reply-to: Your message of "Tue, 10 Feb 1998 21:24:39 GMT." <250F9C8DEB9ED011A14D08002BE4F64CF523EE@wade.reo.dec.com> Date: Tue, 10 Feb 1998 17:06:25 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Stephen" == Stephen Waters writes: Stephen> A number of short-comings are leveled at IPSEC regarding address Stephen> assignment mechanisms. The DHCP+ISAKMP draft covers the Stephen> allocation of an Intranet address, but how does an IPSEC client Stephen> discover the Internet address of the IPSEC Security Gateway? This is the topic for the proposed KX and TX records. If the "intranet" is world routable (not necessarily a reasonable assumption in the IPv4 world, but IPv6 suggests it isn't an issue), then it may also be reasonable to send an ICMP message (an echo) to the desired end node, and watch for an ICMP admin denied message coming back. (One could even just transmit the TCP SYN, but that may be more information than one desires to reveal in the clear. Another option is to send an ISAKMP initiator message) It would come back from security gateway. If one had sent an ISAKMP message, that might be a signal to the gateway to initiate an ISAKMP with the end node. Given appropriate certificates presented by the client and gateway to establish that each is authorized to speak for their respective entities (users on the client, networks on gateway), then the gateway discovery is done. If the network is not routable, then the LAC (LAC === ?? variation of NAS?) has to configured to know where the tunnel is supposed to go anyway. In that case, I see it as being fairly reasonable to provide this information in an IPCP message during PPP. Stephen> Is this worth a (very short) draft proposing an extension to Stephen> IPCP? Since this exchange provides Internet addresses, is there Stephen> any need to protect/encrypt this information? If there is, then I think it is worth a draft. I do not think it is necessary to encrypt the info. Any observer that can see that information is going to be able to later see the encrypted (tunnelled) packets hit that gateway address anyway. Can the data be modified in transit across that modem link? If it is, then the client simply fails to establish a secure tunnel. Denial of service. If the attacker can modify, they can also just garble to cause the same affect. :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON Michael Richardson |Network and security consulting and contract programming Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNODPW9iXVu0RiA21AQEg2wMAoZZXuREfPxmdAj/jxXlF4QHQ07Ka8gla etxkh43bjq6wOrmDqF+ZuWlNExQDuLH1O1UzMHF8zKhmGEaZhNKxACJM6NCh4EVa Nd48khfzXneRcSSdw6cVfIBfVrBQbdLQ =NaJA -----END PGP SIGNATURE----- From owner-ipsec Tue Feb 10 17:28:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA27543 for ipsec-outgoing; Tue, 10 Feb 1998 17:27:40 -0500 (EST) Date: Tue, 10 Feb 1998 17:39:38 -0500 Message-Id: <199802102239.RAA26137@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "C. Harald Koch" Cc: ipsec@tis.com, rgm-sec@htt-consult.com In-Reply-To: C. Harald Koch's message of Mon, 9 Feb 1998 18:25:25 -0500, <98Feb9.182626est.11657@janus.tor.securecomputing.com> Subject: Re: Standarisation status (was Re: Unnecessarily bloated IV calculation) Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk From: "C. Harald Koch" Date: Mon, 9 Feb 1998 18:25:25 -0500 Speaking of which: WHERE ARE THE FINAL DOCUMENTS? I remember a bug push to get everything ready for the December IETF, and then a promise that they'd be ready shortly thereafter. Are we *ever* going to publish this puppy? My apologies. Bob got swamped in a job change, and I got swamped handling some non-IETF work for my employer... as a result, we weren't as agressive as we could have been to push the document editors to get the final edits (to deal with the issues rasied at the document reading party) done and published as I-D's. We've since gotten pressure from the IP Compression Folks (whose work has just finished IETF last call and is blocking on our documents) as well as from the IESG, to get these documents done. As a result, I contacted the various document editors last week and asked them, "Cough, cough.... when?" Nearly all of them apologized and explained that they had similarly gotten caught up with other work-related priorities, and committed to getting new drafts out by Friday of this week. So hopefully we will be able to start an working group last call on those documents which are published as I-D's this Friday, so that we get these documents to the IESG as soon as we can. - Ted From owner-ipsec Tue Feb 10 18:20:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA27901 for ipsec-outgoing; Tue, 10 Feb 1998 18:19:44 -0500 (EST) Message-Id: <3.0.3.32.19980210183329.03241218@pop.hq.tis.com> X-Sender: balenson@pop.hq.tis.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 10 Feb 1998 18:33:29 -0500 To: balenson@tis.com From: "David M. Balenson" Subject: REMINDER: ISOC 1998 Network and Distributed System Security Symposium Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk ---------------------------------------------------------------------------- David M. Balenson, AR&E Cryptographic Technologies Group Trusted Information Systems, 3060 Washington Road, Glenwood, MD 21738 USA balenson@tis.com; 301-854-5358; fax 301-854-5363 From owner-ipsec Tue Feb 10 21:29:42 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA29206 for ipsec-outgoing; Tue, 10 Feb 1998 21:27:46 -0500 (EST) Date: Tue, 10 Feb 1998 21:40:38 -0500 (EST) Message-Id: <199802110240.VAA06780@carp.morningstar.com> From: Ben Rogers To: ipsec@tis.com Subject: Generic CBC-MAC specification Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk After finally finding time to hit the library (albiet with a little 'encouragement'... ;) ), I've completed the Discussion section of this draft. If someone could point me towards the proper procedure for submission to the IETF, I'd be much obliged. Bob, Ted-- Should this be considered a 'draft-ietf-ipsec-' document, or should it be published under my own name? Dan-- You should probably reference this draft in IO-RES if you still can. You will need to include the key deriviation details in your document (I'm assuming we use the first 24 bytes of keystring, with each 8 byte block adjusted for correct parity). I guess I'm yet another victim of "real job" work. Sorry this took so long. ben --------------------------- draft follows ---------------------------- IP Security Working Group B. Rogers Internet Draft Ascend Communications expires in six months 10. February 1998 Use of Block Ciphers for Message Authentication Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inapproporiate to use Internet Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet Draft, please check the "1id-abstracts.txt" listing contained in the Internet Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Australia), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This draft describes CBC-MAC, a method for using encryption functions to produce message authentication hashes. CBC-MAC can be used with any block cipher (eg. DES, 3DES, Blowfish) in combination with a secret key appropriate for that cipher. The cryptographic strength of this authentication depends on the strength of the algorithm, and may be influenced by other factors appropriate to the algorighm (eg. Weak Keys for DES). Introduction Providing a way to check the integrity of information transmitted over or stored in an unreliable medium is a prime necessity in the world of open computing and communications. Mechanisms that provide such integrity check based on a secret key are usually called "message authentication codes" (MAC). Typically, message authentication codes are used between two parties that share a secret key in order to validate information transmitted between these parties. A method for creating MACs using block ciphers has been well known to the cryptographic community for quite some time [Sch96]. However, Rogers expires in six months [Page 1] INTERNET DRAFT CBC-MAC February 1998 cryptographers tend to omit details necessary for programmers to produce interoperable implementations. This document is intended to provide those details. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. Notation b1^b2 This is the bitwise exclusive or of blocks `b1' and `b2'. These blocks are assumed to be the same length. e(k,b) This is the result of encrypting block `b' using algorithm `e' and key `k'. e-CBC-MAC(k,m) This is the authenticator produced by the CBC-MAC algorithm given the message `m' and the key `k'. In practice, `e' will be replaced by the name of a cipher (eg. 3DES-CBC-MAC). Definition of CBC-MAC CBC-MAC is defined with regards to a specific shared key block cipher (Such as DES, 3DES or Blowfish). It produces a message authenticator for arbitrary octet streams which can be verified by any entity sharing the key of the authenticator. The basic algorithm is only capable of authenticating messages which are an integral number of blocks in length. Thus, for a given cipher and message, the message must be tail-padded the the closest block boundary using all zeroes. Once this padding is done (producing m'), the message should be divided into sequential blocks P(0),...,P(n). The production of the authenticator can be described inductively: C(0) = e(k, P(0)) C(i+1) = e(k, P(i+1)^C(i)) The result e-CBC-MAC(k,m) is the result of C(n). Discussion The property we look for in a "good" message authentication code is that another party cannot create valid codes without knowing the shared secret key. In this case, we need only to show that it is Rogers expires in six months [Page 2] INTERNET DRAFT CBC-MAC February 1998 "difficult" to either discover information about the key, or to produce valid results without having the key. If these two properties hold, the MAC will be called strong. While it does not make sense to compare the strength of an encryption algorighm to that of an authentication algorithm, it can be shown that the strength of a CBC-MAC on fixed lenght messages will be dependent on the strength of the base cipher `e' [BKR94]. In fact, for fixed length messages, it has been proven that discovering information about the key, or producing invalid results without the key is at least as difficult as compromising the key, or generating arbitrary ciphertext-plaintext pairs within the given encryption algorithm. This is not the case for variable length messages. Certainly, the padding can be exploited to produce collisions in a trivial manner. [BKR94] shows that CBC-MAC can be compromized as well when the length of the message follows the message itself, assuming a system exists which will authenticate arbitrary messages. This problem can be addressed by prepending the length to the message. CBC-MAC will also serve well as a pseudo-random number generator, as it demonstrates the characteristics (distribution of entropy from the input string and irreversibility) we would like to see in such a function simply as a result of the same characteristics being evident in the underlying block cipher. References [BKR94] Bellare, M., J. Kilian and P. Rogaway., "The Security of Cipher Block Chaining", Advances in Cryptology - CRYPTO 94 Proceedings. [Sch96] Schneier, B., "Applied Cryptography, Protocols, Algorithms, and Source Code in C", 2nd edition. Author's Address Ben Rogers Ascend Communications 655 Metro Place South Suite 370 Dublin, OH 43017 Phone: (614) 760-4045 EMail: ben@ascend.com Rogers expires in six months [Page 3] From owner-ipsec Tue Feb 10 23:49:06 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA29980 for ipsec-outgoing; Tue, 10 Feb 1998 23:47:48 -0500 (EST) Message-Id: <3.0.3.32.19980211000023.0070ba90@pop.hq.tis.com> X-Sender: balenson@pop.hq.tis.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 11 Feb 1998 00:00:23 -0500 To: balenson@tis.com From: "David M. Balenson" Subject: REMINDER: ISOC 1998 Network and Distributed Security Symposium Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_887191223==_" Sender: owner-ipsec@ex.tis.com Precedence: bulk --=====================_887191223==_ Content-Type: text/plain; charset="us-ascii" Ok, now that I got your attention, here's the missing text ... --=====================_887191223==_ Content-Type: text/plain; charset="us-ascii" 1998 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM March 11-13, 1998 Catamaran Resort Hotel San Diego, California Sponsored by the Internet Society Program Chairs: Matt Bishop, University of California at Davis Steve Kent, BBN Technologies ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss98 EARLY REGISTRATION DISCOUNT DEADLINE: February 13, 1998 This 5th annual Symposium brings together researchers, implementers, and users of network and distributed system security technologies to discuss today's important security issues and challenges. The Symposium provides a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical and, to the extent possible, have been implemented. NDSS'98 fosters the exchange of technical information and encourages the Internet community to deploy available security technologies and develop new solutions to unsolved problems. KEYNOTE SPEAKER: Howard Gittleson, Director of the Internet Security Products Group at Bell Laboratories, Lucent Technologies THIS YEAR'S TOPICS INCLUDE: - Internet and Intranet security - Implementation issues for electronic commerce - All-optical networks security - Secure single login - Timestamping protocols - Remote password protocols - Mobile agent systems security - Java security - Trust management - Traffic analysis of TCP gateways - Secure bootstrapping - Firewalls and IP security NEW THIS YEAR! PRE-CONFERENCE TECHNICAL TUTORIALS: - Principles of Network Security (Dr. Stephen T. Kent, BBN Technologies) - Electronic Payment Systems (Dr. B. Clifford Neuman, USC/ISI) - Kerberos (Jeffrey I. Schiller, MIT) - Internet Security with Firewalls (Fred Avolio, TIS) - Web Security and Beyond (Dr. B. Clifford Neuman, USC/ISI) FOR MORE INFORMATION contact the Internet Society: Internet Society, 12020 Sunrise Valley Drive, Reston, VA, 20191 USA Phone: +1 703 648 9888 Fax: + 1 703 648 9887 E-mail: ndss98reg@isoc.org URL: http://www.isoc.org/ndss98/ SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Torryn P. Brazell at the Internet Society at +1 703 648 9888 or send e-mail to brazell@isoc.org. Sponsorship Chair: George Conrades, GTE Internetworking THE INTERNET SOCIETY is a non-governmental organization for global cooperation and coordination for the Internet and its internetworking technologies and applications. --=====================_887191223==_-- From owner-ipsec Tue Feb 10 23:56:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA00090 for ipsec-outgoing; Tue, 10 Feb 1998 23:56:45 -0500 (EST) Date: Wed, 11 Feb 1998 00:09:24 -0500 Message-Id: <199802110509.AAA26296@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ben@Ascend.COM Cc: ipsec@tis.com In-Reply-To: Ben Rogers's message of Tue, 10 Feb 1998 21:40:38 -0500 (EST), <199802110240.VAA06780@carp.morningstar.com> Subject: Re: Generic CBC-MAC specification Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Ben, Dan, I'm a bit confused why you feel we need a document to describe how to do generic CBC MAC's. Given that how you do DES MAC's and 3DES MAC's are relatively well understood and documented in books like Applied Cryptography, do we really need to have a document to describe this? Is there actually concern that 3DES MAC isn't well defined enough such that we can not unambiguously reference other standards or texts to define what we mean by this? - Ted From owner-ipsec Wed Feb 11 01:01:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA00474 for ipsec-outgoing; Wed, 11 Feb 1998 00:59:47 -0500 (EST) Message-Id: <199802110612.WAA18174@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: "Theodore Y. Ts'o" Cc: ben@Ascend.COM, ipsec@tis.com Subject: Re: Generic CBC-MAC specification In-Reply-To: Your message of "Wed, 11 Feb 1998 00:09:24 EST." <199802110509.AAA26296@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 10 Feb 1998 22:12:37 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk The I-O resolution draft currently references Applied Cryptography for CBC-MACs. That was said to be inadequate and I'm merely trying to address the criticism. If most people feel that Applied Cryptography is enough then I'll just leave it as it is. And I guess the burden is on those who think it isn't enough since this involves a change. Speak up now. Dan. > I'm a bit confused why you feel we need a document to describe > how to do generic CBC MAC's. Given that how you do DES MAC's and 3DES > MAC's are relatively well understood and documented in books like > Applied Cryptography, do we really need to have a document to describe > this? Is there actually concern that 3DES MAC isn't well defined enough > such that we can not unambiguously reference other standards or texts to > define what we mean by this? From owner-ipsec Wed Feb 11 07:25:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA02638 for ipsec-outgoing; Wed, 11 Feb 1998 07:21:45 -0500 (EST) Message-ID: <34E12C1F.E12B05D6@smtp.srv.gc.ca> Date: Tue, 10 Feb 1998 23:42:07 -0500 From: gagnonr@smtp.gc.ca (Gagnon Robert) Reply-To: Robert@tis.com, Gagnon@tis.com Organization: PWGSC X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: PKI(Entrust) & IPsec Content-Type: multipart/mixed; boundary="------------203473C2315A10734237623E" Sender: owner-ipsec@ex.tis.com Precedence: bulk This is a multi-part message in MIME format. --------------203473C2315A10734237623E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: PKI(Entrust) & IPsec Date: Tue, 10 Feb 1998 14:49:34 -0500 (Eastern Standard Time) From: Steve Coya To: Gagnon Robert CC: ietf-web@ns.ietf.org Robert, >>How do we consolidate the use of these two security mechanisms since the >>Government of Canada has standardized on PKI(Entrust) and most of our >>solution vendors are dealing with IPSEC? Do you have any suggestions on >>using these two technologies to provide non-repudiated VPN access for >>all forms of remote access(telework, clients, travellers, part-time >>home, etc)????? I believe the best place to send your query would be to the IPSEC WG email list: ipsec@tis.com Note that the IETF focuses on providing technical solutions to the community, but has no influence whatsoever on policy decisions, whether they be made by user groups, ISPs, of governments. Steve --------------203473C2315A10734237623E Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Robert Gagnon Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Robert Gagnon n: ;Robert Gagnon email;internet: gagnonr@smtp.srv.gc.ca x-mozilla-cpt: ;0 x-mozilla-html: FALSE version: 2.1 end: vcard --------------203473C2315A10734237623E-- From owner-ipsec Wed Feb 11 07:56:23 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA03293 for ipsec-outgoing; Wed, 11 Feb 1998 07:54:48 -0500 (EST) Date: Wed, 11 Feb 1998 15:12:46 +0200 (EET) From: Helger Lipmaa X-Sender: helger@keeks To: Daniel Harkins cc: "Theodore Y. Ts'o" , ben@Ascend.COM, ipsec@tis.com Subject: Re: Generic CBC-MAC specification In-Reply-To: <199802110612.WAA18174@dharkins-ss20.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Tue, 10 Feb 1998, Daniel Harkins wrote: > The I-O resolution draft currently references Applied Cryptography > for CBC-MACs. That was said to be inadequate and I'm merely trying > to address the criticism. If most people feel that Applied Cryptography > is enough then I'll just leave it as it is. And I guess the burden is > on those who think it isn't enough since this involves a change. "Applied Cryptography" is not enough for any RFC, but I already commented on this matter a long time ago and was ignored. Helger Lipmaa Cybernetica Ltd, senior research engineer; University of Tartu, PhD Student http://home.cyber.ee/helger; Phone +372-6542422 From owner-ipsec Wed Feb 11 08:02:12 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA03406 for ipsec-outgoing; Wed, 11 Feb 1998 08:00:46 -0500 (EST) Message-Id: <34E1A6A9.3403E81F@mitre.org> Date: Wed, 11 Feb 1998 08:24:58 -0500 From: "Brian W. McKenney" Reply-To: mckenney@mitre.org Organization: The MITRE Corporation X-Mailer: Mozilla 4.04 [en] (Win95; U) Mime-Version: 1.0 To: Robert@tis.com, Gagnon@tis.com Cc: ipsec@tis.com Subject: Re: PKI(Entrust) & IPsec References: <34E12C1F.E12B05D6@smtp.srv.gc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Entrust is working with VPN vendors and has released the EntrustIPSEC Negotiator Toolkit (variant of Entrust/Toolkit). As a result, IPsec vendors that want to plug-in to the Entrust infrastructure are required to conform to this toolkit (high level interface). I also saw a recent announcement that GTE CyberTrust is also working with VPN vendors. Check out: http://www.entrust.com/toolkit/entrustipsec.htm Brian -- Brian W. McKenney The MITRE Corporation 1820 Dolley Madison Blvd. McLean, VA 22102 http://www.mitre.org From owner-ipsec Wed Feb 11 08:06:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA03468 for ipsec-outgoing; Wed, 11 Feb 1998 08:04:46 -0500 (EST) Date: Wed, 11 Feb 1998 08:15:25 -0500 From: "Freedman, Jerome" Subject: RE: Discovery of tunnel server from ISP POP To: Stephen Waters , "Michael C. Richardson" Cc: ipsec@tis.com Message-id: <8D3B7E46799CCF118D9D00805FE28A1E030873AD@ndhm06.ndhm.gtegsc.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-type: text/plain Content-transfer-encoding: 7BIT X-Priority: 3 Sender: owner-ipsec@ex.tis.com Precedence: bulk We do security gateway discovery with a home made protocol. Since it is homemade and ad hoc too, we'd love to discuss the issue in depth. Having said that, the mechanism we use is similar to what is decribed here >but IPv6 suggests it isn't an issue), then it may also be reasonable to send >an ICMP message (an echo) to the desired end node, and watch for an ICMP >admin denied message coming back. (One could even just transmit the TCP SYN, >but that may be more information than one desires to reveal in the >clear. Another option is to send an ISAKMP initiator message) > >It would come back from security gateway. If one had sent an ISAKMP >message, that might be a signal to the gateway to initiate an ISAKMP with >the end node. Given appropriate certificates presented by the client and >gateway to establish that each is authorized to speak for their respective >entities (users on the client, networks on gateway), then the gateway >discovery is done. I don't believe that the discovery should be tied to ISAKMP - the document itself is already huge and there are and maybe other key management exchange protocols. Jerry Freedman,Jr GTE Gov't Systems From owner-ipsec Wed Feb 11 09:10:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA03916 for ipsec-outgoing; Wed, 11 Feb 1998 09:07:48 -0500 (EST) Date: Wed, 11 Feb 1998 09:17:06 -0600 (CST) From: Engineering To: Robert@tis.com, Gagnon@tis.com cc: ipsec@tis.com Subject: Re: PKI(Entrust) & IPsec In-Reply-To: <34E12C1F.E12B05D6@smtp.srv.gc.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk We are combining PKI and IPSEC support into our product. Jeffrey Goodwin ** Ashley Laurent,Inc. ** Software Development ** Consulting ** * * * * 707 West Avenue, Suite 201 * voice: 512-322-0676 * * Austin, Texas 78701 * fax : 512-322-0680 * * web: http://www.osgroup.com * * Microsoft Solution Provider * Complete Systems Design/Development * * Novell Professional Developer * Systems Software/Device Drivers * On Tue, 10 Feb 1998, Gagnon Robert wrote: > Subject: > Re: PKI(Entrust) & IPsec > Date: > Tue, 10 Feb 1998 14:49:34 -0500 (Eastern Standard Time) > From: > Steve Coya > To: > Gagnon Robert > CC: > ietf-web@ns.ietf.org > > > > > Robert, > > > >>How do we consolidate the use of these two security mechanisms since > the > >>Government of Canada has standardized on PKI(Entrust) and most of our > >>solution vendors are dealing with IPSEC? Do you have any suggestions > on > >>using these two technologies to provide non-repudiated VPN access for > >>all forms of remote access(telework, clients, travellers, part-time > >>home, etc)????? > > I believe the best place to send your query would be to the IPSEC WG > email list: ipsec@tis.com > > Note that the IETF focuses on providing technical solutions to the > community, but has no influence whatsoever on policy decisions, whether > they be made by user groups, ISPs, of governments. > > > Steve > > > > > > > From owner-ipsec Wed Feb 11 09:40:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA04190 for ipsec-outgoing; Wed, 11 Feb 1998 09:38:47 -0500 (EST) Date: Wed, 11 Feb 1998 09:51:27 -0500 (EST) Message-Id: <199802111451.JAA08590@carp.morningstar.com> From: Ben Rogers To: Daniel Harkins Cc: "Theodore Y. Ts'o" , ipsec@tis.com Subject: Re: Generic CBC-MAC specification In-Reply-To: <199802110612.WAA18174@dharkins-ss20.cisco.com> References: <199802110509.AAA26296@dcl.MIT.EDU> <199802110612.WAA18174@dharkins-ss20.cisco.com> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Daniel Harkins writes: > The I-O resolution draft currently references Applied Cryptography > for CBC-MACs. That was said to be inadequate and I'm merely trying > to address the criticism. If most people feel that Applied Cryptography > is enough then I'll just leave it as it is. And I guess the burden is > on those who think it isn't enough since this involves a change. > > Speak up now. I was the one to convince Dan that Applied Cryptography was not sufficient for RFC purposes. (I was bothered because it was not free, and no one could point me to a free specification.) The biggest point, however, is that AC does not make any mention of a standard method for padding short input frames, which I made certain to do in my draft. Moreover, there is not an adequate discussion of the security implications of using CBC-MAC as a MAC (which I hope I've addressed sufficiently in the discussion section of that draft). Does anyone disagree with my rationale for another draft? ben From owner-ipsec Wed Feb 11 12:25:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA05218 for ipsec-outgoing; Wed, 11 Feb 1998 12:17:54 -0500 (EST) Date: Wed, 11 Feb 1998 12:30:23 -0500 Message-Id: <199802111730.MAA26425@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ben@Ascend.COM Cc: Daniel Harkins , "Theodore Y. Ts'o" , ipsec@tis.com In-Reply-To: Ben Rogers's message of Wed, 11 Feb 1998 09:51:27 -0500 (EST), <199802111451.JAA08590@carp.morningstar.com> Subject: Re: Generic CBC-MAC specification Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk In general, I don't believe we should compete with Applied Cryptography; we don't need to provide tutorial information about the definition of CBC, Public Key Crypto, how to quickly find prime numbers, and host of other background information. As far as needing a definition for CBC-MAC's, I would suggest that the most appropriate reference would be FIPS-81. This document defines modes of operations for DES, including CBC-MAC (which is defined in Appendix F of FIPS-81). The I-O resolution draft needs to use 3-DES CBC-MAC, but the description in sufficiently general the extension of FIPS-81 to 3-DES should be self-explanatory enough to not be a problem. FIPS is standards document, and it's freely available on the web from the U.S. Government. For example: at the URL http://www.itl.nist.gov/div897/pubs/fip81.htm Ben, the text which you wrote is not bad text, and I think it's useful to have a collection of tutorial texts, linked of a web page, which explain necessary background material. The problem with making it standards track material is that it makes the standards even bigger, and it's additional text that we have to proof-read, and worry about problems if we miss some error in the text. - Ted From owner-ipsec Wed Feb 11 13:06:40 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA05550 for ipsec-outgoing; Wed, 11 Feb 1998 13:05:53 -0500 (EST) Message-Id: <199802111816.NAA06439@relay.hq.tis.com> To: ben@Ascend.COM (Ben Rogers) cc: Daniel Harkins , "Theodore Y. Ts'o" , ipsec@tis.com Subject: Re: Generic CBC-MAC specification In-reply-to: Your message of "Wed, 11 Feb 1998 09:51:27 EST." <199802111451.JAA08590@carp.morningstar.com> Date: Wed, 11 Feb 1998 10:17:19 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk >Does anyone disagree with my rationale for another draft? Yes, I disagree. As Ted pointed out, it's relatively well understood how to generate CBC MAC's. In addition, introducing another document dependency for IPSEC is unnecessary and bordering on the absurd. There's already way too many documents describing this protocol. We need these documents to go to RFC, now. We can always revise the RFC later. It's much more dangerous to have folks shipping products that are written to ID's. I want to ship a product based on an RFC, not an ID. Derrell From owner-ipsec Wed Feb 11 14:55:24 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA06322 for ipsec-outgoing; Wed, 11 Feb 1998 14:53:55 -0500 (EST) Message-ID: From: Roy Pereira To: "'Robert@tis.com'" , "'ipsec@tis.com'" Subject: RE: PKI(Entrust) & IPsec Date: Wed, 11 Feb 1998 15:32:41 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Entrust's PKI and IPSec are complementary technologies. TimeStep, among others, have implemented support for Entrust's PKI within our IPSec product suite. >>>How do we consolidate the use of these two security mechanisms since >the >>>Government of Canada has standardized on PKI(Entrust) and most of our >>>solution vendors are dealing with IPSEC? Do you have any suggestions >on >>>using these two technologies to provide non-repudiated VPN access for >>>all forms of remote access(telework, clients, travellers, part-time >>>home, etc)????? > From owner-ipsec Wed Feb 11 15:09:52 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA06458 for ipsec-outgoing; Wed, 11 Feb 1998 15:08:59 -0500 (EST) Message-ID: <021901bd372a$e0dbd7a0$692068c0@rock105.FrontierTech.com> From: "Ray Langford" To: , Cc: Subject: Re: PKI(Entrust) & IPsec Date: Wed, 11 Feb 1998 14:23:12 -0600 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0216_01BD36F8.95F6A300" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@ex.tis.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0216_01BD36F8.95F6A300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Frontier Technologies' e-Lock IPSec Toolkit supports IPSec and PKI and we are working with VPN vendors. The e-Lock IPSec Toolkit provides ISAKMP and PKIX based PKI services for IPSec vendors which allows them to work with almost any CA and Public Key Infrastructure. More information about e-Lock PKI and VPN solutions is available at the e-Lock web site, www.e-Lock.com. -----Original Message----- From: Gagnon Robert To: ipsec@tis.com Date: Wednesday, February 11, 1998 7:26 AM Subject: PKI(Entrust) & IPsec >Subject: > Re: PKI(Entrust) & IPsec > Date: > Tue, 10 Feb 1998 14:49:34 -0500 (Eastern Standard Time) > From: > Steve Coya > To: > Gagnon Robert > CC: > ietf-web@ns.ietf.org > > > > >Robert, > > >>>How do we consolidate the use of these two security mechanisms since >the >>>Government of Canada has standardized on PKI(Entrust) and most of our >>>solution vendors are dealing with IPSEC? Do you have any suggestions >on >>>using these two technologies to provide non-repudiated VPN access for >>>all forms of remote access(telework, clients, travellers, part-time >>>home, etc)????? > >I believe the best place to send your query would be to the IPSEC WG >email list: ipsec@tis.com > >Note that the IETF focuses on providing technical solutions to the >community, but has no influence whatsoever on policy decisions, whether >they be made by user groups, ISPs, of governments. > > >Steve > > > > > > > ========================================== Ray C. Langford Director of Research and Development Frontier Technologies Corp. Email: Ray@FrontierTech.com Voice: (414) 241-4555 x205 ========================================== ------=_NextPart_000_0216_01BD36F8.95F6A300 Content-Type: text/x-vcard; name="Ray Langford.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Ray Langford.vcf" BEGIN:VCARD VERSION:2.1 N:Langford;Ray FN:Ray Langford ORG:Frontier Technologies Corporation TITLE:Director of Research and Development TEL;WORK;VOICE:(414) 241-4555 x205 TEL;WORK;FAX:(414) 241-7084 ADR;WORK:;;10201 N. Port Washington Rd.;Mequon;WI;53092;US LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:10201 N. Port Washington = Rd.=3D0D=3D0AMequon, WI 53092=3D0D=3D0AUS URL: URL:http://www.frontiertech.com EMAIL;PREF;INTERNET:Ray@FrontierTech.com REV:19980211T202312Z END:VCARD ------=_NextPart_000_0216_01BD36F8.95F6A300-- From owner-ipsec Wed Feb 11 18:38:11 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA07838 for ipsec-outgoing; Wed, 11 Feb 1998 18:36:03 -0500 (EST) Date: Wed, 11 Feb 1998 18:44:46 -0600 (CST) From: Engineering To: ipsec@tis.com Subject: March 2nd Meeting at Raliegh Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, we're interested in doing some pre-interoperability testing with 5 IPSEC hardware gateway vendors, before the March 2nd worshop. We're already supporting most of the transforms in the DOI, and have done some interoperability testing already, but would like to work with more vendors now. We have a Windows 95 and Windows NT IPSEC BITS client. Also, an NT IPSEC Gateway. Please respond to jeffg@osgroup.com Thanks, Jeffrey Goodwin ** Ashley Laurent,Inc. ** Software Development ** Consulting ** * * * * 707 West Avenue, Suite 201 * voice: 512-322-0676 * * Austin, Texas 78701 * fax : 512-322-0680 * * web: http://www.osgroup.com * * Microsoft Solution Provider * Complete Systems Design/Development * * Novell Professional Developer * Systems Software/Device Drivers * From owner-ipsec Thu Feb 12 02:40:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA10589 for ipsec-outgoing; Thu, 12 Feb 1998 02:38:08 -0500 (EST) Date: Thu, 12 Feb 1998 02:50:37 -0500 From: hugh@mimosa.com ("D. Hugh Redelmeier") Message-Id: <199802120750.CAA22891@mimosa.com> To: ipsec@tis.com Subject: confusion about identity Sender: owner-ipsec@ex.tis.com Precedence: bulk I am trying to understand identity payload in ISAKMP, Oakley, and their combination. These are some notes from this exercise. The documents use several not-quite-identical terms that I'm reading as equivalent: Identification Payload, ID payload, and identity payload. Is there an important difference? If not, I suggest that a single term be used everywhere. draft-ietf-ipsec-isakmp-oakley-05.txt, section 5 "Exchanges" says the following (I quote a fair bit to give context, but you needn't read it to get my point): To authenticate either exchange the initiator of the protocol generates HASH_I and the responder generates HASH_R where: HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b ) HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b ) For authentication with digital signatures, HASH_I and HASH_R are signed and verified; for authentication with either public key encryption or pre-shared keys, HASH_I and HASH_R directly authenticate the exchange. The entire ID payload (including ID type, port, and protocol but excluding the generic header) is hashed into both HASH_I and HASH_R. The first word of the second last line is the only use of the word "port" in the document. As such, it seems out of place. I find port mentioned in draft-ietf-ipsec-ipsec-doi-06.txt, section 4.6.2 "Identification Payload Content". Port is recorded in a field that is marked as "reserved" (and hence required to be zero) in draft-ietf-ipsec-isakmp-08.txt section 3.8 "Identification Payload". This conflict looks serious to me: one or the other document should be altered. In describing port, 4.6.2 of draft-ietf-ipsec-ipsec-doi-06.txt says: During Phase I negotiations, the ID port and protocol fields MUST be set to zero or to UDP port 500. If an implementation receives any other values, this MUST be treated as an error and the security association setup MUST be aborted. This event SHOULD be auditable. The only time we use HASH_I and HASH_R (described in the long quote above) is during phase 1. I wonder why one would put UDP port 500 here when it causes a contradiction between the documents and yields no useful information (as far as I can tell). This draft-ietf-ipsec-isakmp-oakley-05.txt section 5.4 says the following, which does not address the issue but may be relevant: When using pre-shared key authentication with Main Mode the key can only be identified by the IP address of the peers since HASH_I must be computed before the initiator has processed IDir. Aggressive Mode allows for a wider range of identifiers of the pre-shared secret to be used. In addition, Aggressive Mode allows two parties to maintain Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253 From owner-ipsec Thu Feb 12 03:31:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA10942 for ipsec-outgoing; Thu, 12 Feb 1998 03:31:09 -0500 (EST) Message-ID: <34E2B64C.794B@cs.umass.edu> Date: Thu, 12 Feb 1998 03:43:56 -0500 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha) MIME-Version: 1.0 To: "D. Hugh Redelmeier" CC: IP Security List Subject: Re: confusion about identity References: <199802120750.CAA22891@mimosa.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk D. Hugh Redelmeier writes: > draft-ietf-ipsec-isakmp-oakley-05.txt, section 5 "Exchanges" says the > following (I quote a fair bit to give context, but you needn't read > it to get my point): [...elided...] > authenticate the exchange. The entire ID payload (including ID type, > port, and protocol but excluding the generic header) is hashed into > both HASH_I and HASH_R. > > The first word of the second last line is the only use of the word > "port" in the document. As such, it seems out of place. I don't see your point here. Enumerating the fields of the ID payload seems a good way to elaborate on the intended meaning of "entire ID payload". "Port" is certainly an appropriate term to use to name one of those fields. I fail to understand why the uniqueness of the word in the document renders it "out of place". -Lewis From owner-ipsec Thu Feb 12 03:49:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA11044 for ipsec-outgoing; Thu, 12 Feb 1998 03:48:09 -0500 (EST) Message-Id: <199802120859.RAA27758@isl.rdc.toshiba.co.jp> To: ipsec@tis.com Subject: Re: Generic CBC-MAC specification In-reply-to: ben's message of "Tue, 10 Feb 1998 21:40:38 EST." <199802110240.VAA06780@carp.morningstar.com> Date: Thu, 12 Feb 1998 17:59:36 +0900 From: FUKUMOTO Atsushi Sender: owner-ipsec@ex.tis.com Precedence: bulk Only description I could find about CBC-MAC in "Applied Cryptography 2nd ed." (first print) is in p.456, where it says: [...] encrypt a message with a block algorithm in CBC or CFB modes. The hash is the last encrypted block, encrypted once more in CBC or CFB modes. This last line, "encrypted once more in CBC or CFB modes", seems to be different from FIPS81 Appendix F, or Mr.Rogers' CBC-MAC draft. So my question is, am I right that the description of Applied Cryptography is wrong, and the "encrypted once more" should only be applied to CFB mode? FUKUMOTO Atsushi fukumoto@isl.rdc.toshiba.co.jp From owner-ipsec Thu Feb 12 07:09:01 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA12235 for ipsec-outgoing; Thu, 12 Feb 1998 07:07:10 -0500 (EST) Date: Thu, 12 Feb 1998 11:44:14 +0000 (GMT) From: George Tsirtsis To: Stephen Waters Cc: ipsec@tis.com Subject: Re: Discovery of tunnel server from ISP POP In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64CF523EE@wade.reo.dec.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Tue, 10 Feb 1998, Stephen Waters wrote: > > A number of short-comings are leveled at IPSEC regarding address > assignment mechanisms. The DHCP+ISAKMP draft covers the allocation of > an Intranet address, but how does an IPSEC client discover the Internet > address of the IPSEC Security Gateway? Sure, this is a problem. > > In the L2TP model, the tunnel is connected by the ISP 'LAC' once the > client has been authenticated via PPP PAP/CHAP. The LAC knows where the > appropriate tunnel end-point is. > > For IPSEC, could the ISP also offer security gateway address resolution? > For example, an extension to the PPP IPCP NCP could allow the ISP to > deliver the Internet address of the IPSEC security Gateway for a given > client (identified in the same way, PAP/CHAP). Ideally, this support > would allow a list of addresses to be supplied in a similar way to the > passing of Primary and Secondary DNS servers via IPCP. This would allow > the client to re-connect should a primary server fail or become > unreachable. > > Is this worth a (very short) draft proposing an extension to IPCP? > Since this exchange provides Internet addresses, is there any need to > protect/encrypt this information? If there is, then things start to get > messy (arranging encrypted sessions with the ISP POP). The L2TP LAC > model avoids this sticky issue of IPCP exchanges in the clear since PPP > encryption has picked in with the tunnel server by the time IPCP > starts-up. > This might be worth doing. You may want to run this idea through the pppext WG? Anyway, I do not see how this helps you with the DHCP+ISAKMP draft. An extension to IPCP in the way you propose may benefit L2TP tunneling since PPP (and IPCP) run on top of it. I do not see how this helps IPSEC! Do I miss something? Also, I think you are on the wrong side of the network, the DHCP+ISAKMP draft talks about a host on the Internet trying to enter an Intranet *though it could work the other way around). You are talking about accessing an ISP and the ISP to provide you with the address of the secure gateway. What you propose might be worthwile; I just try to clarify what it solves. > Regards, Steve. Thanks George ----------------------------- Internet Transport Research | BTLABS | -------------------------------------------------------------------------- Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of British Telecommunications plc. -------------------------------------------------------------------------- From owner-ipsec Thu Feb 12 09:00:12 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA13062 for ipsec-outgoing; Thu, 12 Feb 1998 08:58:09 -0500 (EST) Message-Id: <199802121404.AA07399@mailfw2.ford.com> From: "Krishnan Subramaniam" Date: Thu, 12 Feb 1998 09:04:07 -0500 X-Mailer: Z-Mail (3.2.1 15feb95) To: ipsec@tis.com Subject: Help - Details on March 2nd worshop at Raliegh requested ... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@ex.tis.com Precedence: bulk Would some one let me know, where I can find more information on the Raleigh meeting? Thanks in advance Regards ks From owner-ipsec Thu Feb 12 11:03:15 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA13937 for ipsec-outgoing; Thu, 12 Feb 1998 11:00:12 -0500 (EST) Message-Id: <199802121610.LAA13370@relay.hq.tis.com> To: hugh@mimosa.com ("D. Hugh Redelmeier") cc: ipsec@tis.com Subject: Re: confusion about identity In-reply-to: Your message of "Thu, 12 Feb 1998 02:50:37 EST." <199802120750.CAA22891@mimosa.com> Date: Thu, 12 Feb 1998 08:12:19 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk Greetings, > The documents use several not-quite-identical terms that I'm reading > as equivalent: Identification Payload, ID payload, and identity > payload. Is there an important difference? If not, I suggest that > a single term be used everywhere. They're the same. > draft-ietf-ipsec-isakmp-oakley-05.txt, section 5 "Exchanges" says the > following (I quote a fair bit to give context, but you needn't read > it to get my point): > > To authenticate either exchange the initiator of the protocol > generates HASH_I and the responder generates HASH_R where: > > HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b ) > HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b ) > > For authentication with digital signatures, HASH_I and HASH_R are > signed and verified; for authentication with either public key > encryption or pre-shared keys, HASH_I and HASH_R directly > authenticate the exchange. The entire ID payload (including ID type, > port, and protocol but excluding the generic header) is hashed into > both HASH_I and HASH_R. > > The first word of the second last line is the only use of the word > "port" in the document. As such, it seems out of place. There are a few places when the ISAKMP/Oakley Resolution document is specific to the IPSEC DOI, and this is one of them. I suppose this statement really belongs in the IPSEC DOI, or else the IO Resolution should qualify this with, "For SA's negotiated under the IPSEC DOI, ..." However, we tried to keep all of the key agreement/key exchange protocol self-contained in one document and the IO Resolution is clearly the place for this. It's clearly important to include the full IPSEC DOI ID payloads in the hash calculations. > I find port mentioned in draft-ietf-ipsec-ipsec-doi-06.txt, section > 4.6.2 "Identification Payload Content". Port is recorded in a field > that is marked as "reserved" (and hence required to be zero) in > draft-ietf-ipsec-isakmp-08.txt section 3.8 "Identification Payload". > This conflict looks serious to me: one or the other document should > be altered. The ISAKMP document also says: 3.8 Identification Payload The Identification Payload contains DOI-specific data used to exchange identification information. For the IPSEC DOI, the format is as defined in the IPSEC DOI. For other DOI's, the ID Payload would be defined in the relevant DOI document. For ISAKMP Phase I negotiations, the format is as defined in the ISAKMP document. Having written that, I agree with your next point, that the text in the existing DOI document is bogus... To wit, > In describing port, 4.6.2 of draft-ietf-ipsec-ipsec-doi-06.txt says: > > During Phase I negotiations, the ID port and protocol fields MUST be > set to zero or to UDP port 500. If an implementation receives any > other values, this MUST be treated as an error and the security > association setup MUST be aborted. This event SHOULD be auditable. > The only time we use HASH_I and HASH_R (described in the long quote > above) is during phase 1. I wonder why one would put UDP port 500 > here when it causes a contradiction between the documents and yields > no useful information (as far as I can tell). I added this to the IPSEC DOI document following the Ottawa IPSEC bake-off because there were several vendors sending Port 500 in the Phase I Main Mode exchange. I guess that was a mistake on my part. You're right though and unless there are objections raised ASAP, I'll remove it from the next draft. It really doesn't add anything to have Port 500 included in the hash. > Hugh Redelmeier > hugh@mimosa.com voice: +1 416 482-8253 Hey, thanks for taking the time to read the documents and write-up your comments! Derrell From owner-ipsec Thu Feb 12 12:55:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14836 for ipsec-outgoing; Thu, 12 Feb 1998 12:52:19 -0500 (EST) Message-Id: <199802121804.KAA20325@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: "Krishnan Subramaniam" Cc: ipsec@tis.com Subject: Re: Help - Details on March 2nd worshop at Raliegh requested ... In-Reply-To: Your message of "Thu, 12 Feb 1998 09:04:07 EST." <199802121404.AA07399@mailfw2.ford.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Feb 1998 10:04:56 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Contact Stu Phillips (stuphill@cisco.com) for when, where, and how. If you have a what sort of questions I could probably help you. Stu did post info to this mailing list, though, so perhaps your first step would be to search the archives back about a week. Dan. > Would some one let me know, where I can find more information > on the Raleigh meeting? From owner-ipsec Thu Feb 12 12:55:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14845 for ipsec-outgoing; Thu, 12 Feb 1998 12:53:15 -0500 (EST) Message-Id: <3.0.5.32.19980212130330.00a137c0@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 12 Feb 1998 13:03:30 -0500 To: "Theodore Y. Ts'o" , ben@Ascend.COM From: Robert Moskowitz Subject: Re: Generic CBC-MAC specification Cc: Daniel Harkins , "Theodore Y. Ts'o", ipsec@tis.com In-Reply-To: <199802111730.MAA26425@dcl.MIT.EDU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 12:30 PM 2/11/98 -0500, Theodore Y. Ts'o wrote: > >As far as needing a definition for CBC-MAC's, I would suggest that the >most appropriate reference would be FIPS-81. This document defines >modes of operations for DES, including CBC-MAC (which is defined in >Appendix F of FIPS-81). The I-O resolution draft needs to use 3-DES >CBC-MAC, but the description in sufficiently general the extension of >FIPS-81 to 3-DES should be self-explanatory enough to not be a problem. > Ted's pointing to a FIPS document is a sound solution here. If this gives us what we need, that is one less RFC for IPsec. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Thu Feb 12 12:55:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14834 for ipsec-outgoing; Thu, 12 Feb 1998 12:52:14 -0500 (EST) Message-Id: <3.0.5.32.19980212130034.009ff830@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 12 Feb 1998 13:00:34 -0500 To: Daniel Harkins , "Theodore Y. Ts'o" From: Robert Moskowitz Subject: Re: Generic CBC-MAC specification Cc: ben@Ascend.COM, ipsec@tis.com In-Reply-To: <199802110612.WAA18174@dharkins-ss20.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:12 PM 2/10/98 -0800, Daniel Harkins wrote: > The I-O resolution draft currently references Applied Cryptography >for CBC-MACs. That was said to be inadequate and I'm merely trying >to address the criticism. If most people feel that Applied Cryptography >is enough then I'll just leave it as it is. And I guess the burden is >on those who think it isn't enough since this involves a change. > I might point out that draft-bitan-auth-des-mac-00.txt references the DES-MAC algorithm from: [Kaufman95] Kaufman, C., Perlman, R. and Speciner, M., "Network Security: Private Communication in a Public World", PTR Prentice Hall, Englewood Cliffs, New Jersey, 1995. ISBN 0-13-061466-1 Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Thu Feb 12 13:04:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA14952 for ipsec-outgoing; Thu, 12 Feb 1998 13:04:13 -0500 (EST) Message-Id: <199802121816.KAA20355@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: "Derrell D. Piper" Cc: hugh@mimosa.com ("D. Hugh Redelmeier"), ipsec@tis.com Subject: Re: confusion about identity In-Reply-To: Your message of "Thu, 12 Feb 1998 08:12:19 PST." <199802121610.LAA13370@relay.hq.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Feb 1998 10:16:36 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk > > During Phase I negotiations, the ID port and protocol fields MUST be > > set to zero or to UDP port 500. If an implementation receives any > > other values, this MUST be treated as an error and the security > > association setup MUST be aborted. This event SHOULD be auditable. > > > The only time we use HASH_I and HASH_R (described in the long quote > > above) is during phase 1. I wonder why one would put UDP port 500 > > here when it causes a contradiction between the documents and yields > > no useful information (as far as I can tell). > > I added this to the IPSEC DOI document following the Ottawa IPSEC bake-off > because there were several vendors sending Port 500 in the Phase I Main Mode > exchange. I guess that was a mistake on my part. You're right though and > unless there are objections raised ASAP, I'll remove it from the next draft. > It really doesn't add anything to have Port 500 included in the hash. The port and protocol aren't all that critical but the ID type which is on the same 4 octet portion of the payload as the port and protocol is. So let's leave the hash the way it is. Now what do we put in these fields then? The DOI of an SA offer in phase I is either IPSec DOI or zero. If it's IPSec DOI then the port and protocol have relevance and I don't see why someone who wants to can't put UDP port 500 in there. If it's DOI of zero then the semantics of the ID payload are that of the base ISAKMP draft (which, it was noted at the document reading party, does not define any ID types, that should be taken care of in the next round of edits) and then the port and protocol really must be RESERVED or zero. That humming sound you hear is me: "let's leave it alone". Dan. From owner-ipsec Thu Feb 12 13:11:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA15017 for ipsec-outgoing; Thu, 12 Feb 1998 13:11:13 -0500 (EST) Message-Id: <199802121825.NAA29954@relay.rv.tis.com> To: Daniel Harkins cc: hugh@mimosa.com ("D. Hugh Redelmeier"), ipsec@tis.com Subject: Re: confusion about identity In-reply-to: Your message of "Thu, 12 Feb 1998 10:16:36 PST." <199802121816.KAA20355@dharkins-ss20.cisco.com> Date: Thu, 12 Feb 1998 10:23:20 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk >Now what do we put in these fields then? The DOI of an SA offer in phase I >is either IPSec DOI or zero. If it's IPSec DOI then the port and protocol >have relevance and I don't see why someone who wants to can't put UDP port >500 in there. If it's DOI of zero then the semantics of the ID payload are >that of the base ISAKMP draft (which, it was noted at the document reading >party, does not define any ID types, that should be taken care of in the >next round of edits) and then the port and protocol really must be RESERVED >or zero. I'd forgotten you added that new blurb in the IO Resolution. Okay, I'll leave it as is. Derrell From owner-ipsec Thu Feb 12 14:31:48 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA15554 for ipsec-outgoing; Thu, 12 Feb 1998 14:30:17 -0500 (EST) Date: Thu, 12 Feb 1998 14:42:35 -0500 From: hugh@mimosa.com ("D. Hugh Redelmeier") Message-Id: <199802121942.OAA23824@mimosa.com> To: ddp@network-alchemy.com, lmccarth@cs.umass.edu Cc: ipsec@tis.com Subject: Re: confusion about identity Sender: owner-ipsec@ex.tis.com Precedence: bulk I wrote: | draft-ietf-ipsec-isakmp-oakley-05.txt, section 5 "Exchanges" says the | following (I quote a fair bit to give context, but you needn't read | it to get my point): | | To authenticate either exchange the initiator of the protocol | generates HASH_I and the responder generates HASH_R where: | | HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b ) | HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b ) | | For authentication with digital signatures, HASH_I and HASH_R are | signed and verified; for authentication with either public key | encryption or pre-shared keys, HASH_I and HASH_R directly | authenticate the exchange. The entire ID payload (including ID type, | port, and protocol but excluding the generic header) is hashed into | both HASH_I and HASH_R. | | The first word of the second last line is the only use of the word | "port" in the document. As such, it seems out of place. Lewis responded: | I don't see your point here. Enumerating the fields of the ID payload | seems a good way to elaborate on the intended meaning of "entire ID | payload". "Port" is certainly an appropriate term to use to name one | of those fields. I fail to understand why the uniqueness of the word | in the document renders it "out of place". and Derrell also responded: | There are a few places when the ISAKMP/Oakley Resolution document is specific | to the IPSEC DOI, and this is one of them. I suppose this statement really | belongs in the IPSEC DOI, or else the IO Resolution should qualify this with, | "For SA's negotiated under the IPSEC DOI, ..." However, we tried to keep all | of the key agreement/key exchange protocol self-contained in one document and | the IO Resolution is clearly the place for this. It's clearly important to | include the full IPSEC DOI ID payloads in the hash calculations. As a newbie struggling with the relationships between the documents, I would have been helped by hints such as Derrell mentioned. He says that there are a few such places. I would be helped by flagging each of them. I suggest rewording the following part: The entire ID payload (including ID type, port, and protocol but excluding the generic header) is hashed into both HASH_I and HASH_R. to something like: The entire Identification Payload excluding the generic header (and including ID type, and any DOI-specific fields such as port and protocol for the IPSEC DOI) is hashed into both HASH_I and HASH_R. - I've changed "ID payload" to "Identification Payload" for consistency - I've moved "excluding the generic header" outside the parentheses since it is not parenthetical. - I've made explicit that all DOI-specific stuff is included. I am presuming that this is the original intent, but I am not 100% sure that this makes sense in phase 1. I'm not saying it is wrong, just that I don't understand all the implications (if any). - I've identified the port and protocol fields as DOI specific. Later, I said: | I find port mentioned in draft-ietf-ipsec-ipsec-doi-06.txt, section | 4.6.2 "Identification Payload Content". Port is recorded in a field | that is marked as "reserved" (and hence required to be zero) in | draft-ietf-ipsec-isakmp-08.txt section 3.8 "Identification Payload". | This conflict looks serious to me: one or the other document should | be altered. Derrell responded: | The ISAKMP document also says: | | 3.8 Identification Payload | | | The Identification Payload contains DOI-specific data used to exchange | identification information. | | For the IPSEC DOI, the format is as defined in the IPSEC DOI. For other | DOI's, the ID Payload would be defined in the relevant DOI document. For | ISAKMP Phase I negotiations, the format is as defined in the ISAKMP document. This I find more problematic. draft-ietf-ipsec-isakmp-08.txt clearly states: 2.5.2 RESERVED Fields The existence of RESERVED fields within ISAKMP payloads are used strictly to preserve byte alignment. All RESERVED fields in the ISAKMP protocol MUST be set to zero (0) when a packet is issued. The receiver SHOULD check the RESERVED fields for a zero (0) value and discard the packet if other values are found. I think that all IPSEC DOI conforming systems will violate this ISAKMP rule! Section 3.8 states that the DOI-specific stuff goes in the Identification Data variable-length field (and make no provision elsewhere, except perhaps for the ID Type field). It seems quite wrong to use the payload identifier assigned for an ISAKMP Identification Payload and violate the format specified. One right approach would be to assign a DOI-specific identifier for the IPSEC DOI Identification Payload. It is much to late to evict the port and protocol fields from the IPSEC DOI version of the Identification Payload. The fix that I strongly recommend is that section 3.8 of draft-ietf-ipsec-isakmp-08.txt be reworded to change the RESERVED2 field to a DOI-specific field. I doubt that this word hurt anybody. Summary: I think a simple fix to ISAKMP will make everything right without breaking anything. I infer that this captures the original intent. Derrell also responded | I added this to the IPSEC DOI document following the Ottawa IPSEC bake-off | because there were several vendors sending Port 500 in the Phase I Main Mode | exchange. I guess that was a mistake on my part. You're right though and | unless there are objections raised ASAP, I'll remove it from the next draft. | It really doesn't add anything to have Port 500 included in the hash. I think that the changes I suggested above would together require the Port field to be filled properly, not left zero. A change in their logic (which may or may not be a good thing) would be required to allow zero. Do we wish to specify here that the port is 500? Although that is the normal port, I play with ISAKMP OAKLEY on other ports for various reasons. This is really two points: the 500 is specified elsewhere, and I don't think it should be redundantly embedded in this place. Furthermore, if an implementation happens to support other ports, surely the port being used should appear here, not 500. Thanks for your attention. I'm sorry to be so pedantic, but I think that good standards require this. Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253 From owner-ipsec Thu Feb 12 14:35:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA15605 for ipsec-outgoing; Thu, 12 Feb 1998 14:35:17 -0500 (EST) Date: Thu, 12 Feb 1998 14:48:00 -0500 Message-Id: <199802121948.OAA28831@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: FUKUMOTO Atsushi Cc: ipsec@tis.com In-Reply-To: FUKUMOTO Atsushi's message of Thu, 12 Feb 1998 17:59:36 +0900, <199802120859.RAA27758@isl.rdc.toshiba.co.jp> Subject: Re: Generic CBC-MAC specification Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Thu, 12 Feb 1998 17:59:36 +0900 From: FUKUMOTO Atsushi Only description I could find about CBC-MAC in "Applied Cryptography 2nd ed." (first print) is in p.456, where it says: [...] encrypt a message with a block algorithm in CBC or CFB modes. The hash is the last encrypted block, encrypted once more in CBC or CFB modes. This last line, "encrypted once more in CBC or CFB modes", seems to be different from FIPS81 Appendix F, or Mr.Rogers' CBC-MAC draft. So my question is, am I right that the description of Applied Cryptography is wrong, and the "encrypted once more" should only be applied to CFB mode? If Applied Crypto says this, Applied Crypto is wrong.... - Ted From owner-ipsec Thu Feb 12 16:13:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA16360 for ipsec-outgoing; Thu, 12 Feb 1998 16:11:17 -0500 (EST) Message-Id: <199802122132.QAA00928@smtp3.erols.com> From: "Rich Ankney" To: "Theodore Y. Ts'o" , "FUKUMOTO Atsushi" Cc: Subject: Re: Generic CBC-MAC specification Date: Thu, 12 Feb 1998 16:30:20 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Actually, the extra encryption of the last block was defined in ANSI X9.19 (retail MAC for things like ATM transactions). A recent paper by Bellare and Rogaway proves that this approach does indeed provide the optimum amount of extra security. Regards, Rich ---------- > From: Theodore Y. Ts'o > To: FUKUMOTO Atsushi > Cc: ipsec@tis.com > Subject: Re: Generic CBC-MAC specification > Date: Thursday, February 12, 1998 2:48 PM > > Date: Thu, 12 Feb 1998 17:59:36 +0900 > From: FUKUMOTO Atsushi > > Only description I could find about CBC-MAC in "Applied Cryptography > 2nd ed." (first print) is in p.456, where it says: > > [...] encrypt a message with a block algorithm in CBC or CFB > modes. The hash is the last encrypted block, encrypted once > more in CBC or CFB modes. > > This last line, "encrypted once more in CBC or CFB modes", seems to be > different from FIPS81 Appendix F, or Mr.Rogers' CBC-MAC draft. > > So my question is, am I right that the description of Applied > Cryptography is wrong, and the "encrypted once more" should only be > applied to CFB mode? > > If Applied Crypto says this, Applied Crypto is wrong.... > > - Ted From owner-ipsec Thu Feb 12 17:22:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA16774 for ipsec-outgoing; Thu, 12 Feb 1998 17:20:16 -0500 (EST) Date: Thu, 12 Feb 1998 17:28:33 -0600 (CST) From: Engineering To: Daniel Harkins cc: ipsec@tis.com Subject: Re: Help - Details on March 2nd worshop at Raliegh requested ... In-Reply-To: <199802121804.KAA20325@dharkins-ss20.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Thu, 12 Feb 1998, Daniel Harkins wrote: > If you have a what sort of questions I could probably help you. Stu What sort of space will be available to each vendor. Do we need to bring any special fixtures besides computer equipment and power fixtures. (Tables, chairs, banner or identification, ... ?) What about firewall configurations ? What about phone line connectivity for remote access testing ? Thanks, Jeffrey Goodwin ** Ashley Laurent,Inc. ** Software Development ** Consulting ** * * * * 707 West Avenue, Suite 201 * voice: 512-322-0676 * * Austin, Texas 78701 * fax : 512-322-0680 * * web: http://www.osgroup.com * * Microsoft Solution Provider * Complete Systems Design/Development * * Novell Professional Developer * Systems Software/Device Drivers * From owner-ipsec Thu Feb 12 17:43:46 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA16934 for ipsec-outgoing; Thu, 12 Feb 1998 17:43:16 -0500 (EST) Message-Id: <199802122256.OAA20793@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Engineering Cc: ipsec@tis.com Subject: Re: Help - Details on March 2nd worshop at Raliegh requested ... In-Reply-To: Your message of "Thu, 12 Feb 1998 17:28:33 CST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Feb 1998 14:56:13 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk > On Thu, 12 Feb 1998, Daniel Harkins wrote: > > > If you have a what sort of questions I could probably help you. Stu > > What sort of space will be available to each vendor. Do we need to > bring any special fixtures besides computer equipment and power fixtures. > (Tables, chairs, banner or identification, ... ?) The amount of space depends on how many people show up. The last several bakeoffs had room for 2-3 people per group. If your company has several products-- a host product and a gateway product, for instance-- then you'll probably get a bit more table space. If you've got a single PC you'll probably get something a tad less. Don't be surprised if you share a table with someone else. Bring hubs if you need them as they always seem to be in short supply. Don't bother bringing tables or chairs. Please don't bring banners; this is an interoperability test. You'll probably all have a piece of cardboard folded in two with your company's name on it to place on your table. That's about the extent of your corporate presence. We won't be checking IDs. > What about firewall configurations ? I don't understand the question. > What about phone line connectivity for remote access testing ? We'll have it but there'll also be Internet access for remote testing as well. Dan. From owner-ipsec Thu Feb 12 20:02:46 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA17772 for ipsec-outgoing; Thu, 12 Feb 1998 20:01:24 -0500 (EST) Organization: ESAT, K.U.Leuven, Belgium Date: Fri, 13 Feb 1998 02:13:01 +0100 (MET) From: Bart Preneel To: Rich Ankney cc: "Theodore Y. Ts'o" , FUKUMOTO Atsushi , ipsec@tis.com Subject: Re: Generic CBC-MAC specification In-Reply-To: <199802122132.QAA00928@smtp3.erols.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Unlike most of you, I do not believe that the security of CBC-MAC is so straightforward. Most of the (public) results on its security are only a few years old, so I would not rely on a text book... For the additional encryption: this is only necessary to make CFB-MAC exactly identical to CBC-MAC (you get the same result, but with a different mode). So it is not used in CBC-MAC. - While there is indeed the very nice security proof by Bellare and Rogaway [1], this proof only "works" up till 2**32 messages both for DES and for 3-DES. An attack using this number of known text-MAC pairs can be found in [2]. The forgery attack becomes harder if only a 32-bit result is being used (more chosen texts required). - Addressing the variable length problem is not as easy as it seems. - There is a trivial attack if you do nothing. If you only use 32 bits, there is a very recent attack requiring only 2**16 texts [3]. - Prepending the length seems to work, but is not possible in all applications [1]. - Encrypting the final result with a derived key has been proposed by the RIPE consortium in 1992 [4]. This proposal was then included in the annex of ISO/IEC 9797:1993 (which is not informational). - The ANSI retail MAC uses triple encryption in the last step; this solution has also been included in the annex of ISO 9797. However, there is a recent key recovery attack showing that this is not as secure as it should be [5]. In conclusion: it might be wise to consider writing up a solid draft on CBC-MAC. [1] BELLARE, M., KILIAN, J., and ROGAWAY, P.: `The security of cipher block chaining', Advances in Cryptology, CRYPTO'94, Lect. Notes Comput. Sci. 839, (Springer-Verlag, 1994), pp.~341--358 [2] PRENEEL, B. and VAN OORSCHOT, P.C.: `MDx-MAC and building fast MACs from hash functions', Advances in Cryptology, CRYPTO'95, Lect. Notes Comput. Sci. 963, (Springer-Verlag, 1995), pp. 1-14 [3] KNUDSEN, L.R.: `A chosen text attack on CBC-MAC', Electron. Lett., 1997, 33, (1), pp. 48-49 [4] RIPE: `Integrity Primitives for Secure Information Systems. Final Report of RACE Integrity Primitives Evaluation (RIPE-RACE 1040),' LNCS 1007, A. Bosselaers, B. Preneel, Eds., (Springer-Verlag, 1995) [5] PRENEEL, B and VAN OORSCHOT, P.C.: `A key recovery attack on the ANSI X9.19 retail MAC', Electron. Lett., 1996, 32, (17), pp. 1568-1569 FIPS 113: `Computer Data Authentication,' Federal Information Processing Standard (FIPS), Publication 131, (National Bureau of Standards, US Department of Commerce, Washington D.C., May 1985) ANSI X9.9 (revised): `Financial institution message authentication (wholesale)' (American Bankers Association, April 7, 1986) ANSI X9.19: `Financial institution retail message authentication' (American Bankers Association, August 13, 1986) ISO 8731: `Banking - approved algorithms for message authentication, Part 1, DEA, Part 2, Message authentication algorithm (MAA)' (ISO, 1987) ISO/IEC 9797: `Information technology - Data cryptographic techniques - Data integrity mechanisms using a cryptographic check function employing a block cipher algorithm' (ISO/IEC, 1993) (this standard is currently under revision). If you want to find out how all these standards are related: check MENEZES, A., VAN OORSCHOT, P.C., VANSTONE, S.A.: Handbook of Applied Cryptography, (CRC Press, 1997) --Bart Preneel ------------------------------------------------------------------------------- Katholieke Universiteit Leuven tel. +32 16 32 11 48 Dept. Electrical Engineering-ESAT / COSIC fax. +32 16 32 19 86 K. Mercierlaan 94, B-3001 Heverlee, BELGIUM bart.preneel@esat.kuleuven.ac.be http://www.esat.kuleuven.ac.be/~preneel ------------------------------------------------------------------------------- On Thu, 12 Feb 1998, Rich Ankney wrote: > Actually, the extra encryption of the last block was defined in > ANSI X9.19 (retail MAC for things like ATM transactions). > A recent paper by Bellare and Rogaway proves that this approach > does indeed provide the optimum amount of extra security. > > Regards, > Rich > > ---------- > > From: Theodore Y. Ts'o > > To: FUKUMOTO Atsushi > > Cc: ipsec@tis.com > > Subject: Re: Generic CBC-MAC specification > > Date: Thursday, February 12, 1998 2:48 PM > > > > Date: Thu, 12 Feb 1998 17:59:36 +0900 > > From: FUKUMOTO Atsushi > > > > Only description I could find about CBC-MAC in "Applied Cryptography > > 2nd ed." (first print) is in p.456, where it says: > > > > [...] encrypt a message with a block algorithm in CBC or CFB > > modes. The hash is the last encrypted block, encrypted once > > more in CBC or CFB modes. > > > > This last line, "encrypted once more in CBC or CFB modes", seems to be > > different from FIPS81 Appendix F, or Mr.Rogers' CBC-MAC draft. > > > > So my question is, am I right that the description of Applied > > Cryptography is wrong, and the "encrypted once more" should only be > > applied to CFB mode? > > > > If Applied Crypto says this, Applied Crypto is wrong.... > > > > - Ted > From owner-ipsec Thu Feb 12 22:45:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA18723 for ipsec-outgoing; Thu, 12 Feb 1998 22:44:20 -0500 (EST) Message-Id: <3.0.5.32.19980212225419.009b1430@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 12 Feb 1998 22:54:19 -0500 To: Engineering , Daniel Harkins From: Robert Moskowitz Subject: Re: Help - Details on March 2nd worshop at Raliegh requested ... Cc: ipsec@tis.com In-Reply-To: References: <199802121804.KAA20325@dharkins-ss20.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 05:28 PM 2/12/98 -0600, Engineering wrote: > >What sort of space will be available to each vendor. Do we need to >bring any special fixtures besides computer equipment and power fixtures. >(Tables, chairs, banner or identification, ... ?) You will need to bring your own hubs and cables. If you are a gateway product, that will be 2 hubs. Also a power strip or two will be wise to bring along. The facility is the Embassy suite's ballroom. Some 3100 sq ft (smaller than Ottawa, but that was unique). The hotel is suppling tables and chairs and main power runs. Cisco is providing a switch with 10baseT lines to each table and Internet connectivity plus address blocks. The room is suppose to be open 24 hours a day starting 6am on monday. >What about firewall configurations ? I ASSUME you mean your IPsec gateway config? We are working on test plans. Sorry it is taking so long, my job change plus a few other items. >What about phone line connectivity for remote access testing ? There will be a few phone curcuits for dialup testing. Ethernet clients should also be tested.... Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Thu Feb 12 23:20:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA18909 for ipsec-outgoing; Thu, 12 Feb 1998 23:20:20 -0500 (EST) Date: Thu, 12 Feb 1998 23:32:14 -0500 Message-Id: <199802130432.XAA29362@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Bart Preneel Cc: Rich Ankney , "Theodore Y. Ts'o" , FUKUMOTO Atsushi , ipsec@tis.com In-Reply-To: Bart Preneel's message of Fri, 13 Feb 1998 02:13:01 +0100 (MET), Subject: Re: Generic CBC-MAC specification Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Before people start going crazy over this subject, it might be helpful of people read the I-O resolution document first. For example, you'd might discover that 3DES-CBC-MAC was proposed to be used only as a pseudo-random function (PRF), NOT as a MAC. And, that if no PRF is negotiated the default PRF of the HMAC form of the negotiated hash algorithm is used. The security properties required of a pseudo-random function are very different from those required of a MAC. So, the main question before us is not that of security, but of interoperability, with apparently more than one documented way of a CBC-MAC. Question: has anyone actually implemented 3DES-CBC-MAC as a PRF to be used in ISAKMP/Oakley? If so, how did you do it? The FIPS-81 way, or X9.19 way? If no one has implemented 3DES-CBC-MAC as a PRF, the simplest way of solving this problem is to drop it from the draft altogether, and let IPSECOND worry about documenting alternative PRF's if people don't want to use HMAC. We need to get these documents out, guys. Time is a ticking, and things that can get pushed off until later.... should get pushed back until later. - Ted From owner-ipsec Fri Feb 13 08:05:02 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA22446 for ipsec-outgoing; Fri, 13 Feb 1998 08:02:21 -0500 (EST) Message-Id: <3.0.5.32.19980213080925.009a94f0@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 13 Feb 1998 08:09:25 -0500 To: Engineering , Daniel Harkins From: Robert Moskowitz Subject: Re: Help - Details on March 2nd worshop at Raliegh requested ... Cc: ipsec@tis.com In-Reply-To: <3.0.5.32.19980212225419.009b1430@homebase.htt-consult.com> References: <199802121804.KAA20325@dharkins-ss20.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:54 PM 2/12/98 -0500, Robert Moskowitz wrote: >At 05:28 PM 2/12/98 -0600, Engineering wrote: >> >>What sort of space will be available to each vendor. Do we need to >>bring any special fixtures besides computer equipment and power fixtures. >>(Tables, chairs, banner or identification, ... ?) > >You will need to bring your own hubs and cables. I will be bringing the hub for non-vendor participants, a few cables, and a powerstrip... Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Fri Feb 13 09:02:57 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA22951 for ipsec-outgoing; Fri, 13 Feb 1998 09:02:22 -0500 (EST) Message-Id: <199802131341.IAA19077@ghostwheel.ncsl.nist.gov> Date: Fri, 13 Feb 1998 08:41:31 -0500 (EST) To: ipsec@tis.com From: rob.glenn@nist.gov Subject: Summary of changes to HMAC-MD5-96 draft X-Mailer: Ishmail 1.3.2-970722-linux MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk draft-ietf-ipsec-auth-hmac-md5-96-02.txt has been submitted and should show up in the typical places in a couple of days. Here is a summary of the changes. In addition, a few typos were corrected and some references updated. 1. With regard to implicit packet padding... change: HMAC-MD5-96 operates on 64-byte blocks of data. Padding requirements are specified in [RFC-1321] and are part of the MD5 algorithm. Padding bits are only necessary in computing the HMAC-MD5 authenticator value and MUST NOT be included in the packet. to: HMAC-MD5-96 operates on 64-byte blocks of data. Padding requirements are specified in [RFC-1321] and are part of the MD5 algorithm. If MD5 is built according to [RFC-1321], there is no need to add any additional padding as far as HMAC-MD5-96 is concerned. With regard to "implicit packet padding" as defined in [AH], no implicit packet padding is required. 2. With regard to key lengths Change: Key lengths other than 128-bits SHALL NOT be supported. To: Key lengths other than 128-bits MUST NOT be supported (i.e. only 128-bit keys are to be used by HMAC-MD5-96). 3. In response to the document reading party's comments: >Section 3. Keying Material - The 4th paragraph references the ESP >doc (and not AH) as to how to obtain and process keying material. We >question why this paragraph exists at all. In addition, the ESP has NO such >description of how to do these things. and > [ESP] describes the general mechanism to obtain keying material for > the ESP transform. The derivation of the key from some amount of > keying material does not differ between the manual and automatic key > management mechanisms. > to [arch]... Change: [ESP] describes the general mechanism to obtain keying material for the ESP transform. The derivation of the key from some amount of keying material does not differ between the manual and automatic key management mechanisms. To: [ARCH] describes the general mechanism for obtaining keying material when multiple keys are required for a single SA (e.g. when an ESP SA requires a key for confidentiality and a key for authentication). Also, added a reference for [ARCH]. 4. In response to the document reading party's comment: >There is a requirment that "any known attacks" be discussed in the >Security Considerations section. The MD5-96-01 doc does not discuss this. The following as added to paragraph 1 of section 5. At the time of this writing there are no known cryptographic attacks against HMAC-MD5-96. Rob G. rob.glenn@nist.gov From owner-ipsec Fri Feb 13 10:20:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA23584 for ipsec-outgoing; Fri, 13 Feb 1998 10:17:26 -0500 (EST) Date: Fri, 13 Feb 1998 10:29:14 -0500 (EST) Message-Id: <199802131529.KAA21593@carp.morningstar.com> From: Ben Rogers To: "Theodore Y. Ts'o" Cc: Bart Preneel , Rich Ankney , FUKUMOTO Atsushi , ipsec@tis.com Subject: Re: Generic CBC-MAC specification In-Reply-To: <199802130432.XAA29362@dcl.MIT.EDU> References: <199802130432.XAA29362@dcl.MIT.EDU> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Theodore Y. Ts'o writes: > So, the main question before us is not that of security, but of > interoperability, with apparently more than one documented way of a > CBC-MAC. Question: has anyone actually implemented 3DES-CBC-MAC as a > PRF to be used in ISAKMP/Oakley? If so, how did you do it? The FIPS-81 > way, or X9.19 way? I have implemented it, and done it the FIPS-81 way. However, I have no problem dropping it, partly because I'm not comfortable with it and partly because it requires a lot of extra code to support. I will be more than happy to demonstrate a very peculiar result of using it as your prf at the workshop. ben From owner-ipsec Fri Feb 13 11:03:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA23869 for ipsec-outgoing; Fri, 13 Feb 1998 11:02:28 -0500 (EST) From: Cheryl Madson Message-Id: <199802131615.IAA26464@trix.cisco.com> Subject: Changes to the ciph-des-explicit-iv draft To: ipsec@tis.com Date: Fri, 13 Feb 1998 08:15:16 -0800 (PST) Cc: cmadson@cisco.com (Cheryl Madson) 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 The following changes have been made to the "ciph-des-explicit-iv" draft. Special thanks go to Steve Bellovin and Carlisle Adams for fielding a flurry of last-minute questions. I will be submitting the draft to Cynthia today. Thx - C ================ 1. Bellovin has pointed out an attack based upon using low-Hamming distance IV values. Based on this, (a) In section 3, changed "The IV SHOULD be chosen at random." to "The IV MUST be a random value." (b) Added to the section 3 implementation note: To avoid ECB encryption of very similar plaintext blocks in different packets, implementations MUST NOT use a counter or other low-Hamming distance source for IVs. (c) Added to the Security Considerations section: The case for using random values for IVs has been refined with the following summary provided by Steve Bellovin. Refer to [Bell97] for further information. "The problem arises if you use a counter as an IV, or some other source with a low Hamming distance between successive IVs, for encryption in CBC mode. In CBC mode, the "effective plaintext" for an encryption is the XOR of the actual plaintext and the ciphertext of the preceeding block. Normally, that's a random value, which means that the effective plaintext is quite random. That's good, because many blocks of actual plaintext don't change very much from packet to packet, either. For the first block of plaintext, though, the IV takes the place of the previous block of ciphertext. If the IV doesn't differ much from the previous IV, and the actual plaintext block doesn't differ much from the previous packet's, then the effective plaintext won't differ much, either. This means that you have pairs of ciphertext blocks combined with plaintext blocks that differ in just a few bit positions. This can be a wedge for assorted cryptanalytic attacks." The discussion on IVs has been updated to require that an implementation not use a low-Hamming distance source for IVs. (d) Added a reference to his paper. 2. To clarify the points of key size/format, made the following changes: (a) In section 4, first paragraph, changed the text to: DES-CBC is a symmetric secret key algorithm. The key size is 64 bits. [It is commonly known as a 56-bit key as the key has 56 significant bits; the least significant bit in every byte is the parity bit.] (b) [ESP] doesn't describe the so-called slicing-and-dicing (which algorithm gets which chunk of the base key); the information is contained in [arch]. (c) To clarify the "56-vs-64 bits from key engine": This mechanism MUST derive a 64-bit key value for use by this cipher. The mechanism will derive raw key values, the derivation process itself is not responsible for handling parity or weak key checks. (d) w.r.t. parity -- as there is no technical reason for a MUST (the parity bits are ignored during key transformation and so are really a local implementation issue instead of an interoperability issue), removed the "MUST set parity" and added the following: Implementation note: If an implementation chooses to do weak key checking, it should recognize that the known weak keys [FIPS74] have been adjusted for parity. Otherwise the handling of parity is a local issue. (e) Added a statement requiring a strong PRF for key generation, aligning this draft with the other algorithm drafts. 3. Weak keys: the bulk of the feedback here said to simply refer to the FIPS draft. Removed the list of weak keys (although the FIPS draft does not identity "possibly weak" keys). 4. Key Lifetime. New text: [Blaze96] discusses the costs and key recovery time for brute force attacks. It presents various combinations of total cost/time to recover a key/cost per key recovered for 40-bit and 56-bit DES keys, based on late 1995 estimates. While a brute force search of a 56-bit DES keyspace can be considered infeasable for the so-called casual hacker, who is simply using spare CPU cycles or other low-cost resources, it is within reach of someone willing to spend a bit more money. For example, for a cost of $300,000, a 56-bit DES key can be recovered in an average of 19 days using off-the-shelf technology and in only 3 hours using a custom developed chip. It should be noted that there are other attacks which can recover the key faster, that brute force attacks are considered the "worst case", although the easiest to implement. [Wiener94] also discusses a $1M machine which can break a DES key in 3.5 hours (1993 estimates), using a known-plaintext attack. As discussed in the Security Considerations section, a known plaintext attack is reasonably likely. It should also be noted that over time, the total and average search costs as well as the average key recovery time will continue to drop. While the above does not provide specific recommendations for key lifetime, it does reinforce the point that for a given application the desired key lifetime is dependent upon the perceived threat (an educated guess as to the amount of resources available to the attacker) relative to the worth of the data to be protected. While there are no recommendations for volume-based lifetimes made here, it shoud be noted that given sufficient volume there is an increased probabilty that known plaintext can be accumulated. 5. Fixed references: (a) Fixed the inconsistent spelling of Mike Wiener's name. (b) FIPS-46-2 has superceded both FIPS-46 and FIPS-46-1. (c) Added URL references to HTTP versions of the relevant FIPS documents. [No more watching the printer barf on a WP5 document!] (d) Added: [Bell97] Bellovin, S., "Probable Plaintext Cryptanalysis of the IP Security Protocols", Proceedings of the Symposium on Network and Distributed System Security, San Diego, CA, pp. 155-160, February 1997 (also http://www.research.att.com/~smb/probtxt.{ps, pdf}). [Blaze96] Blaze, M., Diffie, W., Rivest, R., Schneier, B., Shimomura, T., Thompson, E., Wiener, M., "Minimal Key Lengths for Symmetric Ciphers to Provide Adequate Commercial Security", currently available at http://www.bsa.org/policy/encryption/cryptographers.html. (e) Additional locations to find [Wiener94]: [Reprinted in "Practical Cryptography for Data Internetworks", W.Stallings, editor, IEEE Computer Society Press, pp.31-79 (1996). Currently available at ftp://ripem.msu.edu/pub/crypt/docs/des-key-search.ps.] 6. Changed the contact info for Bob ;-). From owner-ipsec Fri Feb 13 14:00:40 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA25074 for ipsec-outgoing; Fri, 13 Feb 1998 13:53:35 -0500 (EST) Date: Fri, 13 Feb 1998 14:03:12 -0600 (CST) From: Engineering To: Daniel Harkins cc: ipsec@tis.com Subject: Re: Help - Details on March 2nd worshop at Raliegh requested ... In-Reply-To: <199802122256.OAA20793@dharkins-ss20.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > > > What about firewall configurations ? > Interoperabilty with NAT... Jeff From owner-ipsec Fri Feb 13 15:49:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA26306 for ipsec-outgoing; Fri, 13 Feb 1998 15:49:42 -0500 (EST) Message-Id: <199802132049.PAA26306@portal.ex.tis.com> Date: Fri, 13 Feb 98 15:35:40 EST From: Karen Seo To: ipsec@tis.com cc: kseo@bbn.com Subject: IPsec AH and ESP drafts Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, Here's a summary of IPsec AH and ESP edits/questions. This is based on the drafts distributed in 11/97 and subsequent email (up until 1/31). It does not include minor edits (typos), the addition of the new copyright text required by the RFC format instructions, updating of the reference section, etc. The issues have been divided into 3 groups: AH-ONLY ESP-ONLY AH AND ESP We have submitted the AH and ESP drafts to the IETF secretariat for distribution. Per direction from the working group chairs, we are also sending copies directly to the list to get them into folks' hands as soon as possible. Thank you for all the feedback/help both on the list and in private email. Karen AH-ONLY ============================================================================ === 1. Per email from Dave Mason (12/29-30) -- For IPv4, need to discuss how to handle the bytes of IP header after the last option. RFC 791 (IP) and RFC 1122 (Host Requirements) specify only that an "End of Options List" option is placed after the last option. "This might not coincide with the end of the internet header according to the internet header length.... and need only be used if the end of the options would not otherwise coincide with the end of the internet header." They do not say to insert "End of Options List" options until the IP header is 4-byte aligned or up to the end of the IP header. *Changed AH Appendix A.1 IPv4 Options -- added the following note at the end of the table. End of Options List options SHOULD be repeated as necessary to ensure that the IP header ends on a 4 byte boundary in order to ensure that there are no unspecified bytes which could be used for a covert channel. ESP-ONLY ============================================================================ === 1. Section 3.1 -- Per summary from IPsec document reading party, "3.1 Say that tunnel mode *MUST* be used." * Sorry, but could someone provide more context? There are several places where this statement might apply. 2. Section 3.3.3 Sequence Number Generation -- Add pointer to Section 5 to provide explanation for comment on manual key management. * Changed last paragraph of this section from: If anti-replay has been disabled, the sender does not need to monitor or reset the counter, e.g., in the case of manual key management. to: If anti-replay has been disabled, the sender does not need to monitor or reset the counter, e.g., in the case of manual key management (see Section 5). 3. Section 3.3.5 -- Per summary from IPsec document reading party, "3.3.5 I'm not convinced that the description of how to do fragmentation is correct. I'm especially concerned that transport and tunnel modes require different processing. The interaction of the rules here with IPv6 fragmentation is especially worthy of attention. (See the discussion of fragmentation in Wagner and Bellovin's "A Bump in the Stack Encryptor for MS-DOS"....) * Modified the existing Section "3.3.5 Fragmentation": If necessary, fragmentation is performed after ESP processing within an IPsec implementation. Thus, transport mode ESP is applied only to whole IP datagrams (not to IP fragments). An IP packet to which ESP has been applied may itself be fragmented by routers en route, and such fragments must be reassembled prior to ESP processing at a receiver. In tunnel mode, ESP is applied to an IP packet, the payload of which may be a fragmented IP packet. For example, a security gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation (as defined in the Security Architecture document) may apply tunnel mode ESP to such fragments. by adding the following two notes: NOTE: For transport mode -- As mentioned at the beginning of Section 3.1, bump-in-the-stack and bump-in-the-wire implementations may have to first reassemble a packet fragmented by the local IP layer, then apply IPsec, and then fragment the resulting packet. NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire implementations, it will be necessary to walk through all the extension headers to determine if there is a fragmentation header and hence that the packet needs reassembling prior to IPsec processing. 4. Section 3.4.5 -- Per summary from IPsec document reading party, need to correct the text to indicate additional ways in which decryption can "fail". * Changed Section 3.4.5 Packet Decryption, paragraph 4 (counting the indented steps 1,2,3 taken by the receiver as one paragraph) from: Note that there are two ways in which the decryption can "fail". o The selected SA may not be correct. o 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. to: Note that there are several ways in which the decryption can "fail": a. The selected SA may not be correct -- The SA may be mis-selected due to tampering with the SPI, destination address. or IPsec protocol type fields. Such errors, if they map the packet to another extant SA, will be indistinguishable from a corrupted packet, (case c). Tampering with the SPI can be detected by use of authentication. However, an SA mismatch might still occur due to tampering with the IP Destination Address or the IPsec protocol type field. b. The pad length or pad values could be erroneous -- Bad pad lengths or pad values can be detected irrespective of the use of authentication. c. The encrypted ESP packet could be corrupted -- This can be detected if authentication is selected for the SA., In case (a) or (c), 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. AH AND ESP ============================================================================ === 1. Section 2 -- Define "IV" (ESP-only) and "ICV" (AH and ESP) before/when using these terms. * In AH -- Changed the text following the header format diagram from: The following subsections define the fields that comprise the AH format. All the fields described here are mandatory, i.e., they are always present in the AH format and are included in the ICV computation. to: The following subsections define the fields that comprise the AH format. All the fields described here are mandatory, i.e., they are always present in the AH format and are included in the Integrity Check Value (ICV) computation (see Sections 2.6 and 3.3.3). * In ESP -- Changed text following header format diagram from: * If included in the Payload field, cryptographic synchronization data, e.g., an IV, usually is not encrypted per se, although it often is referred to as being part of the ciphertext. 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.... to: * If included in the Payload field, cryptographic synchronization data, e.g., an Initialization Vector (IV, see Section 2.3), usually is not encrypted per se, although it often is referred to as being part of the ciphertext. 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 Integrity Check Value (ICV, see Section 2.7)...... 2. Section 3.1 -- Per summary from IPsec document reading party, need to reconcile AH (Section 3.1) and ESP (Section 3.1) descriptions of support for combinations of SAs with the Architecture's description of support for combinations of SAs. *The Architecture document has been changed to more clearly reflect the 4 cases that the community agreed needed to be supported and remove some errors and inconsistencies. The AH and ESP text has been changed to point to the Architecture document. We removed the following text from AH and ESP Sections 3.1: If more than one IPsec header/extension is required, then starting with packet [IP1][upper], the following 5 cases plus any combination of one of the Tunnel cases followed by one of the Transport cases (i.e., 4 then 1, 4 then 2, 4 then 3, 5 then 1, 5 then 2, 5 then 3.) MUST be supported. Transport Tunnel ----------------- --------------------- 1. [IP1][AH][upper] 4. [IP2][AH][IP1][upper] 2. [IP1][ESP][upper] 5. [IP2][ESP][IP1][upper] 3. [IP1][AH][ESP][upper] Support for additional combinations of AH and ESP is optional. Use of other, optional combinations may adversely affect interoperability. and replaced it with: ESP and AH headers can be combined in a variety of modes. The IPsec Architecture document describes the combinations of security associations that must be supported. 3. Section 3.3.4 (ESP) and 3.3.3.2.2 (AH) -- Per discussion re: "implicit padding for authentication" (1/7-25), need to clarify that the input "block size" for MD5 and SHA-1 is such that no padding is needed even though their internal algorithms have an internal "block size" of 64 bytes. * Changed AH and ESP documents to clarify the above. This involved changing AH Section "3.3.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. by adding the following sentence at the end: Note that MD5 and SHA-1 are viewed as having a 1-byte blocksize because of their internal padding conventions. and changing ESP Section "3.3.4 Integrity Check Value Calculation", paragraph 2: 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, (after the Next Header field) 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. by adding the following sentence at the end: Note that MD5 and SHA-1 are viewed as having a 1-byte blocksize because of their internal padding conventions. 4. Section 3.4.1 -- Per summary from IPsec document reading party, need to clarify that the appearance of a "fragment" for ESP processing can result not just from a bug in the code but because the current IPv4 spec does NOT require (upon reassembly) the zero'ing of the OFFSET field or the clearing of the MORE FRAGMENTS flag. *Modified the following text in AH and ESP: 3.4.1 Reassembly If required, reassembly is performed prior to AH processing. If a packet offered to AH for processing appears to be an IP fragment, i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID. 3.4.1 Reassembly If required, reassembly is performed prior to ESP processing. If a packet offered to ESP for processing appears to be an IP fragment, i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID. by the addition of the following text: NOTE: For packet reassembly, the current IPv4 spec does NOT require either the zero'ing of the OFFSET field or the clearing of the MORE FRAGMENTS flag. In order for a reassembled packet to be processed by IPsec (as opposed to discarded as an apparent fragment), the IP code must do these two things after it reassembles a packet. 5. Section 3.4.3 -- Per suggestion from Dan McDonald (1/7), need to modify the documents to clarify that anti-replay is not supportable in the case of multiple senders to a single SA, irrespective of whether the destination address is unicast, broadcast, or multicast. *Changed AH and ESP documents to clarify the above. This involved changing AH Section "3.4.3 Sequence Number Verification" from: All AH implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. (Note that there are no provisions for managing transmitted Sequence Number values among multiple senders directing traffic to a single, multicast SA. Thus the anti-replay service SHOULD NOT be used in a multi-sender multicast environment that employs a single, multicast SA.) to: All AH implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. (Note that there are no provisions for managing transmitted Sequence Number values among multiple senders directing traffic to a single SA (irrespective of whether the destination address is unicast, broadcast, or multicast). Thus the anti-replay service SHOULD NOT be used in a multi-sender environment that employs a single SA.) and changing ESP Section "3.4.3 Sequence Number Verification" from: All ESP implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. This service MUST NOT be enabled unless the authentication service also is enabled for the SA, since otherwise the Sequence Number field has not been integrity protected. (Note that there are no provisions for managing transmitted Sequence Number values among multiple senders directing traffic to a single, multicast SA. Thus the anti-replay service SHOULD NOT be used in a multi-sender multicast environment that employs a single, multicast SA.) to: All ESP implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. This service MUST NOT be enabled unless the authentication service also is enabled for the SA, since otherwise the Sequence Number field has not been integrity protected. (Note that there are no provisions for managing transmitted Sequence Number values among multiple senders directing traffic to a single SA (irrespective of whether the destination address is unicast, broadcast, or multicast). Thus the anti-replay service SHOULD NOT be used in a multi-sender environment that employs a single SA.) From owner-ipsec Fri Feb 13 15:50:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA26319 for ipsec-outgoing; Fri, 13 Feb 1998 15:50:40 -0500 (EST) Message-Id: <199802132050.PAA26319@portal.ex.tis.com> Date: Fri, 13 Feb 98 15:38:49 EST From: Karen Seo To: ipsec@tis.com Subject: Internet Draft -- IPsec ESP spec Sender: owner-ipsec@ex.tis.com Precedence: bulk Network Working Group Stephen Kent, BBN Corp Internet Draft Randall Atkinson, @Home Network draft-ietf-ipsec-esp-v2-03.txt February 1998 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 IPsec working group. 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. Copyright (C) The Internet Society (February 1998). All Rights Reserved. Kent, Atkinson [Page 1] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) Table of Contents 1. Introduction......................................................3 2. Encapsulating Security Payload Packet Format......................4 2.1 Security Parameters Index....................................5 2.2 Sequence Number .............................................5 2.3 Payload Data.................................................5 2.4 Padding (for Encryption).....................................6 2.5 Pad Length...................................................7 2.6 Next Header..................................................7 2.7 Authentication Data..........................................8 3. Encapsulating Security Protocol Processing........................8 3.1 ESP Header Location..........................................8 3.2 Algorithms..................................................10 3.2.1 Encryption Algorithms..................................10 3.2.2 Authentication Algorithms..............................11 3.3 Outbound Packet Processing..................................11 3.3.1 Security Association Lookup............................11 3.3.2 Packet Encryption......................................11 3.3.3 Sequence Number Generation.............................12 3.3.4 Integrity Check Value Calculation......................12 3.3.5 Fragmentation..........................................13 3.4 Inbound Packet Processing...................................13 3.4.1 Reassembly.............................................13 3.4.2 Security Association Lookup............................14 3.4.3 Sequence Number Verification...........................14 3.4.4 Integrity Check Value Verification.....................16 3.4.5 Packet Decryption......................................16 4. Auditing.........................................................18 5. Conformance Requirements.........................................18 6. Security Considerations..........................................18 7. Differences from RFC 1827........................................19 Acknowledgements....................................................19 References..........................................................19 Disclaimer..........................................................20 Author Information..................................................21 Kent, Atkinson [Page 2] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) 1. Introduction The Encapsulating Security Payload (ESP) header is designed to provide a mix of 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 "Security Architecture for the Internet Protocol" [KA97a], hereafter referred to as the Security Architecture document). 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 the Security Architecture document [KA97a]. The ESP header is inserted after the IP header and before the upper layer protocol header (transport mode) or before an encapsulated IP header (tunnel mode). These modes are described in more detail below. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. The set of services provided depends on options selected at the time of Security Association establishment and on the placement of the implementation. Confidentiality may be selected independent of all other services. However, use of confidentiality without integrity/authentication (either in ESP or separately in AH) may subject traffic to certain forms of active attacks that could undermine the confidentiality service (see [Bel96]). Data origin authentication and connectionless integrity are joint services (hereafter referred to jointly as "authentication) and are offered as an option in conjunction with confidentiality. The anti-replay service may be selected only if data origin authentication is selected, and its election is solely at the discretion of the receiver. (Although the default calls for the sender to increment the Sequence Number used for anti-replay, the service is effective only if the receiver checks the Sequence Number.) Traffic flow confidentiality requires selection of tunnel mode, and is most effective if implemented at a security gateway, where traffic aggregation may be able to mask true source-destination patterns. It is assumed that the reader is familiar with the terms and concepts described in the Security Architecture document. In particular, the reader should be familiar with the definitions of security services offered by ESP and AH, the concept of Security Associations, the ways in which ESP can be used in conjunction with the Authentication Header (AH), and the different key management options available for Kent, Atkinson [Page 3] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) ESP and AH. (With regard to the last topic, the current key management options required for both AH and ESP are manual keying and automated keying via ISAKMP/Oakley.) The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [Bra97]. 2. Encapsulating Security Payload Packet Format The protocol header (IPv4, IPv6, or Extension) immediately preceding the ESP header will contain the value 50 in its Protocol (IPv4) or Next Header (IPv6, Extension) field [STD-2]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- | Security Parameters Index (SPI) | ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Auth. | Sequence Number | |Coverage +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----- | Payload Data* (variable) | | ^ ~ ~ | | | | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Confid. | | Padding (0-255 bytes) | |Coverage* +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Pad Length | Next Header | v v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------- | Authentication Data (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * If included in the Payload field, cryptographic synchronization data, e.g., an Initialization Vector (IV, see Section 2.3), usually is not encrypted per se, although it often is referred to as being part of the ciphertext. 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 Integrity Check Value (ICV, see Section 2.7). 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 Kent, Atkinson [Page 4] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) 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 that, in combination with the destination IP address and security protocol (ESP), uniquely identifies the Security Association for this datagram. 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. It is ordinarily selected by the destination system upon establishment of an SA (see the Security Architecture document for more details). The SPI field is mandatory. The SPI value of zero (0) is reserved for local, implementation- specific use and MUST NOT be sent on the wire. For example, a key management implementation MAY use the zero SPI value to mean "No Security Association Exists" during the period when the IPsec implementation has requested that its key management entity establish a new SA, but the SA has not yet been established. 2.2 Sequence Number This unsigned 32-bit field contains a monotonically increasing counter value (sequence number). It is mandatory and is always present even if the receiver does not elect to enable the anti-replay service for a specific SA. Processing of the Sequence Number field is at the discretion of the receiver, i.e., the sender MUST always transmit this field, but the receiver need not act upon it (see the discussion of Sequence Number Verification in the "Inbound Packet Processing" section below). The sender's counter and the receiver's counter are initialized to 0 when an SA is established. (The first packet sent using a given SA will have a Sequence Number of 1; see Section 3.3.3 for more details on how the Sequence Number is generated.) If anti-replay is enabled (the default), the transmitted Sequence Number must never be allowed to cycle. Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA. 2.3 Payload Data Payload Data is a variable-length field containing data described by the Next Header field. The Payload Data field is mandatory and is an Kent, Atkinson [Page 5] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) integral number of bytes in length. If the algorithm used to encrypt the payload requires cryptographic synchronization data, e.g., an Initialization Vector (IV), then this data MAY be carried explicitly in the Payload field. Any encryption algorithm that requires such explicit, per-packet synchronization data MUST indicate the length, any structure for such data, and the location of this data as part of an RFC specifying how the algorithm is used with ESP. If such synchronization data is implicit, the algorithm for deriving the data MUST be part of the RFC. Note that with regard to ensuring the alignment of the (real) ciphertext in the presence of an IV: o For some IV-based modes of operation, the receiver treats the IV as the start of the ciphertext, feeding it into the algorithm directly. In these modes, alignment of the start of the (real) ciphertext is not an issue at the receiver. o In some cases, the receiver reads the IV in separately from the ciphertext. In these cases, the algorithm specification MUST address how alignment of the (real) ciphertext is to be achieved. 2.4 Padding (for Encryption) Several factors require or motivate use of the Padding field. o If an encryption algorithm is employed that requires the plaintext to be a multiple of some number of bytes, e.g., the block size of a block cipher, the Padding field is used to fill the plaintext (consisting of the Payload Data, Pad Length and Next Header fields, as well as the Padding) to the size required by the algorithm. o Padding also may be required, irrespective of encryption algorithm requirements, to ensure that the resulting ciphertext terminates on a 4-byte boundary. Specifically, the Pad Length and Next Header fields must be right aligned within a 4-byte word, as illustrated in the ESP packet format figure above, to ensure that the Authentication Data field (if present) is aligned on a 4-byte boundary. o Padding beyond that required for the algorithm or alignment reasons cited above, may be used to conceal the actual length of the payload, in support of (partial) traffic flow confidentiality. However, inclusion of such additional padding has adverse bandwidth implications and thus its use should be undertaken with care. Kent, Atkinson [Page 6] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) The sender MAY add 0-255 bytes of padding. Inclusion of the Padding field in an ESP packet is optional, but all implementations MUST support generation and consumption of padding. The padding computation applies to the plaintext portion of the Payload Data, exclusive of the IV (if present). If Padding bytes are needed but the encryption algorithm does not specify the padding contents, then the following default processing MUST be used. The Padding bytes are initialized with a series of (unsigned, 1-byte) integer values. The first padding byte appended to the plaintext is numbered 1, with subsequent padding bytes making up a monotonically increasing sequence: 1, 2, 3, ... When this padding scheme is employed, the receiver SHOULD inspect the Padding field. (This scheme was selected because of its relative simplicity, ease of implementation in hardware, and because it offers limited protection against certain forms of "cut and paste" attacks in the absence of other integrity measures, if the receiver checks the padding values upon decryption.) Any encryption algorithm that requires Padding other than the default described above, MUST define the Padding contents (e.g., zeros or random data) and any required receiver processing of these Padding bytes in an RFC specifying how the algorithm is used with ESP. In such circumstances, the content of the Padding field will be determined by the encryption algorithm and mode selected and defined in the corresponding algorithm RFC. The relevant algorithm RFC MAY specify that a receiver MUST inspect the Padding field or that a receiver MUST inform senders of how the receiver will handle the Padding field. 2.5 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 no Padding bytes are present. The Pad Length field is mandatory. 2.6 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. Kent, Atkinson [Page 7] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) 2.7 Authentication Data The Authentication Data is a variable-length field containing an Integrity Check Value (ICV) computed over the ESP packet minus the Authentication Data. The length of the field is specified by the authentication function selected. The Authentication Data field is optional, and is included only if the authentication service has been selected for the SA in question. The authentication algorithm specification MUST specify the length of the ICV and the comparison rules and processing steps for validation. 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, note that for "bump-in-the-stack" or "bump-in-the- wire" implementations, as defined in the Security Architecture document, inbound and outbound IP fragments may require an IPsec implementation to perform extra IP reassembly/fragmentation in order to both conform to this specification and provide transparent IPsec support. Special care is required to perform such operations within these implementations when multiple interfaces are in use.) In transport mode, ESP is inserted after the IP header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other IPsec headers that have already been inserted. 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.) Kent, Atkinson [Page 8] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) BEFORE APPLYING ESP ---------------------------- IPv4 |orig IP hdr | | | |(any options)| TCP | Data | ---------------------------- AFTER APPLYING ESP ------------------------------------------------- IPv4 |orig IP hdr | ESP | | | ESP | ESP| |(any options)| Hdr | 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. BEFORE APPLYING ESP --------------------------------------- IPv6 | | ext hdrs | | | | orig IP hdr |if present| TCP | Data | --------------------------------------- AFTER APPLYING ESP --------------------------------------------------------- IPv6 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP| |IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer|Auth| --------------------------------------------------------- |<---- encrypted ---->| |<---- authenticated ---->| * = if present, could be before ESP, after ESP, or both ESP and AH headers can be combined in a variety of modes. The IPsec Architecture document describes the combinations of security associations that must be supported. 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 Kent, Atkinson [Page 9] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) "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* |new ext | | orig*|orig ext | | | ESP | ESP| |IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer|Auth| ------------------------------------------------------------ |<--------- encrypted ----------->| |<---------- authenticated ---------->| * = if present, construction of outer IP hdr/extensions and modification of inner IP hdr/extensions is discussed below. 3.2 Algorithms The mandatory-to-implement algorithms are described in Section 5, "Conformance Requirements". Other algorithms MAY be supported. 3.2.1 Encryption Algorithms 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 any data required to allow the receiver to establish cryptographic synchronization for decryption. This data may be carried explicitly in the payload field, e.g., as an IV (as described above), or the data may be derived from the packet header. Since ESP makes provision for padding of the plaintext, encryption algorithms employed with ESP may exhibit either block or stream mode characteristics. Kent, Atkinson [Page 10] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) 3.2.2 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 appropriate, though performance and space considerations currently preclude use of such algorithms. 3.3 Outbound Packet Processing In transport mode, the sender 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 Security Architecture document. If there is more than one IPsec header/extension required by security policy, the order of the application of the security headers MUST be defined by security policy. 3.3.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 Security Architecture document. 3.3.2 Packet Encryption The sender: 1. encapsulates (into the ESP Payload field): - for transport mode -- just the original upper layer protocol information. - for tunnel mode -- the entire original IP datagram. 2. adds any necessary padding. 3. encrypts the result (Payload Data, Padding, Pad Length, and Next Header) using the key, encryption algorithm, algorithm mode indicated by the SA and cryptographic synchronization data (if any). - If explicit cryptographic synchronization data, e.g., an IV, is indicated, it is input to the decryption algorithm per the algorithm specification and placed Kent, Atkinson [Page 11] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) in the Payload field. - If implicit cryptographic synchronication data, e.g., an IV, is indicated, it is constructed and input to the decryption algorithm as per the algorithm specification. The exact steps for constructing the outer IP header depend on the mode (transport or tunnel) and are described in the Security Architecture document. If authentication is 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. 3.3.3 Sequence Number Generation The sender's counter is initialized to 0 when an SA is established. The sender increments the Sequence Number for this SA and inserts the new value into the Sequence Number field. Thus the first packet sent using a given SA will have a Sequence Number of 1. If anti-replay is enabled (the default), the sender checks to ensure that the counter has not cycled before inserting the new value in the Sequence Number field. In other words, the sender MUST NOT send a packet on an SA if doing so would cause the Sequence Number to cycle. An attempt to transmit a packet that would result in Sequence Number overflow is an auditable event. (Note that this approach to Sequence Number management does not require use of modular arithmetic.) If anti-replay has been disabled, the sender does not need to monitor or reset the counter, e.g., in the case of manual key management (see Section 5). 3.3.4 Integrity Check Value Calculation If authentication is selected for the SA, the sender computes the ICV over the ESP packet minus the Authentication Data. Thus the SPI, Sequence Number, Payload Data, Padding (if present), Pad Length, and Next Header are all encompassed by the ICV computation. Note that the last 4 fields will be in ciphertext form, since encryption is Kent, Atkinson [Page 12] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) performed prior to authentication. 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, (after the Next Header field) 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. Note that MD5 and SHA-1 are viewed as having a 1-byte blocksize because of their internal padding conventions. 3.3.5 Fragmentation If necessary, fragmentation is performed after ESP processing within an IPsec implementation. Thus, transport mode ESP is applied only to whole IP datagrams (not to IP fragments). An IP packet to which ESP has been applied may itself be fragmented by routers en route, and such fragments must be reassembled prior to ESP processing at a receiver. In tunnel mode, ESP is applied to an IP packet, the payload of which may be a fragmented IP packet. For example, a security gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation (as defined in the Security Architecture document) may apply tunnel mode ESP to such fragments. NOTE: For transport mode -- As mentioned at the beginning of Section 3.1, bump-in-the-stack and bump-in-the-wire implementations may have to first reassemble a packet fragmented by the local IP layer, then apply IPsec, and then fragment the resulting packet. NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire implementations, it will be necessary to walk through all the extension headers to determine if there is a fragmentation header and hence that the packet needs reassembling prior to IPsec processing. 3.4 Inbound Packet Processing 3.4.1 Reassembly If required, reassembly is performed prior to ESP processing. If a packet offered to ESP for processing appears to be an IP fragment, i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, Kent, Atkinson [Page 13] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID. NOTE: For packet reassembly, the current IPv4 spec does NOT require either the zero'ing of the OFFSET field or the clearing of the MORE FRAGMENTS flag. In order for a reassembled packet to be processed by IPsec (as opposed to discarded as an apparent fragment), the IP code must do these two things after it reassembles a packet. 3.4.2 Security Association Lookup Upon receipt of a (reassembled) packet containing an ESP Header, the receiver determines the appropriate (unidirectional) SA, based on the destination IP address, security protocol (ESP), and the SPI. (This process is described in more detail in the Security Architecture document.) The SA indicates whether the Sequence Number field will be checked, whether the Authentication Data field 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 packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the cleartext Flow ID. 3.4.3 Sequence Number Verification All ESP implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. This service MUST NOT be enabled unless the authentication service also is enabled for the SA, since otherwise the Sequence Number field has not been integrity protected. (Note that there are no provisions for managing transmitted Sequence Number values among multiple senders directing traffic to a single SA (irrespective of whether the destination address is unicast, broadcast, or multicast). Thus the anti-replay service SHOULD NOT be used in a multi-sender environment that employs a single SA.) If the receiver does not enable anti-replay for an SA, no inbound checks are performed on the Sequence Number. The default for the sender is that the Sequence Number will be checked at the sender. Hence, if an SA establishment protocol such as ISAKMP/Oakley is employed, the receiver SHOULD notify the sender, during SA establishment, if the receiver will not provide anti-replay Kent, Atkinson [Page 14] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) protection. If the receiver has enabled the anti-replay service for this SA, the receive packet counter for the SA MUST be initialized to zero when the SA is established. For each received packet, 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 ESP 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.) A MINIMUM window size of 32 MUST be supported; but a window size of 64 is preferred and SHOULD be employed as the default. Another window size (larger than the MINIMUM) MAY be chosen by the receiver. (The receiver does NOT notify the sender of the window size.) The "right" edge of the window represents the highest, validated Sequence Number 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 the Security Architecture document. If the received packet falls within the window and is new, or if the packet is to the right of the window, then the receiver proceeds to ICV verification. If the ICV validation fails, the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, the Sequence Number, and (in IPv6) the Flow ID. The receive window is updated only if the ICV verification succeeds. DISCUSSION: Note that if the packet is either inside the window and new, or is outside the window on the "right" side, the receiver MUST authenticate the packet before updating the Sequence Number window data. Kent, Atkinson [Page 15] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) 3.4.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; this is an auditable event. The log data SHOULD include the SPI value, date/time received, Source Address, Destination Address, and (in IPv6) the cleartext Flow ID. 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 saved value, using the comparison rules defined by the algorithm specification. (For example, if a digital signature and one-way hash are used for the ICV computation, the matching process is more complex.) 3.4.5 Packet Decryption The receiver: 1. decrypts the ESP Payload Data, Padding, Pad Length, and Next Header using the key, encryption algorithm, algorithm mode, and cryptographic synchronization data (if any), indicated by the SA. - If explicit cryptographic synchronization data, e.g., an IV, is indicated, it is taken from the Payload field and input to the decryption algorithm as per the algorithm specification. - If implicit cryptographic synchronization data, e.g., an IV, is indicated, a local version of the IV is constructed and input to the decryption algorithm as per the algorithm specification. 2. processes any padding as specified in the encryption algorithm specification. The default action is to remove/ignore any padding. Kent, Atkinson [Page 16] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) 3. reconstructs the original IP datagram from: - for transport mode -- original IP header plus the original upper layer protocol information in the ESP Payload field - for tunnel mode -- tunnel IP header + the entire IP datagram in the ESP Payload field. The exact steps for reconstructing the original datagram depend on the mode (transport or tunnel) and are described in the Security Architecture document. At a minimum, in an IPv6 context, the receiver SHOULD ensure that the decrypted data is 8-byte aligned, to facilitate processing by the protocol identified in the Next Header field. If authentication has been selected, verification and decryption MAY be performed serially or in parallel. If performed serially, then ICV verification SHOULD be performed first. If performed in parallel, verification MUST be completed before the decrypted packet is passed on for further processing. 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. Note: If the receiver performs decryption in parallel with authentication, care must be taken to avoid possible race conditions with regard to packet access and reconstruction of the decrypted packet. Note that there are several ways in which the decryption can "fail": a. The selected SA may not be correct -- The SA may be mis-selected due to tampering with the SPI, destination address. or IPsec protocol type fields. Such errors, if they map the packet to another extant SA, will be indistinguishable from a corrupted packet, (case c). Tampering with the SPI can be detected by use of authentication. However, an SA mismatch might still occur due to tampering with the IP Destination Address or the IPsec protocol type field. b. The pad length or pad values could be erroneous -- Bad pad lengths or pad values can be detected irrespective of the use of authentication. c. The encrypted ESP packet could be corrupted -- This can be detected if authentication is selected for the SA., In case (a) or (c), the erroneous result of the decryption operation (an invalid IP datagram or transport-layer frame) will not Kent, Atkinson [Page 17] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) necessarily be detected by IPsec, and is the responsibility of later protocol processing. 4. Auditing Not all systems that implement ESP will implement auditing. However, if ESP is incorporated into a system that supports auditing, then the ESP implementation MUST also support auditing and MUST allow a system administrator to enable or disable auditing for ESP. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in this specification and for each of these events a minimum set of information that SHOULD be included in an audit log is defined. Additional information also MAY be included in the audit log for each of these events, and additional events, not explicitly called out in this specification, also MAY result in audit log entries. There is no requirement for the receiver to transmit any message to the purported sender in response to the detection of an auditable event, because of the potential to induce denial of service via such action. 5. 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 document. If the key used to compute an ICV is manually distributed, correct provision of the anti-replay service would require correct maintenance of the counter state at the sender, until the key is replaced, and there likely would be no automated recovery provision if counter overflow were imminent. Thus a compliant implementation SHOULD NOT provide this service in conjunction with SAs that are manually keyed. A compliant ESP implementation MUST support the following mandatory-to-implement algorithms: - DES in CBC mode [MD97] - HMAC with MD5 [MG97a] - HMAC with SHA-1 [MG97b] 6. Security Considerations Security is central to the design of this protocol, and thus security considerations permeate the specification. Additional security- relevant aspects of using the IPsec protocol are discussed in the Security Architecture document. Kent, Atkinson [Page 18] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) 7. Differences from RFC 1827 This document differs from RFC 1827 [ATK95] in several significant ways. The major difference is that, this document attempts to specify a complete framework and context for ESP, whereas RFC 1827 provided a "shell" that was completed through the definition of transforms. The combinatorial growth of transforms motivated the reformulation of the ESP specification as a more complete document, with options for security services that may be offered in the context of ESP. Thus, fields previously defined in transform documents are now part of this base ESP specification. For example, the fields necessary to support authentication (and anti-replay) are now defined here, even though the provision of this service is an option. The fields used to support padding for encryption, and for next protocol identification, are now defined here as well. Packet processing consistent with the definition of these fields also is included in the document. 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 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 Karen Seo for providing extensive help in the review, editing, background research, and coordination for this version of the specification. The authors would also 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, Norman Shulman, William Simpson and Nina Yuan. References [ATK95] R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 1827, August 1997. [Bel96] Steven M. Bellovin, "Problem Areas for the IP Security Protocols", Proceedings of the Sixth Usenix Unix Security Kent, Atkinson [Page 19] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) Symposium, July, 1996. [Bra97] S. Bradner, "Key words for use in RFCs to Indicate Requirement Level," RFC-2119, March 1997. [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. [KA97a] Steve Kent, Randall Atkinson, "Security Architecture for the Internet Protocol", Internet Draft, February 1998. [KA97b] Steve Kent, Randall Atkinson, "IP Authentication Header", Internet Draft, February 1998. [MD97] C. Madson & N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", Internet Draft, Deceber 1997. [MG97a] C. Madson & R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", Internet Draft, November 1997. [MG97b] C. Madson & R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", Internet Draft, November 1997. [STD-2] J. Reynolds and J. Postel, "Assigned Numbers", STD-2, 20 October 1994. [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. 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. Kent, Atkinson [Page 20] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) Author Information Stephen Kent BBN Corporation 70 Fawcett Street Cambridge, MA 02140 USA E-mail: kent@bbn.com Telephone: +1 (617) 873-3988 Randall Atkinson @Home Network 425 Broadway, Redwood City, CA 94063 USA E-mail: rja@inet.org Copyright (C) The Internet Society (February 1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Kent, Atkinson [Page 21] ----- End of forwarded messages From owner-ipsec Fri Feb 13 15:52:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA26371 for ipsec-outgoing; Fri, 13 Feb 1998 15:52:42 -0500 (EST) Message-Id: <199802132052.PAA26371@portal.ex.tis.com> Date: Fri, 13 Feb 98 15:38:06 EST From: Karen Seo To: ipsec@tis.com Subject: Internet Draft -- IPsec AH spec Sender: owner-ipsec@ex.tis.com Precedence: bulk Network Working Group Stephen Kent, BBN Corp Internet Draft Randall Atkinson, @Home Network draft-ietf-ipsec-auth-header-04.txt February 1998 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 IPsec Working Group. 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. Copyright (C) The Internet Society (February 1998). All Rights Reserved. Kent, Atkinson [Page 1] Internet Draft IP Authentication Header February 1998 Table of Contents 1. Introduction......................................................3 2. Authentication Header Format......................................4 2.1 Next Header...................................................4 2.2 Payload Length................................................4 2.3 Reserved......................................................5 2.4 Security Parameters Index (SPI)...............................5 2.5 Sequence Number...............................................5 2.6 Authentication Data ..........................................6 3. Authentication Header Processing..................................6 3.1 Authentication Header Location...............................6 3.2 Authentication Algorithms....................................8 3.3 Outbound Packet Processing...................................8 3.3.1 Security Association Lookup.............................9 3.3.2 Sequence Number Generation..............................9 3.3.3 Integrity Check Value Calculation.......................9 3.3.3.1 Handling Mutable Fields...........................10 3.3.3.1.1 ICV Computation for IPv4.....................10 3.3.3.1.1.1 Base Header Fields.......................10 3.3.3.1.1.2 Options..................................11 3.3.3.1.2 ICV Computation for IPv6.....................11 3.3.3.1.2.1 Base Header Fields.......................11 3.3.3.1.2.2 Extension Headers -- Options.............12 3.3.3.1.2.3 Extension Headers -- non-Options.........12 3.3.3.2 Padding...........................................12 3.3.3.2.1 Authentication Data Padding..................12 3.3.3.2.2 Implicit Packet Padding......................13 3.3.4 Fragmentation..........................................13 3.4 Inbound Packet Processing...................................13 3.4.1 Reassembly.............................................13 3.4.2 Security Association Lookup............................14 3.4.3 Sequence Number Verification...........................14 3.4.4 Integrity Check Value Verification.....................15 4. Auditing.........................................................16 5. Conformance Requirements.........................................16 6. Security Considerations..........................................17 7. Differences from RFC 1826........................................17 Acknowledgements....................................................17 Appendix A -- Mutability of IP Options/Extension Headers............19 A1. IPv4 Options.................................................19 A2. IPv6 Extension Headers.......................................20 References..........................................................22 Disclaimer..........................................................22 Author Information..................................................22 Kent, Atkinson [Page 2] Internet Draft IP Authentication Header February 1998 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, by the receiver, when a Security Association is established. (Although the default calls for the sender to increment the Sequence Number used for anti-replay, the service is effective only if the receiver checks the Sequence Number.) 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 sender. 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 "Security Architecture for the Internet Protocol" [KA97a], hereafter referred to as the Security Architecture document). 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 a confidentiality (encryption) service. The primary difference between the authentication provided by ESP and AH is the extent of the coverage. Specifically, ESP does not protect any IP header fields unless those fields are encapsulated by ESP (tunnel mode). For more details on how to use AH and ESP in various network environments, see the Security Architecture document [KA97a]. It is assumed that the reader is familiar with the terms and concepts described in the Security Architecture document. In particular, the reader should be familiar with the definitions of security services offered by AH and ESP, the concept of Security Associations, the ways in which AH can be used in conjunction with ESP, and the different key management options available for AH and ESP. (With regard to the last topic, the current key management options required for both AH and ESP are manual keying and automated keying via ISAKMP/Oakley.) The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [Bra97]. Kent, Atkinson [Page 3] Internet Draft IP Authentication Header February 1998 2. Authentication Header Format The protocol header (IPv4, IPv6, or Extension) immediately preceding the AH header will contain the value 51 in its Protocol (IPv4) or Next Header (IPv6, Extension) field [STD-2]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Payload Len | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Authentication Data (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following subsections define the fields that comprise the AH format. All the fields described here are mandatory, i.e., they are always present in the AH format and are included in the Integrity Check Value (ICV) computation (see Sections 2.6 and 3.3.3). 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). 2.2 Payload Length This 8-bit field specifies the length of AH in 32-bit words (4-byte units), minus "2". (All IPv6 extension headers, as per RFC 1883, encode the "Hdr Ext Len" field by first subtracting 1 (64-bit word) from the header length (measured in 64-bit words). AH is an IPv6 extension header. However, since its length is measured in 32-bit words, the "Payload Length" is calculated by subtracting 2 (32 bit words).) In the "standard" case of a 96-bit authentication value plus the 3 32-bit word fixed portion, this length field will be "4". A "null" authentication algorithm may be used only for debugging purposes. Its use would result in a "1" value for this field for IPv4 or a "2" for IPv6, as there would be no corresponding Authentication Data field (see Section 3.3.3.2.1 on "Authentication Kent, Atkinson [Page 4] Internet Draft IP Authentication Header February 1998 Data Padding"). 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.) 2.4 Security Parameters Index (SPI) The SPI is an arbitrary 32-bit value that, in combination with the destination IP address and security protocol (AH), uniquely identifies the Security Association for this datagram. 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. It is ordinarily selected by the destination system upon establishment of an SA (see the Security Architecture document for more details). The SPI value of zero (0) is reserved for local, implementation- specific use and MUST NOT be sent on the wire. For example, a key management implementation MAY use the zero SPI value to mean "No Security Association Exists" during the period when the IPsec implementation has requested that its key management entity establish a new SA, but the SA has not yet been established. 2.5 Sequence Number This unsigned 32-bit field contains a monotonically increasing counter value (sequence number). It is mandatory and is always present even if the receiver does not elect to enable the anti-replay service for a specific SA. Processing of the Sequence Number field is at the discretion of the receiver, i.e., the sender MUST always transmit this field, but the receiver need not act upon it (see the discussion of Sequence Number Verification in the "Inbound Packet Processing" section below). The sender's counter and the receiver's counter are initialized to 0 when an SA is established. (The first packet sent using a given SA will have a Sequence Number of 1; see Section 3.3.2 for more details on how the Sequence Number is generated.) If anti-replay is enabled (the default), the transmitted Sequence Number must never be allowed to cycle. Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA. Kent, Atkinson [Page 5] Internet Draft IP Authentication Header February 1998 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.3.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 below. The authentication algorithm specification MUST specify the length of the ICV and the comparison rules and processing steps for validation. 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, note that for "bump-in- the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document, inbound and outbound IP fragments may require an IPsec implementation to perform extra IP reassembly/fragmentation in order to both conform to this specification and provide transparent IPsec support. Special care is required to perform such operations within these implementations when multiple interfaces are in use.) In transport mode, AH is inserted after the IP header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other IPsec headers that have already been inserted. 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. Kent, Atkinson [Page 6] Internet Draft IP Authentication Header February 1998 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. BEFORE APPLYING AH --------------------------------------- IPv6 | | ext hdrs | | | | orig IP hdr |if present| TCP | Data | --------------------------------------- AFTER APPLYING AH ------------------------------------------------------------ IPv6 | |hop-by-hop, dest*, | | dest | | | |orig IP hdr |routing, fragment. | AH | opt* | TCP | Data | ------------------------------------------------------------ |<---- authenticated except for mutable fields ----------->| * = if present, could be before AH, after AH, or both ESP and AH headers can be combined in a variety of modes. The IPsec Architecture document describes the combinations of security associations that must be supported. Tunnel mode AH may be employed in either hosts or security gateways (or in so-called "bump-in-the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document). When AH is implemented in a security gateway (to protect 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 Kent, Atkinson [Page 7] Internet Draft IP Authentication Header February 1998 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 -->| | in the new IP hdr | -------------------------------------------------------------- IPv6 | | ext hdrs*| | | ext hdrs*| | | |new IP hdr*|if present| AH |orig IP hdr*|if present|TCP|Data| -------------------------------------------------------------- |<-- authenticated except for mutable fields in new IP hdr ->| * = construction of outer IP hdr/extensions and modification of inner IP hdr/extensions is discussed below. 3.2 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 appropriate, though performance and space considerations currently preclude use of such algorithms. The mandatory-to-implement authentication algorithms are described in Section 5 "Conformance Requirements". Other algorithms MAY be supported. 3.3 Outbound Packet Processing In transport mode, the sender 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 Security Architecture document. If there is more than one IPsec header/extension required, the order of the application of the security headers MUST be defined by security policy. For simplicity of processing, each IPsec header Kent, Atkinson [Page 8] Internet Draft IP Authentication Header February 1998 SHOULD ignore the existence (i.e., not zero the contents or try to predict the contents) of IPsec headers to be applied later. (While a native IP or bump-in-the-stack implementation could predict the contents of later IPsec headers that it applies itself, it won't be possible for it to predict any IPsec headers added by a bump-in-the- wire implementation between the host and the network.) 3.3.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 Security Architecture document. 3.3.2 Sequence Number Generation The sender's counter is initialized to 0 when an SA is established. The sender increments the Sequence Number for this SA and inserts the new value into the Sequence Number Field. Thus the first packet sent using a given SA will have a Sequence Number of 1. If anti-replay is enabled (the default), the sender checks to ensure that the counter has not cycled before inserting the new value in the Sequence Number field. In other words, the sender MUST not send a packet on an SA if doing so would cause the Sequence Number to cycle. An attempt to transmit a packet that would result in Sequence Number overflow is an auditable event. (Note that this approach to Sequence Number management does not require use of modular arithmetic.) If anti-replay has been disabled, the sender does not need to monitor or reset the counter, e.g., in the case of manual key management. 3.3.3 Integrity Check Value Calculation The AH ICV is computed over: o IP header fields that are either immutable in transit or that are predictable in value upon arrival at the endpoint for the AH SA o the AH header (Next Header, Payload Len, Reserved, SPI, Sequence Number, and the Authentication Data (which is set to zero for this computation)) o the upper level protocol data, which is assumed to be immutable in transit Kent, Atkinson [Page 9] Internet Draft IP Authentication Header February 1998 3.3.3.1 Handling Mutable Fields If a field may be 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 is also 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. Also, the zero-fill approach ensures that the length of the fields that are so handled cannot be changed during transit, even though their contents are not explicitly covered by the ICV. As a new extension header or IPv4 option is created, it will be defined in its own RFC and SHOULD include (in the Security Considerations section) directions for how it should be handled when calculating the AH ICV. If the IPsec implementation encounters an extension header that it does not recognize, it MUST zero the whole header except for the Next Header and Hdr Ext Len fields. The length of the extension header MUST be computed by 8 * Hdr Ext Len value + 8. If the IPsec implementation encounters an IPv4 option that it does not recognize, it should zero the whole option, using the second byte of the option as the length. (IPv6 options contain a flag indicating mutability, which determines appropriate processing for such options.) 3.3.3.1.1 ICV Computation for IPv4 3.3.3.1.1.1 Base Header Fields The IPv4 base header fields are classified as follows: Immutable Version Internet Header Length Total Length Identification Protocol (This should be the value for AH.) Source Address Destination Address (without loose or strict source routing) Mutable but predictable Destination Address (with loose or strict source routing) Kent, Atkinson [Page 10] Internet Draft IP Authentication Header February 1998 Mutable (zeroed prior to ICV calculation) Type of Service (TOS) Flags Fragment Offset Time to Live (TTL) Header Checksum TOS -- This field is excluded 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. Flags -- This field is excluded since an intermediate router might set the DF bit, even if the source did not select it. Fragment Offset -- Since AH is applied only to non-fragmented IP packets, the Offset Field must always be zero, and thus it is excluded (even though it is predictable). TTL -- This is changed en-route as a normal course of processing by routers, and thus its value at the receiver is not predictable by the sender. Header Checksum -- This will change if any of these other fields changes, and thus its value upon reception cannot be predicted by the sender. 3.3.3.1.1.2 Options For IPv4 (unlike IPv6), there is no mechanism for tagging options as mutable in transit. Hence the IPv4 options are explicitly listed in Appendix A and classified as immutable, mutable but predictable, or mutable. For IPv4, the entire option is viewed as a unit; so even though the 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. 3.3.3.1.2 ICV Computation for IPv6 3.3.3.1.2.1 Base Header Fields The IPv6 base header fields are classified as follows: Immutable Version Payload Length Next Header (This should be the value for AH.) Source Address Destination Address (without Routing Extension Header) Kent, Atkinson [Page 11] Internet Draft IP Authentication Header February 1998 Mutable but predictable Destination Address (with Routing Extension Header) Mutable (zeroed prior to ICV calculation) Class Flow Label Hop Limit 3.3.3.1.2.2 Extension Headers -- Options The IPv6 extension headers (that are options) are explicitly listed in Appendix A and classified as immutable, mutable but predictable, or mutable. IPv6 options in the Hop-by-Hop and Destination Extension Headers contain a bit that indicates whether the option might change (unpredictably) 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 options for which the bit indicates immutability are included in the ICV calculation. See the IPv6 specification [DH95] for more information. 3.3.3.1.2.3 Extension Headers -- non-Options The IPv6 extension headers (that are not options) are explicitly listed in Appendix A and classified as immutable, mutable but predictable, or mutable. 3.3.3.2 Padding 3.3.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 two factors: - the length of the ICV - the IP protocol version (v4 or v6) For example, if the output of the selected algorithm is 96-bits, no padding is required for either IPv4 or for IPv6. However, if a different length ICV is generated, due to use of a different algorithm, then padding may be required depending on the length and IP protocol version. The content of the padding field is arbitrarily Kent, Atkinson [Page 12] Internet Draft IP Authentication Header February 1998 selected by the sender. (The padding is arbitrary, but need not be random to achieve security.) These padding 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.3.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. Note that MD5 and SHA-1 are viewed as having a 1-byte blocksize because of their internal padding conventions. 3.3.4 Fragmentation If required, IP fragmentation occurs after AH processing within an IPsec implementation. Thus, transport mode AH is applied only to whole IP datagrams (not to IP fragments). An IP packet to which AH has been applied may itself be fragmented by routers en route, and such fragments must be reassembled prior to AH processing at a receiver. In tunnel mode, AH is applied to an IP packet, the payload of which may be a fragmented IP packet. For example, a security gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation (see the Security Architecture document for details) may apply tunnel mode AH to such fragments. 3.4 Inbound Packet Processing If there is more than one IPsec header/extension present, the processing for each one ignores (does not zero, does not use) any IPsec headers applied subsequent to the header being processed. 3.4.1 Reassembly If required, reassembly is performed prior to AH processing. If a packet offered to AH for processing appears to be an IP fragment, i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID. Kent, Atkinson [Page 13] Internet Draft IP Authentication Header February 1998 NOTE: For packet reassembly, the current IPv4 spec does NOT require either the zero'ing of the OFFSET field or the clearing of the MORE FRAGMENTS flag. In order for a reassembled packet to be processed by IPsec (as opposed to discarded as an apparent fragment), the IP code must do these two things after it reassembles a packet. 3.4.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, security protocol (AH), and the SPI. (This process is described in more detail in the Security Architecture document.) The SA indicates whether the Sequence Number field will be checked, specifies the algorithm(s) employed for ICV computation, and indicates 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; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID. 3.4.3 Sequence Number Verification All AH implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. (Note that there are no provisions for managing transmitted Sequence Number values among multiple senders directing traffic to a single SA (irrespective of whether the destination address is unicast, broadcast, or multicast). Thus the anti-replay service SHOULD NOT be used in a multi-sender environment that employs a single SA.) If the receiver does not enable anti-replay for an SA, no inbound checks are performed on the Sequence Number. The default for the sender is that the Sequence Number will be checked at the sender. Hence, if an SA establishment protocol such as ISAKMP/Oakley is employed, the receiver SHOULD notify the sender, during SA establishment, if the receiver will not provide anti-replay protection. If the receiver has enabled the anti-replay service for this SA, the receiver packet counter for the SA MUST be initialized to zero when the SA is established. For each received packet, 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 14] Internet Draft IP Authentication Header February 1998 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.) A MINIMUM window size of 32 MUST be supported; but a window size of 64 is preferred and SHOULD be employed as the default. Another window size (larger than the MINIMUM) MAY be chosen by the receiver. (The receiver does NOT notify the sender of the window size.) The "right" edge of the window represents the highest, validated Sequence Number 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 the Security Architecture document. If the received packet falls within the window and is new, or if the packet is to the right of the window, then the receiver proceeds to ICV verification. If the ICV validation fails, the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, the Sequence Number, and (in IPv6) the Flow ID. The receive window is updated only if the ICV verification succeeds. DISCUSSION: Note that if the packet is either inside the window and new, or is outside the window on the "right" side, the receiver MUST authenticate the packet before updating the Sequence Number window data. 3.4.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; this is an auditable event. The audit log entry SHOULD include the SPI value, date/time received, Source Address, Destination Address, and (in IPv6) the Flow ID. DISCUSSION: Kent, Atkinson [Page 15] Internet Draft IP Authentication Header February 1998 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.3.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. Perform the ICV computation and compare the result with the saved value, using the comparison rules defined by the algorithm specification. (For example, if a digital signature and one-way hash are used for the ICV computation, the matching process is more complex.) 4. Auditing Not all systems that implement AH will implement auditing. However, if AH is incorporated into a system that supports auditing, then the AH implementation MUST also support auditing and MUST allow a system administrator to enable or disable auditing for AH. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in this specification and for each of these events a minimum set of information that SHOULD be included in an audit log is defined. Additional information also MAY be included in the audit log for each of these events, and additional events, not explicitly called out in this specification, also MAY result in audit log entries. There is no requirement for the receiver to transmit any message to the purported sender in response to the detection of an auditable event, because of the potential to induce denial of service via such action. 5. 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 document. If the key used to compute an ICV is manually distributed, correct provision of the anti-replay service would require correct maintenance of the counter state at the sender, until the key is replaced, and there likely would be no automated recovery provision if counter overflow were imminent. Thus a compliant implementation SHOULD NOT provide this service in conjunction with SAs that are manually keyed. A compliant AH implementation MUST support the following mandatory-to-implement algorithms: Kent, Atkinson [Page 16] Internet Draft IP Authentication Header February 1998 - HMAC with MD5 [MG97a] - HMAC with SHA-1 [MG97b] 6. Security Considerations Security is central to the design of this protocol, and these security considerations permeate the specification. Additional security-relevant aspects of using the IPsec protocol are discussed in the Security Architecture document. 7. Differences from RFC 1826 This specification of AH differs from RFC 1826 [ATK95] in several important respects, but the fundamental features of AH remain intact. One goal of the revision of RFC 1826 was to provide a complete framework for AH, with ancillary RFCs required only for algorithm specification. For example, the anti-replay service is now an integral, mandatory part of AH, not a feature of a transform defined in another RFC. Carriage of a sequence number to support this service is now required at all times. The default algorithms required for interoperability have been changed to HMAC with MD5 or SHA-1 (vs. keyed MD5), for security reasons. The list of IPv4 header fields excluded from the ICV computation has been expanded to include the OFFSET and FLAGS fields. Another motivation for revision was to provide additional detail and clarification of subtle points. This specification provides rationale for exclusion of selected IPv4 header fields from AH coverage and provides examples on positioning of AH in both the IPv4 and v6 contexts. Auditing requirements have been clarified in this version of the specification. Tunnel mode AH was mentioned only in passing in RFC 1826, but now is a mandatory feature of AH. Discussion of interactions with key management and with security labels have been moved to the Security Architecture document. 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 Karen Seo for providing extensive help in the review, editing, background research, and coordination for this version of the specification. The authors would also like to thank the members of the IPsec and IPng working groups, with special mention of the efforts of (in alphabetic order): Kent, Atkinson [Page 17] Internet Draft IP Authentication Header February 1998 Steve Bellovin, Steve Deering, Francis Dupont, Phil Karn, Frank Kastenholz, Perry Metzger, David Mihelcic, Hilarie Orman, Norman Shulman, William Simpson, and Nina Yuan. Kent, Atkinson [Page 18] Internet Draft IP Authentication Header February 1998 Appendix A -- Mutability of IP Options/Extension Headers A1. IPv4 Options This table shows how the IPv4 options are classified with regard to "mutability". Where two references are provided, the second one supercedes the first. This table is based in part on information provided in RFC1700, "ASSIGNED NUMBERS", (October 1994). Opt. Copy Class # Name Reference ---- ----- --- ------------------------- --------- IMMUTABLE -- included in ICV calculation 0 0 0 End of Options List [RFC791] 0 0 1 No Operation [RFC791] 1 0 2 Security [RFC1108(historic but in use)] 1 0 5 Extended Security [RFC1108(historic but in use)] 1 0 6 Commercial Security [expired I-D, now US MIL STD] 1 0 20 Router Alert [RFC2113] 1 0 21 Sender Directed Multi- [RFC1770] Destination Delivery MUTABLE -- zeroed 1 0 3 Loose Source Route [RFC791] 0 2 4 Time Stamp [RFC791] 0 0 7 Record Route [RFC791] 1 0 9 Strict Source Route [RFC791] 0 2 18 Traceroute [RFC1393] EXPERIMENTAL, SUPERCEDED -- zeroed 1 0 8 Stream ID [RFC791, RFC1122 (Host Req)] 0 0 11 MTU Probe [RFC1063, RFC1191 (PMTU)] 0 0 12 MTU Reply [RFC1063, RFC1191 (PMTU)] 1 0 17 Extended Internet Protocol [RFC1385, RFC1883 (IPv6)] 0 0 10 Experimental Measurement [ZSu] 1 2 13 Experimental Flow Control [Finn] 1 0 14 Experimental Access Ctl [Estrin] 0 0 15 ??? [VerSteeg] 1 0 16 IMI Traffic Descriptor [Lee] 1 0 19 Address Extension [Ullmann IPv7] NOTE: Use of the Router Alert option is potentially incompatible with use of IPsec. Although the option is immutable, its use implies that each router along a packet's path will "process" the packet and consequently might change the packet. This would happen on a hop by hop basis as the packet goes from router to router. Prior to being processed by the application to which the option contents are directed, e.g., RSVP/IGMP, the packet should encounter AH processing. Kent, Atkinson [Page 19] Internet Draft IP Authentication Header February 1998 However, AH processing would require that each router along the path is a member of a multicast-SA defined by the SPI. This might pose problems for packets that are not strictly source routed, and it requires multicast support techniques not currently available. NOTE: Addition or removal of any security labels (BSO, ESO, CIPSO) by systems along a packet's path conflicts with the classification of these IP Options as immutable and is incompatible with the use of IPsec. NOTE: End of Options List options SHOULD be repeated as necessary to ensure that the IP header ends on a 4 byte boundary in order to ensure that there are no unspecified bytes which could be used for a covert channel. A2. IPv6 Extension Headers This table shows how the IPv6 Extension Headers are classified with regard to "mutability". Option/Extension Name Reference ----------------------------------- --------- MUTABLE BUT PREDICTABLE -- included in ICV calculation Routing (Type 0) [RFC1883] BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING TRANSIT) Hop by Hop options [RFC1883] Destination options [RFC1883] NOT APPLICABLE Fragmentation [RFC1883] Options -- IPv6 options in the Hop-by-Hop and Destination Extension Headers contain a bit that indicates whether the option might change (unpredictably) 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 options for which the bit indicates immutability are included in the ICV calculation. See the IPv6 specification [DH95] for more information. Routing (Type 0) -- 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 Kent, Atkinson [Page 20] Internet Draft IP Authentication Header February 1998 included in the Authentication Data calculation as mutable but predictable. The sender must order the field so that it appears as it will at the receiver, prior to performing the ICV computation. Fragmentation -- Fragmentation occurs after outbound IPsec processing (section 3.3) and reassembly occurs before inbound IPsec processing (section 3.4). So the Fragmentation Extension Header, if it exists, is not seen by IPsec. Note that on the receive side, the IP implementation could leave a Fragmentation Extension Header in place when it does re-assembly. If this happens, then when AH receives the packet, before doing ICV processing, AH MUST "remove" (or skip over) this header and change the previous header's "Next Header" field to be the "Next Header" field in the Fragmentation Extension Header. Note that on the send side, the IP implementation could give the IPsec code a packet with a Fragmentation Extension Header with Offset of 0 (first fragment) and a More Fragments Flag of 0 (last fragment). If this happens, then before doing ICV processing, AH MUST first "remove" (or skip over) this header and change the previous header's "Next Header" field to be the "Next Header" field in the Fragmentation Extension Header. Kent, Atkinson [Page 21] Internet Draft IP Authentication Header February 1998 References [ATK95] R. Atkinson, "The IP Authentication Header," RFC 1826, August 1995. [Bra97] S. Bradner, "Key words for use in RFCs to Indicate Requirement Level," RFC-2119, March 1997. [DH95] Steve Deering & Bob Hinden, "Internet Protocol version 6 (IPv6) Specification", RFC-1883, December 1995. [KA97a] Steve Kent, Randall Atkinson, "Security Architecture for the Internet Protocol", Internet Draft, February, 1998. [KA97b] Steve Kent, Randall Atkinson, "IP Encapsulating Security Payload (ESP)", Internet Draft, February 1998. [MG97a] C. Madson & R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", Internet Draft, November 1997. [MG97b] C. Madson & R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", Internet Draft, November 1997. [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 E-mail: kent@bbn.com Telephone: +1 (617) 873-3988 Kent, Atkinson [Page 22] Internet Draft IP Authentication Header February 1998 Randall Atkinson @Home Network 425 Broadway, Redwood City, CA 94063 USA E-mail: rja@inet.org Copyright (C) The Internet Society (February 1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Kent, Atkinson [Page 23] ----- End of forwarded messages From owner-ipsec Fri Feb 13 16:19:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA26533 for ipsec-outgoing; Fri, 13 Feb 1998 16:19:45 -0500 (EST) Date: Fri, 13 Feb 1998 16:32:39 -0500 (EST) Message-Id: <199802132132.QAA22073@carp.morningstar.com> From: Ben Rogers Reply-To: ben@ascend.com (Ben Rogers) To: dharkins@cisco.com, ipsec@tis.com Subject: Deriviation of Phase 1 keying material Sender: owner-ipsec@ex.tis.com Precedence: bulk >From IO-RES Appendix B: Encryption keys used to protect the ISAKMP SA are derived from SKEYID_e in an algorithm-specific manner. When SKEYID_e is not long enough to supply all the necessary keying material an algorithm requires, the key is derived from feeding the results of a pseudo- random function into itself, concatenating the results, and taking the highest necessary bits. For example, if (ficticious) algorithm AKULA requires 320-bits of key (and has no weak key check) and the prf used to generate SKEYID_e only generates 120 bits of material, the key for AKULA, would be the first 320-bits of Ka, where: Ka = K1 | K2 | K3 and K1 = prf(SKEYID_e, 0) K2 = prf(SKEYID_e, K1) K3 = prf(SKEYID_e, K2) I'm not really clear as to what we do if SKEYID_e has enough bits to provide us with the encryption key we're looking for. Perhaps one of the following clarifications is appropriate? Encryption keys used to protect the ISAKMP SA are derived from SKEYID_e in an algorithm-specific manner. If SKEYID_e is long enough to supply the necessary keying material the algorithm requires, then it is used without modification. If it is not long enough, the key is derived from feeding the results of a pseudo-random function into itself, concatenating the results, and taking the highest necessary bits. For example,... or Encryption keys used to protect the ISAKMP SA are derived from SKEYID_e in an algorithm-specific manner. The key material is generated by taking the high order bits of the following string K: K = K1 | K2 | K3 | ... where K1 = prf(SKEYID_e, 0) KN+1 = prf(SKEYID_e, KN) and 0 is represented by a single octet. For example, if (ficticious) algorithm AKULA requires 320-bits of key (and has no weak key check) and the prf used to generate SKEYID_e only generates 120 bits of material, the key for AKULA, would be the first 320-bits of Ka, where: Ka = K1 | K2 | K3 and K1 = prf(SKEYID_e, 0) K2 = prf(SKEYID_e, K1) K3 = prf(SKEYID_e, K2) where prf is the negotiated prf or the HMAC version of the negotiated hash function. Each result of the prf provides 120 bits of material for a total of 360 bits. AKULA would use the first 320 bits of that 360 bit string. I'm also not certain to do in the case where the first 8 bytes of this keystring are weak. Do we instead take bytes 1-9, or bytes 9-16? Does anyone see the need to include the weak key check in 3DES-CBC? If so, do we not allow keys for which any of the DES keys is weak, or only keys where all three are weak? If the first is the case, shold we allow non-contiguous keys? (ie, if bytes 9-16 are a weak key, do I build my 3DES key from bytes 1-8, 17-24 and 25-32, or take the contiguous block of bytes 17-40 or 25-48?) ben --QAA06833.887405184/relay.hq.tis.com-- From owner-ipsec Fri Feb 13 17:33:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA00382 for ipsec-outgoing; Fri, 13 Feb 1998 17:33:41 -0500 (EST) Date: Fri, 13 Feb 1998 17:46:33 -0500 (EST) Message-Id: <199802132246.RAA22250@carp.morningstar.com> From: Ben Rogers To: dharkins@cisco.com, ipsec@tis.com Subject: Deriviation of Phase 1 keying material Reply-To: ben@ascend.com (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk [I appologize if this as a re-send -- my mailer is confused .. ben] >From IO-RES Appendix B: Encryption keys used to protect the ISAKMP SA are derived from SKEYID_e in an algorithm-specific manner. When SKEYID_e is not long enough to supply all the necessary keying material an algorithm requires, the key is derived from feeding the results of a pseudo- random function into itself, concatenating the results, and taking the highest necessary bits. For example, if (ficticious) algorithm AKULA requires 320-bits of key (and has no weak key check) and the prf used to generate SKEYID_e only generates 120 bits of material, the key for AKULA, would be the first 320-bits of Ka, where: Ka = K1 | K2 | K3 and K1 = prf(SKEYID_e, 0) K2 = prf(SKEYID_e, K1) K3 = prf(SKEYID_e, K2) I'm not really clear as to what we do if SKEYID_e has enough bits to provide us with the encryption key we're looking for. Perhaps one of the following clarifications is appropriate? Encryption keys used to protect the ISAKMP SA are derived from SKEYID_e in an algorithm-specific manner. If SKEYID_e is long enough to supply the necessary keying material the algorithm requires, then it is used without modification. If it is not long enough, the key is derived from feeding the results of a pseudo-random function into itself, concatenating the results, and taking the highest necessary bits. For example,... or Encryption keys used to protect the ISAKMP SA are derived from SKEYID_e in an algorithm-specific manner. The key material is generated by taking the high order bits of the following string K: K = K1 | K2 | K3 | ... where K1 = prf(SKEYID_e, 0) KN+1 = prf(SKEYID_e, KN) and 0 is represented by a single octet. For example, if (ficticious) algorithm AKULA requires 320-bits of key (and has no weak key check) and the prf used to generate SKEYID_e only generates 120 bits of material, the key for AKULA, would be the first 320-bits of Ka, where: Ka = K1 | K2 | K3 and K1 = prf(SKEYID_e, 0) K2 = prf(SKEYID_e, K1) K3 = prf(SKEYID_e, K2) where prf is the negotiated prf or the HMAC version of the negotiated hash function. Each result of the prf provides 120 bits of material for a total of 360 bits. AKULA would use the first 320 bits of that 360 bit string. I'm also not certain to do in the case where the first 8 bytes of this keystring are weak. Do we instead take bytes 1-9, or bytes 9-16? Does anyone see the need to include the weak key check in 3DES-CBC? If so, do we not allow keys for which any of the DES keys is weak, or only keys where all three are weak? If the first is the case, shold we allow non-contiguous keys? (ie, if bytes 9-16 are a weak key, do I build my 3DES key from bytes 1-8, 17-24 and 25-32, or take the contiguous block of bytes 17-40 or 25-48?) ben From owner-ipsec Sun Feb 15 04:24:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA10921 for ipsec-outgoing; Sun, 15 Feb 1998 04:24:43 -0500 (EST) Date: Sun, 15 Feb 1998 11:38:53 +0200 (IST) From: Hugo Krawczyk Message-Id: <199802150938.LAA14691@ee.technion.ac.il> To: ipsec@tis.com, rob.glenn@nist.gov Subject: Re: Summary of changes to HMAC-MD5-96 draft Sender: owner-ipsec@ex.tis.com Precedence: bulk Rob, the addition below is not acceptable in the text: > >4. In response to the document reading party's comment: > >>There is a requirment that "any known attacks" be discussed in the >>Security Considerations section. The MD5-96-01 doc does not discuss this. > >The following as added to paragraph 1 of section 5. > >At the time of this writing there are no known cryptographic attacks against >HMAC-MD5-96. Of course, THERE ARE such attacks (exhaustive key recovery attack, MAC guessing attacks, on-line birthday attacks are all cryptographic attacks). Even if they are currently impractical they exist. You should refer to the following text of rfc 2104 or even adapt a part of it to your needs here (I stress that this text does apply to the 96-bit truncated output version used in ipsec). The strongest attack known against HMAC is based on the frequency of collisions for the hash function H ("birthday attack") [PV,BCK2], and is totally impractical for minimally reasonable hash functions. As an example, if we consider a hash function like MD5 where the output length equals L=16 bytes (128 bits) the attacker needs to acquire the correct message authentication tags computed (with the _same_ secret key K!) on about 2**64 known plaintexts. This would require the processing of at least 2**64 blocks under H, an impossible task in any realistic scenario (for a block length of 64 bytes this would take 250,000 years in a continuous 1Gbps link, and without changing the secret key K during all this time). This attack could become realistic only if serious flaws in the collision behavior of the function H are discovered (e.g. collisions found after 2**30 messages). Such a discovery would determine the immediate replacement of the function H (the effects of such failure would be far more severe for the traditional uses of H in the context of digital signatures, public key certificates, etc.). Another part of rfc 2104 that you may want to bring explicitly is: Keys need to be chosen at random (or using a cryptographically strong pseudo-random generator seeded with a random seed), and periodically refreshed. (Current attacks do not indicate a specific recommended frequency for key changes as these attacks are practically infeasible. However, periodic key refreshment is a fundamental security practice that helps against potential weaknesses of the function and keys, and limits the damage of an exposed key.) Hugo > >Rob G. >rob.glenn@nist.gov > > > From owner-ipsec Mon Feb 16 07:21:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA19913 for ipsec-outgoing; Mon, 16 Feb 1998 07:21:43 -0500 (EST) Date: Fri, 13 Feb 1998 17:28:12 -0600 (CST) From: Engineering To: Daniel Harkins cc: ipsec@tis.com Subject: Re: Help - Details on March 2nd worshop at Raliegh requested ... In-Reply-To: <199802131935.LAA22202@dharkins-ss20.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > scenarios then the answer is yes. IPSec and NAT will most likely be tested. This was the answer I was looking for. Thanks, Jeffrey Goodwin ** Ashley Laurent,Inc. ** Software Development ** Consulting ** * * * * 707 West Avenue, Suite 201 * voice: 512-322-0676 * * Austin, Texas 78701 * fax : 512-322-0680 * * web: http://www.osgroup.com * * Microsoft Solution Provider * Complete Systems Design/Development * * Novell Professional Developer * Systems Software/Device Drivers * From owner-ipsec Mon Feb 16 07:22:44 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA19941 for ipsec-outgoing; Mon, 16 Feb 1998 07:22:43 -0500 (EST) Message-Id: <199802132317.PAA22381@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: ipsec@tis.com Subject: I like IKE! Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 Feb 1998 15:17:41 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Changes have been made to the I-O Resolution Document and a new version has been submitted. Changes are: 0. The name has been changed from "The Resolution of ISAKMP with Oakley" to "The Internet Key Exchange (IKE)". 1. Mention that the final Aggressive Mode message need not be transmitted in the clear was added to section 5. 2. The payload explosion incorrectly set the SPI size of an AH offer to 8. It is now 4 octets. section 7.2. 3. A mention was made in Appendix A that the key length attribute MUST NOT be sent in a phase 1 offer when the encryption algorithm uses a fixed key length. 4. Section 5 now clarifies how multiple phase 1 offers are made. They MUST be a single SA payload with a single Proposal payload with possibly many transform payloads. 5. Appendix A incorrectly failed to reserved the value 6 to IANA. This was changed. 6. Added clarification to Appendix A on attribute encoding. Basic attributes MUST NOT be encoded as variable but if an attribute whose type is variable has a value that is small enough, it can be encoded as basic and that does not void the "responder can't change offers" rule. 7. Clarification that offers may not be changed in section 5. 8. Section 5.5 now states that phase 2 offers are logically related and must be consistant. 9. removed references to 3DES-CBC-MAC but left the PRF attribute to be negotiated using private use values until such time as IANA assigns a number. throughout. 10. added an IANA considerations section. So, for your consideration... IKE! Dan. ----------------------------------------------------------------------- IPSEC Working Group D. Harkins, D. Carrel INTERNET-DRAFT cisco Systems draft-ietf-ipsec-isakmp-oakley-06.txt February 1998 The Internet Key Exchange (IKE) Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inapproporiate to use Internet Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet Draft, please check the "1id-abstracts.txt" listing contained in the Internet Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Australia), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Table Of Contents 1 Abstract 2 Discussion 3 Terms and Definitions 3.1 Requirements Terminology 3.2 Notation 3.3 Perfect Forward Secrecty 3.4 Security Association 4 Introduction 5 Exchanges 5.1 Authentication with Digital Signatures 5.2 Authentication with Public Key Encryption 5.3 A Revised method of Authentication with Public Key Encryption 5.4 Authentication with a Pre-Shared Key 5.5 Quick Mode 5.6 New Group Mode 5.7 ISAKMP Informational Exchanges 6 Oakley Groups Harkins, Carrel [Page 1] INTERNET DRAFT February 1998 6.1 First Oakley Group 6.2 Second Oakley Group 6.3 Third Oakley Group 6.4 Fourth Oakley Group 7 Payload Explosion of Complete Exchange 7.1 Phase 1 with Main Mode 7.2 Phase 2 with Quick Mode 8 Perfect Forward Secrecy Example 9 Implementation Hints 10 Security Considerations 11 IANA Considerations 12 Acknowledgments 13 References Appendix A Appendix B 1. Abstract [MSST98] (ISAKMP) provides a framework for authentication and key exchange but does not define them. ISAKMP is designed to be key exchange independant; that is, it is designed to support many different key exchanges. [Orm96] (Oakley) describes a series of key exchanges-- called "modes"-- and details the services provided by each (e.g. perfect forward secrecy for keys, identity protection, and authentication). [Kra96] (SKEME) describes a versatile key exchange technique which provides anonymity, repudiability, and quick key refreshment. This document describes a protocol using part of Oakley and part of SKEME in conjunction with ISAKMP to obtain authenticated keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI. Harkins, Carrel [Page 2] INTERNET DRAFT February 1998 2. Discussion This draft describes a hybrid protocol. The purpose is to negotiate, and provide authenticated keying material for, security associations in a protected manner. Processes which implement this draft can be used for negotiating virtual private networks (VPNs) and also for providing a remote user from a remote site (whose IP address need not be known beforehand) access to a secure host or network. Client negotiation is supported. Client mode is where the negotiating parties are not the endpoints for which security association negotiation is taking place. When used in client mode, the identities of the end parties remain hidden. This does not implement the entire Oakley protocol, but only a subset necessary to satisfy its goals. It does not claim conformance or compliance with the entire Oakley protocol nor is it dependant in any way on the Oakley protocol. Likewise, this does not implement the entire SKEME protocol, but only the method of public key encryption for authentication and its concept of fast re-keying using an exchange of nonces. This protocol is not dependant in any way on the SKEME protocol. 3. Terms and Definitions 3.1 Requirements Terminology Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [Bra97]. 3.2 Notation The following notation is used throughout this draft. HDR is an ISAKMP header whose exchange type is the mode. When writen as HDR* it indicates payload encryption. SA is an SA negotiation payload with one or more proposals. An initiator MAY provide multiple proposals for negotiation; a responder MUST reply with only one.

_b indicates the body of payload

-- the ISAKMP generic payload is not included. Harkins, Carrel [Page 3] INTERNET DRAFT February 1998 SAi_b is the entire body of the SA payload (minus the ISAKMP generic header)-- i.e. the DOI, situation, all proposals and all transforms offered by the Initiator. CKY-I and CKY-R are the Initiator's cookie and the Responder's cookie, respectively, from the ISAKMP header. g^xi and g^xr are the Diffie-Hellman public values of the initiator and responder respectively. g^xy is the Diffie-Hellman shared secret. KE is the key exchange payload which contains the public information exchanged in a Diffie-Hellman exchange. There is no particular encoding used for the data of a KE payload. Nx is the nonce payload; x can be: i or r for the ISAKMP initiator and responder respectively. IDx is the identity payload for "x". x can be: "ii" or "ir" for the ISAKMP initiator and responder respectively during phase one negotiation; or "ui" or "ur" for the user initiator and responder respectively during phase two. The ID payload format for the Internet DOI is defined in [Pip97]. SIG is the signature payload. The data to sign is exchange- specific. CERT is the certificate payload. HASH (and any derivitive such as HASH(2) or HASH_I) is the hash payload. The contents of the hash are specific to the authentication method. prf(key, msg) is the keyed pseudo-random function-- often a keyed hash function-- used to generate a deterministic output that appears pseudo-random. prf's are used both for key derivations and for authentication (i.e. as a keyed MAC). (See [KBC96]). SKEYID is a string derived from secret material known only to the active players in the exchange. SKEYID_e is the keying material used by the ISAKMP SA to protect the confidentiality of its messages. SKEYID_a is the keying material used by the ISAKMP SA to authenticate its messages. Harkins, Carrel [Page 4] INTERNET DRAFT February 1998 SKEYID_d is the keying material used to derive keys for non-ISAKMP security associations. y indicates that "x" is encrypted with the key "y". --> signifies "initiator to responder" communication (requests). <-- signifies "responder to initiator" communication (replies). | signifies concatenation of information-- e.g. X | Y is the concatentation of X with Y. [x] indicates that x is optional. Message encryption (when noted by a '*' after the ISAKMP header) MUST begin immediately after the ISAKMP header. When communication is protected, all payloads following the ISAKMP header MUST be encrypted. Encryption keys are generated from SKEYID_e in a manner that is defined for each algorithm. 3.3 Perfect Forward Secrecy When used in the draft Perfect Forward Secrecy (PFS) refers to the notion that compromise of a single key will permit access to only data protected by a single key. For PFS to exist the key used to protect transmission of data MUST NOT be used to derive any additional keys, and if the key used to protect transmission of data was derived from some other keying material, that material MUST NOT be used to derive any more keys. Perfect Forward Secrecy for both keys and identities is provided in this protocol. (Sections 5.5 and 8). 3.4 Security Association A security association (SA) is a set of policy and key(s) used to protect information. The ISAKMP SA is the shared policy and key(s) used by the negotiating peers in this protocol to protect their communication. 4. Introduction Oakley and SKEME each define a method to establish an authenticated key exchange. This includes payloads construction, the information payloads carry, the order in which they are processed and how they are used. While Oakley defines "modes", ISAKMP defines "phases". The Harkins, Carrel [Page 5] INTERNET DRAFT February 1998 relationship between the two is very straightforward and IKE presents different exchanges as modes which operate in one of two phases. Phase 1 is where the two ISAKMP peers establish a secure, authenticated channel with which to communicate. This is called the ISAKMP Security Association (SA). "Main Mode" and "Aggressive Mode" each accomplish a phase 1 exchange. "Main Mode" and "Aggressive Mode" MUST ONLY be used in phase 1. Phase 2 is where Security Associations are negotiated on behalf of services such as IPsec or any other service which needs key material and/or parameter negotiation. "Quick Mode" accomplishes a phase 2 exchange. "Quick Mode" MUST ONLY be used in phase 2. "New Group Mode" is not really a phase 1 or phase 2. It follows phase 1, but serves to establish a new group which can be used in future negotiations. "New Group Mode" MUST ONLY be used after phase 1. The ISAKMP SA is bi-directional. That is, once established, either party may initiate Quick Mode, Informational, and New Group Mode Exchanges. Per the base ISAKMP document, the ISAKMP SA is identified by the Initiator's cookie followed by the Responder's cookie-- the role of each party in the phase 1 exchange dictates which cookie is the Initiator's. The cookie order established by the phase 1 exchange continues to identify the ISAKMP SA regardless of the direction the Quick Mode, Informational, or New Group exchange. In other words, the cookies MUST NOT swap places when the direction of the ISAKMP SA changes. With the use of ISAKMP phases, an implementation can accomplish very fast keying when necessary. A single phase 1 negotiation may be used for more than one phase 2 negotiation. Additionally a single phase 2 negotiation can request multiple Security Associations. With these optimizations, an implementation can see less than one round trip per SA as well as less than one DH exponentiation per SA. "Main Mode" for phase 1 provides identity protection. When identity protection is not needed, "Aggressive Mode" can be used to reduce round trips even further. Developer hints for doing these optimizations are included below. It should also be noted that using public key encryption to authenticate an Aggressive Mode exchange will still provide identity protection. This protocol does not define its own DOI per se. The ISAKMP SA, established in phase 1, MAY use the DOI and situation from a non- ISAKMP service (such as the IETF IPSec DOI [Pip97]). In this case an implementation MAY choose to restrict use of the ISAKMP SA for establishment of SAs for services of the same DOI. Alternately, an Harkins, Carrel [Page 6] INTERNET DRAFT February 1998 ISAKMP SA MAY be established with the value zero in both the DOI and situation (see [MSST98] for a description of these fields) and in this case implementations will be free to establish security services for any defined DOI using this ISAKMP SA. If a DOI of zero is used for establishment of a phase 1 SA, the syntax of the identity payloads used in phase 1 is that defined in [MSST98] and not from any DOI-- e.g. [Pip97]-- which may further expand the syntax and semantics of identities. The following attributes are used by IKE and are negotiated as part of the ISAKMP Security Association. (These attributes pertain only to the ISAKMP Security Association and not to any Security Associations that ISAKMP may be negotiating on behalf of other services.) - encryption algorithm (e.g. DES, IDEA, Blowfish). - hash algorithm (e.g. MD5, SHA) - authentication method (e.g. DSS sig, RSA sig, RSA encryption, pre-shared key) - information about a group over which to do Diffie-Hellman. All of these attributes are mandatory and MUST be negotiated. In addition, it is possible to optionally negotiate a psuedo-random function ("prf"). (There are currently no negotiable pseudo-random functions defined in this document. Private use attribute values can be used for prf negotiation between consenting parties). If a "prf" is not negotiation, the HMAC (see [KBC96]) version of the negotiated hash algorithm is used as a pseudo-random function. Other non- mandatory attributes are described in Appendix A. The selected hash algorithm MUST support both native and HMAC modes. The Diffie-Hellman group MUST be either specified using a defined group description (section 6) or by defining all attributes of a group (section 5.6). Group attributes (such as group type or prime-- see Appendix A) MUST NOT be offered in conjunction with a previously defined group (either a reserved group description or a private use description that is established after conclusion of a New Group Mode exchange). IKE implementations MUST support the following attribute values: - DES-CBC with a weak, and semi-weak, key check (weak and semi- weak keys are referenced in [Sch96] and listed in Appendix A). The key is derived according to Appendix B. Harkins, Carrel [Page 7] INTERNET DRAFT February 1998 - MD5 and SHA. - Authentication via pre-shared keys. The Digital Signature Standard SHOULD be supported; RSA-- both signatures and authentication with public key encryption-- SHOULD be supported. - MODP over the default group (see below). ECP and EC2N groups MAY be supported. The IKE modes described here MUST be implemented whenever the IETF IPsec DOI [Pip97] is implemented. Other DOIs MAY use the modes described here. 5. Exchanges There are two basic methods used to establish an authenticated key exchange: Main Mode and Aggressive Mode. Each generates authenticated keying material from an ephemeral Diffie-Hellman exchange. Main Mode MUST be implemented; Aggressive Mode SHOULD be implemented. In addition, Quick Mode MUST be implemented as a mechanism to generate fresh keying material and negotiate non-ISAKMP security services. In additon, New Group Mode SHOULD be implemented as a mechanism to define private groups for Diffie-Hellman exchanges. Implementations MUST NOT switch exchange types in the middle of an exchange. Exchanges conform to standard ISAKMP [MSST98] payload syntax, attribute encoding, timeouts and retransmits of messages, and informational messages-- e.g a notify response is sent when, for example, a proposal is unacceptable, or a signature verification or decryption was unsuccessful, etc. The SA payload MUST precede all other payloads in a phase 1 exchange. Except where otherwise noted, there are no requirements for ISAKMP payloads in any message to be in any particular order. Main Mode is an instantiation of the ISAKMP Identity Protect Exchange: The first two messages negotiate policy; the next two exchange Diffie-Hellman public values and ancillary data (e.g. nonces) necessary for the exchange; and the last two messages authenticate the Diffie-Hellman Exchange. The authentication method negotiated as part of the initial ISAKMP exchange influences the composition of the payloads but not their purpose. The XCHG for Main Mode is ISAKMP Identity Protect. Similarly, Aggressive Mode is an instantiation of the ISAKMP Aggressive Exchange. The first two messages negotiate policy, exchange Diffie-Hellman public values and ancillary data necessary for the exchange, and identities. In addition the second message Harkins, Carrel [Page 8] INTERNET DRAFT February 1998 authenticates the responder. The third message authenticates the initiator and provides a proof of participation in the exchange. The XCHG for Aggressive Mode is ISAKMP Aggressive. The final message MAY NOT be sent under protection of the ISAKMP SA allowing each party to postpone exponentiation, if desired, until negotiation of this exchange is complete. The graphic depictions of Aggressive Mode show the final payload in the clear; it need not be. Security Association negotiation is limited with Aggressive Mode. Due to message construction requirements the group in which the Diffie- Hellman exchange is performed cannot be negotiated. In addition, different authentication methods may further constrain attribute negotiation. For example, authentication with public key encryption cannot be negotiated and when using the revised method of public key encryption for authentication the cipher and hash cannot be negotiated. For situations where the rich attribute negotiation capabilities of IKE are required Main Mode may be required. Quick Mode and New Group Mode have no analog in ISAKMP. The XCHG values for Quick Mode and New Group Mode are defined in Appendix A. Main Mode, Aggressive Mode, and Quick Mode do security association negotiation. Security Association offers take the form of Tranform Payload(s) encapsulated in Proposal Payload(s) encapsulated in Security Association (SA) payload(s). If multiple offers are being made for phase 1 exchanges (Main Mode and Aggressive Mode) they MUST take the form of multiple Transform Payloads for a single Proposal Payload in a single SA payload. To put it another way, for phase 1 exchanges there MUST NOT be multiple Proposal Payloads for a single SA payload and there MUST NOT be multiple SA payloads. This document does not proscribe such behavior on offers in phase 2 exchanges. There is no limit on the number of offers the initiator may send to the responder but conformant implementations MAY choose to limit the number of offers it will inspect for performance reasons. During security association negotiation, initiators present offers for potential security associations to responders. Responders MUST NOT modify attributes of any offer, attribute encoding excepted (see Appendix A). If the initiator of an exchange notices that attribute values have changed or attributes have been added or deleted from an offer made, that response MUST be rejected. Four different authentication methods are allowed with either Main Mode or Aggressive Mode-- digital signature, two forms of authentication with public key encryption, or pre-shared key. The value SKEYID is computed seperately for each authentication method. Harkins, Carrel [Page 9] INTERNET DRAFT February 1998 For signatures: SKEYID = prf(Ni_b | Nr_b, g^xy) For public key encryption: SKEYID = prf(hash(Ni_b | Nr_b), CKY-I | CKY-R) For pre-shared keys: SKEYID = prf(pre-shared-key, Ni_b | Nr_b) The result of either Main Mode or Aggressive Mode is three groups of authenticated keying material: SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1) SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2) and agreed upon policy to protect further communications. The values of 0, 1, and 2 above are represented by a single octet. The key used for encryption is derived from SKEYID_e in an algorithm-specific manner (see appendix B). To authenticate either exchange the initiator of the protocol generates HASH_I and the responder generates HASH_R where: HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b ) HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b ) For authentication with digital signatures, HASH_I and HASH_R are signed and verified; for authentication with either public key encryption or pre-shared keys, HASH_I and HASH_R directly authenticate the exchange. The entire ID payload (including ID type, port, and protocol but excluding the generic header) is hashed into both HASH_I and HASH_R. As mentioned above, the negotiated authentication method influences the content and use of messages for Phase 1 Modes, but not their intent. When using public keys for authentication, the Phase 1 exchange can be accomplished either by using signatures or by using public key encryption (if the algorithm supports it). Following are Phase 1 exchanges with different authentication options. 5.1 IKE Phase 1 Authenticated With Signatures Using signatures, the ancillary information exchanged during the second roundtrip are nonces; the exchange is authenticated by signing a mutually obtainable hash. Main Mode with signature authentication is described as follows: Initiator Responder ---------- ----------- HDR, SA --> Harkins, Carrel [Page 10] INTERNET DRAFT February 1998 <-- HDR, SA HDR, KE, Ni --> <-- HDR, KE, Nr HDR*, IDii, [ CERT, ] SIG_I --> <-- HDR*, IDir, [ CERT, ] SIG_R Aggressive mode with signatures in conjunction with ISAKMP is described as follows: Initiator Responder ----------- ----------- HDR, SA, KE, Ni, IDii --> <-- HDR, SA, KE, Nr, IDir, [ CERT, ] SIG_R HDR, [ CERT, ] SIG_I --> In both modes, the signed data, SIG_I or SIG_R, is the result of the negotiated digital signature algorithm applied to HASH_I or HASH_R respectively. In general the signature will be over HASH_I and HASH_R as above using the negotiated prf, or the HMAC version of the negotiated hash function (if no prf is negotiated). However, this can be overridden for construction of the signature if the signature algorithm is tied to a particular hash algorithm (e.g. DSS is only defined with SHA's 160 bit output). In this case, the signature will be over HASH_I and HASH_R as above, except using the HMAC version of the hash algorithm associated with the signature method. The negotiated prf and hash function would continue to be used for all other prescribed pseudo- random functions. Since the hash algorithm used is already known there is no need to encode its OID into the signature. In addition, there is no binding between the OIDs used for RSA signatures in PKCS #1 and those used in this document. Therefore, RSA signatures MUST be encoded as a private key encryption in PKCS #1 format. DSS signatures MUST be encoded as r followed by s. One or more certificate payloads MAY be optionally passed. 5.2 Phase 1 Authenticated With Public Key Encryption Using public key encryption to authenticate the exchange, the ancillary information exchanged is encrypted nonces. Each party's ability to reconstruct a hash (proving that the other party decrypted the nonce) authenticates the exchange. In order to perform the public key encryption, the initiator must Harkins, Carrel [Page 11] INTERNET DRAFT February 1998 already have the responder's public key. In the case where the responder has multiple public keys, a hash of the certificate the initiator is using to encrypt the ancillary information is passed as part of the third message. In this way the responder can determine which corresponding private key to use to decrypt the encrypted payloads and identity protection is retained. In addition to the nonce, the identities of the parties (IDii and IDir) are also encrypted with the other party's 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, Main Mode is defined as follows. Initiator Responder ----------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, [ HASH(1), ] PubKey_r, PubKey_r --> HDR, KE, PubKey_i, <-- PubKey_i HDR*, HASH_I --> <-- HDR*, HASH_R Aggressive Mode authenticated with encryption is described as follows: Initiator Responder ----------- ----------- HDR, SA, [ HASH(1),] KE, Pubkey_r, Pubkey_r --> HDR, SA, KE, PubKey_i, <-- PubKey_i, HASH_R HDR, HASH_I --> Where HASH(1) is a hash (using the negotiated hash function) of the certificate which the initiator is using to encrypt the nonce and identity. RSA encryption MUST be encoded in PKCS #1 format. While only the body of the ID and nonce payloads is encrypted, the encrypted data must be preceded by a valid ISAKMP generic header. The payload length is the Harkins, Carrel [Page 12] INTERNET DRAFT February 1998 length of the entire encrypted payload plus header. The PKCS #1 encoding allows for determination of the actual length of the cleartext payload upon decryption. Using encryption for authentication provides for a plausably deniable exchange. There is no proof (as with a digital signature) that the conversation ever took place since each party can completely reconstruct both sides of the exchange. In addition, security is added to secret generation since an attacker would have to successfully break not only the Diffie-Hellman exchange but also both RSA encryptions. This exchange was motivated by [Kra96]. Note that, unlike other authentication methods, authentication with public key encryption allows for identity protection with Aggressive Mode. 5.3 Phase 1 Authenticated With a Revised Mode of Public Key Encryption Authentication with Public Key Encryption has significant advantages over authentication with signatures (see section 5.2 above). Unfortunately, this is at the cost of 4 public key operations-- two public key encryptions and two private key decryptions. This authentication mode retains the advantages of authentication using public key encryption but does so with half the public key operations. In this mode, the nonce is still encrypted using the public key of the peer, however the peer's identity (and the certificate if it is sent) is encrypted using the negotiated symmetric encryption algorithm (from the SA payload) with a key derived from the nonce. This solution adds minimal complexity and state yet saves two costly public key operations on each side. In addition, the Key Exchange payload is also encrypted using the same derived key. This provides additional protection against cryptanalysis of the Diffie-Hellman exchange. As with the public key encryption method of authentication (section 5.2), a HASH payload may be sent to identify a certificate if the responder has multiple certificates which contain useable public keys (e.g. if the certificate is not for signatures only, either due to certificate restrictions or algorithmic restrictions). If the HASH payload is sent it MUST be the first payload of the second message exchange and MUST be followed by the encrypted nonce. If the HASH payload is not sent, the first payload of the second message exchange MUST be the encrypted nonce. In addition, the initiator my optionally send a certificate payload to provide the responder with a public key with which to respond. Harkins, Carrel [Page 13] INTERNET DRAFT February 1998 When using the revised encryption mode for authentication, Main Mode is defined as follows. Initiator Responder ----------- ----------- HDR, SA --> <-- HDR, SA HDR, [ HASH(1), ] Pubkey_r, Ke_i, Ke_i, [<Ke_i] --> HDR, PubKey_i, Ke_r, <-- Ke_r, HDR*, HASH_I --> <-- HDR*, HASH_R Aggressive Mode authenticated with the revised encryption method is described as follows: Initiator Responder ----------- ----------- HDR, SA, [ HASH(1),] Pubkey_r, Ke_i, Ke_i [, Ke_i ] --> HDR, SA, PubKey_i, Ke_r, Ke_r, <-- HASH_R HDR, HASH_I --> where HASH(1) is identical to section 5.2. Ke_i and Ke_r are keys to the symmetric encryption algorithm negotiated in the SA payload exchange. Only the body of the payloads are encrypted (in both public key and symmetric operations), the generic payload headers are left in the clear. The payload length includes that added to perform encryption. The symmetric cipher keys are derived from the decrypted nonces as follows. First the values Ne_i and Ne_r are computed: Ne_i = prf(Ni_b, CKY-I) Ne_r = prf(Nr_b, CKY-R) The keys Ke_i and Ke_r are then taken from Ne_i and Ne_r respectively in the manner described in Appendix B used to derive symmetric keys for use with the negotiated encryption algorithm. If the length of Harkins, Carrel [Page 14] INTERNET DRAFT February 1998 the output of the negotiated prf is greater than or equal to the key length requirements of the cipher, Ke_i and Ke_r are derived from the most significant bits of Ne_i and Ne_r respectively. If the desired length of Ke_i and Ke_r exceed the length of the output of the prf the necessary number of bits is obtained by repeatedly feeding the results of the prf back into itself and concatenating the result until the necessary number has been achieved. For example, if the negotiated encryption algorithm requires 320 bits of key and the output of the prf is only 128 bits, Ke_i is the most significant 320 bits of K, where K = K1 | K2 | K3 and K1 = prf(Ne_i, 0) K2 = prf(Ne_i, K1) K3 = prf(Ne_i, K2) For brevity, only derivation of Ke_i is shown; Ke_r is identical. The length of the value 0 in the computation of K1 is a single octet. Note that Ne_i, Ne_r, Ke_i, and Ke_r are all ephemeral and MUST be discarded after use. Save the requirements on the location of the optional HASH payload and the mandatory nonce payload there are no further payload requirements. All payloads-- in whatever order-- following the encrypted nonce MUST be encrypted with Ke_i or Ke_r depending on the direction. If CBC mode is used for the symmetric encryption then the initialization vectors (IVs) are set as follows. The IV for encrypting the first payload following the nonce is set to 0 (zero). The IV for subsequent payloads encrypted with the ephemeral symmetric cipher key, Ke_i, is the last ciphertext block of the previous payload. Encrypted payloads are padded up to the nearest block size. All padding bytes, except for the last one, contain 0x00. The last byte of the padding contains the number of the padding bytes used, excluding the last one. Note that this means there will always be padding. 5.4 Phase 1 Authenticated With a Pre-Shared Key A key derived by some out-of-band mechanism may also be used to authenticate the exchange. The actual establishment of this key is out of the scope of this document. When doing a pre-shared key authentication, Main Mode is defined as follows: Initiator Responder Harkins, Carrel [Page 15] INTERNET DRAFT February 1998 ---------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, Ni --> <-- HDR, KE, Nr HDR*, IDii, HASH_I --> <-- HDR*, IDir, HASH_R Aggressive mode with a pre-shared key is described as follows: Initiator Responder ----------- ----------- HDR, SA, KE, Ni, IDii --> <-- HDR, SA, KE, Nr, IDir, HASH_R HDR, HASH_I --> When using pre-shared key authentication with Main Mode the key can only be identified by the IP address of the peers since HASH_I must be computed before the initiator has processed IDir. Aggressive Mode allows for a wider range of identifiers of the pre-shared secret to be used. In addition, Aggressive Mode allows two parties to maintain multiple, different pre-shared keys and identify the correct one for a particular exchange. 5.5 Phase 2 - Quick Mode Quick Mode is not a complete exchange itself, but is used as part of the ISAKMP SA negotiation process (phase 2) to derive keying material and negotiate shared policy for non-ISAKMP SAs. The information exchanged along with Quick Mode MUST be protected by the ISAKMP SA-- i.e. all payloads except the ISAKMP header are encrypted. In Quick Mode, a HASH payload MUST immediately follow the ISAKMP header and a SA payload MUST immediately follow the HASH. This HASH authenticates the message and also provides liveliness proofs. Quick Mode is essentially a SA negotiation and an exchange of nonces that provides replay protection. The nonces are used to generate fresh key material and prevent replay attacks from generating bogus security associations. An optional Key Exchange payload can be exchanged to allow for an additional Diffie-Hellman exchange and exponentiation per Quick Mode. While use of the key exchange payload with Quick Mode is optional it MUST be supported. Base Quick Mode (without the KE payload) refreshes the keying material derived from the exponentiation in phase 1. This does not provide PFS. Using the optional KE payload, an additional exponentiation is performed and PFS is provided for the keying material. Harkins, Carrel [Page 16] INTERNET DRAFT February 1998 If ISAKMP is acting as a client negotiator on behalf of another party the identities of the parties MUST be passed as IDci and then IDcr. Local policy will dictate whether the proposals are acceptible for the identities specified. If IDs are not exchanged, the negotiation MAY assumed to be done on behalf of each ISAKMP peer. If an ID range (see Appendix A of [Pip97]) is not acceptable (for example, the specified subnet is too large) a INVALID-ID-INFORMATION notify message (18) followed by an acceptible ID range, in an ID payload, SHOULD be sent. The client identities are used to identify and direct traffic to the appropriate tunnel in cases where multiple tunnels exist between two peers and also to allow for unique and shared SAs with different granularities. All offers made during a Quick Mode are logically related and must be consistant. For example, if a KE payload is sent, the attribute describing the Diffie-Hellman group (see section 6.1 and [Pip97]) MUST be included in every transform of every proposal of every SA being negotiated. Similarly, if client identities are used, they MUST apply to every SA in the negotiation. Quick Mode is defined as follows: Initiator Responder ----------- ----------- HDR*, HASH(1), SA, Ni [, KE ] [, IDci, IDcr ] --> <-- HDR*, HASH(2), SA, Nr [, KE ] [, IDci, IDcr ] HDR*, HASH(3) --> Where: HASH(1) is the prf over the message id (M-ID) from the ISAKMP header concatenated with the entire message that follows the hash including all payload headers, but excluding any padding added for encryption. HASH(2) is identical to HASH(1) except the initiator's nonce-- Ni, minus the payload header-- is added after M-ID but before the complete message. The addition of the nonce to HASH(2) is for a liveliness proof. 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-- minus the payload header. In other words, the hashes for the above exchange are: HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr ]) HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci | IDcr ]) Harkins, Carrel [Page 17] INTERNET DRAFT February 1998 HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b) With the exception of the HASH, SA, and the optional ID payloads, there are no payload ordering restrictions on Quick Mode. HASH(1) and HASH(2) may differ from the illustration above if the order of payloads in the message differs from the illustrative example. If PFS is not needed, and KE payloads are not exchanged, the new keying material is defined as KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b). If PFS is desired and KE payloads were exchanged, the new keying material is defined as KEYMAT = prf(SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | Nr_b) where g(qm)^xy is the shared secret from the ephemeral Diffie-Hellman exchange of this Quick Mode. In either case, "protocol" and "SPI" are from the ISAKMP Proposal Payload that contained the negotiated Transform. A single SA negotiation results in two security assocations-- one inbound and one outbound. Different SPIs for each SA (one chosen by the initiator, the other by the responder) guarantee a different key for each direction. The SPI chosen by the destination of the SA is used to derive KEYMAT for that SA. For situations where the amount of keying material desired is greater than that supplied by the prf, KEYMAT is expanded by feeding the results of the prf back into itself and concatenating results until the required keying material has been reached. In other words, KEYMAT = K1 | K2 | K3 | ... where K1 = prf(SKEYID_d, [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b) K2 = prf(SKEYID_d, K1 | [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b) K3 = prf(SKEYID_d, K2 | [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b) etc. This keying material (whether with PFS or without, and whether derived directly or through concatenation) MUST be used with the negotiated SA. It is up to the service to define how keys are derived from the keying material. Harkins, Carrel [Page 18] INTERNET DRAFT February 1998 In the case of an ephemeral Diffie-Hellman exchange in Quick Mode, the exponential (g(qm)^xy) is irretreivably removed from the current state and SKEYID_e and SKEYID_a (derived from phase 1 negotiation) continue to protect and authenticate the ISAKMP SA and SKEYID_d continues to be used to derive keys. Using Quick Mode, multiple SA's and keys can be negotiated with one exchange as follows: Initiator Responder ----------- ----------- HDR*, HASH(1), SA0, SA1, Ni, [, KE ] [, IDci, IDcr ] --> <-- HDR*, HASH(2), SA0, SA1, Nr, [, KE ] [, IDci, IDcr ] HDR*, HASH(3) --> The keying material is derived identically as in the case of a single SA. In this case (negotiation of two SA payloads) the result would be four security associations-- two each way for both SAs. 5.6 New Group Mode New Group Mode MUST NOT be used prior to establishment of an ISAKMP SA. The description of a new group MUST only follow phase 1 negotiation. (It is not a phase 2 exchange, though). Initiator Responder ----------- ----------- HDR*, HASH(1), SA --> <-- HDR*, HASH(2), SA where HASH(1) is the prf output, using SKEYID_a as the key, and the message-ID from the ISAKMP header concatenated with the entire SA proposal, body and header, as the data; HASH(2) is the prf output, using SKEYID_a as the key, and the message-ID from the ISAKMP header concatenated with the reply as the data. In other words the hashes for the above exchange are: HASH(1) = prf(SKEYID_a, M-ID | SA) HASH(2) = prf(SKEYID_a, M-ID | SA) The proposal will specify the characteristics of the group (see appendix A, "Attribute Assigned Numbers"). Group descriptions for private Groups MUST be greater than or equal to 2^15. If the group is not acceptable, the responder MUST reply with a Notify payload with the message type set to ATTRIBUTES-NOT-SUPPORTED (13). Harkins, Carrel [Page 19] INTERNET DRAFT February 1998 ISAKMP implementations MAY require private groups to expire with the SA under which they were established. Groups may be directly negotiated in the SA proposal with Main Mode. To do this the component parts-- for a MODP group, the type, prime and generator; for a EC2N group the type, the Irreducible Polynomial, Group Generator One, Group Generator Two, Group Curve A, Group Curve B and Group Order-- are passed as SA attributes (see Appendix A). Alternately, the nature of the group can be hidden using New Group Mode and only the group identifier is passed in the clear during phase 1 negotiation. 5.7 ISAKMP Informational Exchanges This protocol protects ISAKMP Informational Exchanges when possible. Once the ISAKMP security association has been established (and SKEYID_e and SKEYID_a have been generated) ISAKMP Information Exchanges, when used with this protocol, are as follows: Initiator Responder ----------- ----------- HDR*, HASH(1), N/D --> where N/D is either an ISAKMP Notify Payload or an ISAKMP Delete Payload and HASH(1) is the prf output, using SKEYID_a as the key, and a M-ID unique to this exchange concatenated with the entire informational payload (either a Notify or Delete) as the data. In other words, the hash for the above exchange is: HASH(1) = prf(SKEYID_a, M-ID | N/D) As noted the message ID in the ISAKMP header-- and used in the prf computation-- is unique to this exchange and MUST NOT be the same as the message ID of another phase 2 exchange which generated this informational exchange. The derivation of the initialization vector, used with SKEYID_e to encrypt this message, is described in Appendix B. If the ISAKMP security association has not yet been established at the time of the Informational Exchange, the exchange is done in the clear without an accompanying HASH payload. 6 Oakley Groups With IKE, the group in which to do the Diffie-Hellman exchange is negotiated. Four groups-- values 1 through 4-- are defined below. These groups originated with the Oakley protocol and are therefore called "Oakley Groups". The attribute class for "Group" is defined in Harkins, Carrel [Page 20] INTERNET DRAFT February 1998 Appendix A. All values 2^15 and higher are used for private group identifiers. For a discussion on the strength of the default Oakley groups please see the Security Considerations section below. 6.1 First Oakley Default Group Oakley implementations MUST support a MODP group with the following prime and generator. This group is assigned id 1 (one). The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } Its hexadecimal value is FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF The generator is: 2. 6.2 Second Oakley Group IKE implementations SHOULD support a MODP group with the following prime and generator. This group is assigned id 2 (two). The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. Its hexadecimal value is FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 FFFFFFFF FFFFFFFF The generator is 2 (decimal) 6.3 Third Oakley Group IKE implementations SHOULD support a EC2N group with the following characteristics. This group is assigned id 3 (three). The curve is based on the Galois Field GF[2^155]. The field size is 155. The irreducible polynomial for the field is: u^155 + u^62 + 1. The equation for the elliptic curve is: y^2 + xy = x^3 + ax^2 + b. Field Size: 155 Group Prime/Irreducible Polynomial: Harkins, Carrel [Page 21] INTERNET DRAFT February 1998 0x0800000000000000000000004000000000000001 Group Generator One: 0x7b Group Curve A: 0x0 Group Curve B: 0x07338f Group Order: 0X0800000000000000000057db5698537193aef944 The data in the KE payload when using this group is the value x from the solution (x,y), the point on the curve chosen by taking the randomly chosen secret Ka and computing Ka*P, where * is the repetition of the group addition and double operations, P is the curve point with x coordinate equal to generator 1 and the y coordinate determined from the defining equation. The equation of curve is implicitly known by the Group Type and the A and B coefficients. There are two possible values for the y coordinate; either one can be used successfully (the two parties need not agree on the selection). 6.4 Fourth Oakley Group IKE implementations SHOULD support a EC2N group with the following characteristics. This group is assigned id 4 (four). The curve is based on the Galois Field GF[2^185]. The field size is 185. The irreducible polynomial for the field is: u^185 + u^69 + 1. The equation for the elliptic curve is: y^2 + xy = x^3 + ax^2 + b. Field Size: 185 Group Prime/Irreducible Polynomial: 0x020000000000000000000000000000200000000000000001 Group Generator One: 0x18 Group Curve A: 0x0 Group Curve B: 0x1ee9 Group Order: 0X01ffffffffffffffffffffffdbf2f889b73e484175f94ebc The data in the KE payload when using this group will be identical to that as when using Oakley Group 3 (three). Other groups can be defined using New Group Mode. These default groups were generated by Richard Schroeppel at the University of Arizona. Properties of these primes are described in [Orm96]. 7. Payload Explosion for a Complete IKE Exchange This section illustrates how the IKE protocol is used to: Harkins, Carrel [Page 22] INTERNET DRAFT February 1998 - establish a secure and authenticated channel between ISAKMP processes (phase 1); and - generate key material for, and negotiate, an IPsec SA (phase 2). Harkins, Carrel [Page 23] INTERNET DRAFT February 1998 7.1 Phase 1 using Main Mode The following diagram illustrates the payloads exchanged between the two parties in the first round trip exchange. The initiator MAY propose several proposals; the responder MUST reply with one. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ISAKMP Header with XCHG of Main Mode, ~ ~ and Next Payload of ISA_SA ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Domain of Interpretation ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Situation ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Proposal #1 ! PROTO_ISAKMP ! SPI size = 0 | # Transforms ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_TRANS ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Transform #1 ! KEY_OAKLEY | RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ prefered SA attributes ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Transform #2 ! KEY_OAKLEY | RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ alternate SA attributes ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The responder replies in kind but selects, and returns, one transform proposal (the ISAKMP SA attributes). Harkins, Carrel [Page 24] INTERNET DRAFT February 1998 The second exchange consists of the following payloads: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ISAKMP Header with XCHG of Main Mode, ~ ~ and Next Payload of ISA_KE ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_NONCE ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ D-H Public Value (g^xi from initiator g^xr from responder) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Ni (from initiator) or Nr (from responder) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The shared keys, SKEYID_e and SKEYID_a, are now used to protect and authenticate all further communication. Note that both SKEYID_e and SKEYID_a are unauthenticated. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ISAKMP Header with XCHG of Main Mode, ~ ~ and Next Payload of ISA_ID and the encryption bit set ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_SIG ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Identification Data of the ISAKMP negotiator ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ signature verified by the public key of the ID above ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The key exchange is authenticated over a signed hash as described in section 5.1. Once the signature has been verified using the authentication algorithm negotiated as part of the ISAKMP SA, the shared keys, SKEYID_e and SKEYID_a can be marked as authenticated. (For brevity, certificate payloads were not exchanged). 7.2 Phase 2 using Quick Mode The following payloads are exchanged in the first round of Quick Mode with ISAKMP SA negotiation. In this hypothetical exchange, the ISAKMP negotiators are proxies for other parties which have requested authentication. Harkins, Carrel [Page 25] INTERNET DRAFT February 1998 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ISAKMP Header with XCHG of Quick Mode, ~ ~ Next Payload of ISA_HASH and the encryption bit set ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_SA ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ keyed hash of message ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_NONCE ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Domain Of Interpretation ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Situation ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Proposal #1 ! PROTO_IPSEC_AH! SPI size = 4 | # Transforms ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SPI (4 octets) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_TRANS ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Transform #1 ! AH_SHA | RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! other SA attributes ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Transform #2 ! AH_MD5 | RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! other SA attributes ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_ID ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ nonce ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_ID ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ID of source for which ISAKMP is a client ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ID of destination for which ISAKMP is a client ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where the contents of the hash are described in 5.5 above. The responder replies with a similar message which only contains one Harkins, Carrel [Page 26] INTERNET DRAFT February 1998 transform-- the selected AH transform. Upon receipt, the initiator can provide the key engine with the negotiated security association and the keying material. As a check against replay attacks, the responder waits until receipt of the next message. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ISAKMP Header with XCHG of Quick Mode, ~ ~ Next Payload of ISA_HASH and the encryption bit set ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ hash data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where the contents of the hash are described in 5.5 above. 8 Perfect Forward Secrecy Example This protocol can provide PFS of both keys and identities. The identies of both the ISAKMP negotiating peer and, if applicable, the identities for whom the peers are negotiating can be protected with PFS. To provide Perfect Forward Secrecy of both keys and all identities, two parties would perform the following: o A Main Mode Exchange to protect the identities of the ISAKMP peers. This establishes an ISAKMP SA. o A Quick Mode Exchange to negotiate other security protocol protection. This establishes a SA on each end for this protocol. o Delete the ISAKMP SA and its associated state. Since the key for use in the non-ISAKMP SA was derived from the single ephemeral Diffie-Hellman exchange PFS is preserved. To provide Perfect Forward Secrecy of merely the keys of a non-ISAKMP security association, it in not necessary to do a phase 1 exchange if an ISAKMP SA exists between the two peers. A single Quick Mode in which the optional KE payload is passed, and an additional Diffie- Hellman exchange is performed, is all that is required. At this point the state derived from this Quick Mode must be deleted from the ISAKMP SA as described in section 5.5. Harkins, Carrel [Page 27] INTERNET DRAFT February 1998 9. Implementation Hints Using a single ISAKMP Phase 1 negotiation makes subsequent Phase 2 negotiations extremely quick. As long as the Phase 1 state remains cached, and PFS is not needed, Phase 2 can proceed without any exponentiation. How many Phase 2 negotiations can be performed for a single Phase 1 is a local policy issue. The decision will depend on the strength of the algorithms being used and level of trust in the peer system. An implementation may wish to negotiate a range of SAs when performing Quick Mode. By doing this they can speed up the "re- keying". Quick Mode defines how KEYMAT is defined for a range of SAs. When one peer feels it is time to change SAs they simply use the next one within the stated range. A range of SAs can be established by negotiating multiple SAs (identical attributes, different SPIs) with one Quick Mode. An optimization that is often useful is to establish Security Associations with peers before they are needed so that when they become needed they are already in place. This ensures there would be no delays due to key management before initial data transmission. This optimization is easily implemented by setting up more than one Security Association with a peer for each requested Security Association and caching those not immediately used. Also, if an ISAKMP implementation is alerted that a SA will soon be needed (e.g. to replace an existing SA that will expire in the near future), then it can establish the new SA before that new SA is needed. The base ISAKMP specification describes conditions in which one party of the protocol may inform the other party of some activity-- either deletion of a security association or in response to some error in the protocol such as a signature verification failed or a payload failed to decrypt. It is strongly suggested that these Informational exchanges not be responded to under any circumstances. Such a condition may result in a "notify war" in which failure to understand a message results in a notify to the peer who cannot understand it and sends his own notify back which is also not understood. 10. Security Considerations This entire draft discusses a hybrid protocol, combining parts of Oakley and parts of SKEME with ISAKMP, to negotiate, and derive keying material for, security associations in a secure and authenticated manner. Harkins, Carrel [Page 28] INTERNET DRAFT February 1998 Confidentiality is assured by the use of a negotiated encryption algorithm. Authentication is assured by the use of a negotiated method: a digital signature algorithm; a public key algorithm which supports encryption; or, a pre-shared key. The confidentiality and authentication of this exchange is only as good as the attributes negotiated as part of the ISAKMP security association. Repeated re-keying using Quick Mode can consume the entropy of the Diffie- Hellman shared secret. Implementors should take note of this fact and set a limit on Quick Mode Exchanges between exponentiations. This draft does not prescribe such a limit. Perfect Forward Secrecy (PFS) of both keying material and identities is possible with this protocol. By specifying a Diffie-Hellman group, and passing public values in KE payloads, ISAKMP peers can establish PFS of keys-- the identities would be protected by SKEYID_e from the ISAKMP SA and would therefore not be protected by PFS. If PFS of both keying material and identities is desired, an ISAKMP peer MUST establish only one non-ISAKMP security association (e.g. IPsec Security Association) per ISAKMP SA. PFS for keys and identities is accomplished by deleting the ISAKMP SA (and optionally issuing a DELETE message) upon establishment of the single non-ISAKMP SA. In this way a phase one negotiation is uniquely tied to a single phase two negotiation, and the ISAKMP SA established during phase one negotiation is never used again. The strength of a key derived from a Diffie-Hellman exchange using any of the groups defined here depends on the inherent strength of the group, the size of the exponent used, and the entropy provided by the random number generator used. Due to these inputs it is difficult to determine the strength of a key for any of the defined groups. The default Diffie-Hellman group (number one) when used with a strong random number generator and an exponent no less than 160 bits is sufficient to use for DES. Groups two through four provide greater security. Implementations should make note of these conservative estimates when establishing policy and negotiating security parameters. Note that these limitations are on the Diffie-Hellman groups themselves. There is nothing in IKE which prohibits using stronger groups nor is there anything which will dilute the strength obtained from stronger groups. In fact, the extensible framework of IKE encourages the definition of more groups; use of elliptical curve groups will greatly increase strength using much smaller numbers. For situations where defined groups provide insufficient strength New Group Mode can be used to exchange a Diffie-Hellman group which provides the necessary strength. In is incumbent upon implementations Harkins, Carrel [Page 29] INTERNET DRAFT February 1998 to check the primality in groups being offered and independently arrive at strength estimates. It is assumed that the Diffie-Hellman exponents in this exchange are erased from memory after use. In particular, these exponents must not be derived from long-lived secrets like the seed to a pseudo-random generator. 11. IANA Considerations This document contains many "magic numbers" to be maintained by the IANA. This section explains the criteria to be used by the IANA to assign additional numbers in each of these lists. 11.1 Attribute Classes Attributes negotiated in this protocol are identified by their class. Requests for assignment of new classes must be accompanied by a standards- track RFC which describes the use of this attribute. 11.2 Encryption Algorithm Class Values of the Encryption Algorithm Class define an encryption algorithm to use when called for in this document. Requests for assignment of new encryption algorithm values must be accompanied by a reference to a standards-track or Informational RFC or a reference to published cryptographic literature which describes this algorithm. 11.3 Hash Algorithm Values of the Hash Algorithm Class define a hash algorithm to use when called for in this document. Requests for assignment of new hash algorithm values must be accompanied by a reference to a standards- track or Informational RFC or a reference to published cryptographic literature which describes this algorithm. 11.4 Group Description and Group Type Values of the Group Description Class identify a group to use in a Diffie-Hellman exchange. Values of the Group Type Class define the type of group. Requests for assignment of new groups must be accompanied by a reference to a standards-track or Informational RFC which describes this group. Requests for assignment of new group types must be accompanied by a reference to a standards-track or Informational RFC or by a reference to published cryptographic or mathmatical literature which describes the new type. 11.5 Life Type Values of the Life Type Class define a type of lifetime to which the ISAKMP Security Association applies. Requests for assignment of new life types must be accompanied by a detailed description of the units of this type and its expiry. 12. Acknowledgements This document is the result of close consultation with Hugo Krawczyk, Douglas Maughan, Hilarie Orman, Mark Schertler, Mark Schneider, and Jeff Turner. It relies on protocols which were written by them. Harkins, Carrel [Page 30] INTERNET DRAFT February 1998 Without their interest and dedication, this would not have been written. Special thanks Rob Adams, Cheryl Madson, Derrell Piper, Harry Varnis, and Elfed Weaver for technical input, encouragement, and various sanity checks along the way. We would also like to thank the many members of the IPSec working group that contributed to the development of this protocol over the past year. 13. References [Acm97] Adams, C.M., "The CAST-128 Encryption Algorithm", RFC 2144, May 1997. [Bra97] Bradner, S., "Key Words for use in RFCs to indicate Requirement Levels", RFC2119, March 1997. [KBC96] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [Kra96] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange Mechanism for Internet", from IEEE Proceedings of the 1996 Symposium on Network and Distributed Systems Security. [MSST98] Maughhan, D., Schertler, M., Schneider, M., and Turner, J., "Internet Security Association and Key Management Protocol (ISAKMP)", version 9, draft-ietf-ipsec-isakmp-09.{ps,txt}. [Orm96] Orman, H., "The Oakley Key Determination Protocol", version 2, draft-ietf-ipsec-oakley-02.txt [Pip98] Piper, D., "The Internet IP Security Domain Of Interpretation for ISAKMP", version 7, draft-ietf-ipsec-ipsec-doi-07.txt. [Sch96] Schneier, B., "Applied Cryptography, Protocols, Algorithms, and Source Code in C", 2nd edition. Harkins, Carrel [Page 31] INTERNET DRAFT February 1998 Appendix A This is a list of DES Weak and Semi-Weak keys. The keys come from [Sch96]. All keys are listed in hexidecimal. DES Weak Keys 0101 0101 0101 0101 1F1F 1F1F E0E0 E0E0 E0E0 E0E0 1F1F 1F1F FEFE FEFE FEFE FEFE DES Semi-Weak Keys 01FE 01FE 01FE 01FE 1FE0 1FE0 0EF1 0EF1 01E0 01E0 01F1 01F1 1FFE 1FFE 0EFE 0EFE 011F 011F 010E 010E E0FE E0FE F1FE F1FE FE01 FE01 FE01 FE01 E01F E01F F10E F10E E001 E001 F101 F101 FE1F FE1F FE0E FE0E 1F01 1F01 0E01 0E01 FEE0 FEE0 FEF1 FEF1 Attribute Assigned Numbers Attributes negotiated during phase one use the following definitions. Phase two attributes are defined in the applicable DOI specification (for example, IPsec attributes are defined in the IPsec DOI), with the exception of a group description when Quick Mode includes an ephemeral Diffie-Hellman exchange. Attribute types can be either Basic (B) or Variable-length (V). Encoding of these attributes is defined in the base ISAKMP specification as Type/Value (Basic) and Type/Length/Value (Variable). Attributes described as basic MUST NOT be encoded as variable. Variable length attributes MAY be encoded as basic attributes if their value can fit into two octets. If this is the case, an attribute offered as variable (or basic) by the initiator of this protocol MAY be returned to the initiator as a basic (or variable). Harkins, Carrel [Page 32] INTERNET DRAFT February 1998 Attribute Classes class value type ------------------------------------------------------------------- Encryption Algorithm 1 B Hash Algorithm 2 B Authentication Method 3 B Group Description 4 B Group Type 5 B Group Prime/Irreducible Polynomial 6 V Group Generator One 7 V Group Generator Two 8 V Group Curve A 9 V Group Curve B 10 V Life Type 11 B Life Duration 12 V PRF 13 B Key Length 14 B Field Size 15 B Group Order 16 V values 17-16383 are reserved to IANA. Values 16384-32767 are for private use among mutually consenting parties. Class Values - Encryption Algorithm DEC-CBC 1 IDEA-CBC 2 Blowfish-CBC 3 RC5-R16-B64-CBC 4 3DES-CBC 5 CAST-CBC 6 values 7-65000 are reserved to IANA. Values 65001-65535 are for private use among mutually consenting parties. - Hash Algorithm MD5 1 SHA 2 Tiger 3 values 4-65000 are reserved to IANA. Values 65001-65535 are for private use among mutually consenting parties. - Authentication Method pre-shared key 1 DSS signatures 2 Harkins, Carrel [Page 33] INTERNET DRAFT February 1998 RSA signatures 3 Encryption with RSA 4 Revised encryption with RSA 5 values 6-65000 are reserved to IANA. Values 65001-65535 are for private use among mutually consenting parties. - Group Description default 768-bit MODP group (section 6.1) 1 alternate 1024-bit MODP group (section 6.2) 2 .sp EC2N group on GP[2^155] (section 6.3) 3 .sp EC2N group on GP[2^185] (section 6.4) 4 values 5-32767 are reserved to IANA. Values 32768-65535 are for private use among mutually consenting parties. - Group Type MODP (modular exponentiation group) 1 ECP (elliptic curve group over GF[P]) 2 EC2N (elliptic curve group over GF[2^N]) 3 values 4-65000 are reserved to IANA. Values 65001-65535 are for private use among mutually consenting parties. - Life Type seconds 1 kilobytes 2 values 3-65000 are reserved to IANA. Values 65001-65535 are for private use among mutually consenting parties. For a given "Life Type" the value of the "Life Duration" attribute defines the actual length of the SA life-- either a number of seconds, or a number of kbytes protected. - PRF There are currently no pseudo-random functions defined. values 1-65000 are reserved to IANA. Values 65001-65535 are for private use among mutually consenting parties. - Key Length When using an Encryption Algorithm that has a variable length key, this attribute specifies the key length in bits. (MUST use network byte order). This attribute MUST NOT be used when the specified Harkins, Carrel [Page 34] INTERNET DRAFT February 1998 Encryption Algorithm uses a fixed length key. - Field Size The field size, in bits, of a Diffie-Hellman group. - Group Order The group order of an elliptical curve group. Note the length of this attribute depends on the field size. Additional Exchanges Defined-- XCHG values Quick Mode 32 New Group Mode 33 Harkins, Carrel [Page 35] INTERNET DRAFT February 1998 Appendix B This appendix describes encryption details to be used ONLY when encrypting ISAKMP messages. When a service (such as an IPSEC transform) utilizes ISAKMP to generate keying material, all encryption algorithm specific details (such as key and IV generation, padding, etc...) MUST be defined by that service. ISAKMP does not purport to ever produce keys that are suitable for any encryption algorithm. ISAKMP produces the requested amount of keying material from which the service MUST generate a suitable key. Details, such as weak key checks, are the responsibility of the service. Use of negotiated PRFs may require the PRF output to be expanded due to the PRF feedback mechanism employed by this document. For example, if the (ficticious) DOORAK-MAC requires 24 bytes of key but produces only 8 bytes of output, the output must be expanded three times before being used as the key for another instance of itself. The output of a PRF is expanded by feeding back the results of the PRF into itself to generate successive blocks. These blocks are concatenated until the requisite number of bytes has been acheived. For example, for pre-shared key authentication with DOORAK-MAC as the negotiated PRF: BLOCK1-8 = prf(pre-shared-key, Ni_b | Nr_b) BLOCK9-16 = prf(pre-shared-key, BLOCK1-8 | Ni_b | Nr_b) BLOCK17-24 = prf(pre-shared-key, BLOCK9-16 | Ni_b | Nr_b) and SKEYID = BLOCK1-8 | BLOCK9-16 | BLOCK17-24 so therefore to derive SKEYID_d: BLOCK1-8 = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) BLOCK9-16 = prf(SKEYID, BLOCK1-8 | g^xy | CKY-I | CKY-R | 0) BLOCK17-24 = prf(SKEYID, BLOCK9-16 | g^xy | CKY-I | CKY-R | 0) and SKEYID_d = BLOCK1-8 | BLOCK9-16 | BLOCK17-24 Subsequent PRF derivations are done similarly. Encryption keys used to protect the ISAKMP SA are derived from SKEYID_e in an algorithm-specific manner. When SKEYID_e is not long enough to supply all the necessary keying material an algorithm requires, the key is derived from feeding the results of a pseudo- random function into itself, concatenating the results, and taking the highest necessary bits. For example, if (ficticious) algorithm AKULA requires 320-bits of key (and has no weak key check) and the prf used to generate SKEYID_e Harkins, Carrel [Page 36] INTERNET DRAFT February 1998 only generates 120 bits of material, the key for AKULA, would be the first 320-bits of Ka, where: Ka = K1 | K2 | K3 and K1 = prf(SKEYID_e, 0) K2 = prf(SKEYID_e, K1) K3 = prf(SKEYID_e, K2) where prf is the negotiated prf or the HMAC version of the negotiated hash function (if no prf was negotiated) and 0 is represented by a single octet. Each result of the prf provides 120 bits of material for a total of 360 bits. AKULA would use the first 320 bits of that 360 bit string. In phase 1, material for the initialization vector (IV material) for CBC mode encryption algorithms is derived from a hash of a concatenation of the initiator's public Diffie-Hellman value and the responder's public Diffie-Hellman value using the negotiated hash algorithm. This is used for the first message only. Each message should be padded up to the nearest block size using bytes containing 0x00. The message length in the header MUST include the length of the pad since this reflects the size of the cyphertext. Subsequent messages MUST use the last CBC encryption block from the previous message as their initialization vector. In phase 2, material for the initialization vector for CBC mode encryption of the first message of a Quick Mode exchange is derived from a hash of a concatenation of the last phase 1 CBC output block and the phase 2 message id using the negotiated hash algorithm. The IV for subsequent messages within a Quick Mode exchange is the CBC output block from the previous message. Padding and IVs for subsequent messages are done as in phase 1. After the ISAKMP SA has been authenticated all Informational Exchanges are encrypted using SKEYID_e. The initiaization vector for these exchanges is derived in exactly the same fashion as that for a Quick Mode-- i.e. it is derived from a hash of a concatenation of the last phase 1 CBC output block and the message id from the ISAKMP header of the Informational Exchange (not the message id from the message that may have prompted the Informational Exchange). Note that the final phase 1 CBC output block, the result of encryption/decryption of the last phase 1 message, must be retained in the ISAKMP SA state to allow for generation of unique IVs for each Quick Mode. Each post- phase 1 exchange (Quick Modes and Informational Exchanges) generates IVs independantly to prevent IVs from getting out of sync when two different exchanges are started Harkins, Carrel [Page 37] INTERNET DRAFT February 1998 simultaneously. In all cases, there is a single bidirectional cipher/IV context. Having each Quick Mode and Informational Exchange maintain a unique context prevents IVs from getting out of sync. The key for DES-CBC is derived from the first eight (8) non-weak and non-semi-weak (see Appendix A) bytes of SKEYID_e. The IV is the first 8 bytes of the IV material derived above. The key for IDEA-CBC is derived from the first sixteen (16) bytes of SKEYID_e. The IV is the first eight (8) bytes of the IV material derived above. The key for Blowfish-CBC is either the negotiated key size, or the first fifty-six (56) bytes of a key (if no key size is negotiated) derived in the aforementioned pseudo-random function feedback method. The IV is the first eight (8) bytes of the IV material derived above. The key for RC5-R16-B64-CBC is the negotiated key size, or the first sixteen (16) bytes of a key (if no key size is negotiated) derived from the aforementioned pseudo-random function feedback method if necessary. The IV is the first eight (8) bytes of the IV material derived above. The number of rounds MUST be 16 and the block size MUST be 64. The key for 3DES-CBC is the first twenty-four (24) bytes of a key derived in the aforementioned pseudo-random function feedback method. 3DES-CBC is an encrypt-decrypt-encrypt operation using the first, middle, and last eight (8) bytes of the entire 3DES-CBC key. The IV is the first eight (8) bytes of the IV material derived above. The key for CAST-CBC is either the negotiated key size, or the first sixteen (16) bytes of a key derived in the aforementioned pseudo- random function feedback method. The IV is the first eight (8) bytes of the IV material derived above. Support for algorithms other than DES-CBC is purely optional. Some optional algorithms may be subject to intellectual property claims. Harkins, Carrel [Page 38] INTERNET DRAFT February 1998 Authors' Addresses: Dan Harkins cisco Systems 170 W. Tasman Dr. San Jose, California, 95134-1706 United States of America +1 408 526 4000 Dave Carrel 76 Lippard Ave. San Francisco, CA 94131-2947 United States of America +1 415 337 8469 Authors' Note: The authors encourage independent implementation, and interoperability testing, of this hybrid protocol. Harkins, Carrel [Page 39] From owner-ipsec Mon Feb 16 07:40:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA20120 for ipsec-outgoing; Mon, 16 Feb 1998 07:40:44 -0500 (EST) Date: Mon, 16 Feb 1998 07:40:44 -0500 (EST) From: owner-ipsec@ex.tis.com Message-Id: <199802142321.SAA11508@relay.rv.tis.com> 25766; 13 Feb 98 15:24 EST Date: Fri, 13 Feb 98 15:21:11 EST From: Karen Seo To: internet-drafts@ietf.org cc: tytso@mit.edu, rgm-sec@homebase.htt-consult.com, skent@bbn.com, kseo@bbn.com Subject: Internet Draft -- IPsec ESP spec Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk Hello, Please find attached the Internet Draft for the IPsec ESP specification. Thank you, Karen Network Working Group Stephen Kent, BBN Corp Internet Draft Randall Atkinson, @Home Network draft-ietf-ipsec-esp-v2-03.txt February 1998 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 IPsec working group. 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. Copyright (C) The Internet Society (February 1998). All Rights Reserved. Kent, Atkinson [Page 1] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) Table of Contents 1. Introduction......................................................3 2. Encapsulating Security Payload Packet Format......................4 2.1 Security Parameters Index....................................5 2.2 Sequence Number .............................................5 2.3 Payload Data.................................................5 2.4 Padding (for Encryption).....................................6 2.5 Pad Length...................................................7 2.6 Next Header..................................................7 2.7 Authentication Data..........................................8 3. Encapsulating Security Protocol Processing........................8 3.1 ESP Header Location..........................................8 3.2 Algorithms..................................................10 3.2.1 Encryption Algorithms..................................10 3.2.2 Authentication Algorithms..............................11 3.3 Outbound Packet Processing..................................11 3.3.1 Security Association Lookup............................11 3.3.2 Packet Encryption......................................11 3.3.3 Sequence Number Generation.............................12 3.3.4 Integrity Check Value Calculation......................12 3.3.5 Fragmentation..........................................13 3.4 Inbound Packet Processing...................................13 3.4.1 Reassembly.............................................13 3.4.2 Security Association Lookup............................14 3.4.3 Sequence Number Verification...........................14 3.4.4 Integrity Check Value Verification.....................16 3.4.5 Packet Decryption......................................16 4. Auditing.........................................................18 5. Conformance Requirements.........................................18 6. Security Considerations..........................................18 7. Differences from RFC 1827........................................19 Acknowledgements....................................................19 References..........................................................19 Disclaimer..........................................................20 Author Information..................................................21 Kent, Atkinson [Page 2] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) 1. Introduction The Encapsulating Security Payload (ESP) header is designed to provide a mix of 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 "Security Architecture for the Internet Protocol" [KA97a], hereafter referred to as the Security Architecture document). 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 the Security Architecture document [KA97a]. The ESP header is inserted after the IP header and before the upper layer protocol header (transport mode) or before an encapsulated IP header (tunnel mode). These modes are described in more detail below. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. The set of services provided depends on options selected at the time of Security Association establishment and on the placement of the implementation. Confidentiality may be selected independent of all other services. However, use of confidentiality without integrity/authentication (either in ESP or separately in AH) may subject traffic to certain forms of active attacks that could undermine the confidentiality service (see [Bel96]). Data origin authentication and connectionless integrity are joint services (hereafter referred to jointly as "authentication) and are offered as an option in conjunction with confidentiality. The anti-replay service may be selected only if data origin authentication is selected, and its election is solely at the discretion of the receiver. (Although the default calls for the sender to increment the Sequence Number used for anti-replay, the service is effective only if the receiver checks the Sequence Number.) Traffic flow confidentiality requires selection of tunnel mode, and is most effective if implemented at a security gateway, where traffic aggregation may be able to mask true source-destination patterns. It is assumed that the reader is familiar with the terms and concepts described in the Security Architecture document. In particular, the reader should be familiar with the definitions of security services offered by ESP and AH, the concept of Security Associations, the ways in which ESP can be used in conjunction with the Authentication Header (AH), and the different key management options available for Kent, Atkinson [Page 3] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) ESP and AH. (With regard to the last topic, the current key management options required for both AH and ESP are manual keying and automated keying via ISAKMP/Oakley.) The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [Bra97]. 2. Encapsulating Security Payload Packet Format The protocol header (IPv4, IPv6, or Extension) immediately preceding the ESP header will contain the value 50 in its Protocol (IPv4) or Next Header (IPv6, Extension) field [STD-2]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- | Security Parameters Index (SPI) | ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Auth. | Sequence Number | |Coverage +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----- | Payload Data* (variable) | | ^ ~ ~ | | | | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Confid. | | Padding (0-255 bytes) | |Coverage* +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Pad Length | Next Header | v v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------- | Authentication Data (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * If included in the Payload field, cryptographic synchronization data, e.g., an Initialization Vector (IV, see Section 2.3), usually is not encrypted per se, although it often is referred to as being part of the ciphertext. 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 Integrity Check Value (ICV, see Section 2.7). 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 Kent, Atkinson [Page 4] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) 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 that, in combination with the destination IP address and security protocol (ESP), uniquely identifies the Security Association for this datagram. 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. It is ordinarily selected by the destination system upon establishment of an SA (see the Security Architecture document for more details). The SPI field is mandatory. The SPI value of zero (0) is reserved for local, implementation- specific use and MUST NOT be sent on the wire. For example, a key management implementation MAY use the zero SPI value to mean "No Security Association Exists" during the period when the IPsec implementation has requested that its key management entity establish a new SA, but the SA has not yet been established. 2.2 Sequence Number This unsigned 32-bit field contains a monotonically increasing counter value (sequence number). It is mandatory and is always present even if the receiver does not elect to enable the anti-replay service for a specific SA. Processing of the Sequence Number field is at the discretion of the receiver, i.e., the sender MUST always transmit this field, but the receiver need not act upon it (see the discussion of Sequence Number Verification in the "Inbound Packet Processing" section below). The sender's counter and the receiver's counter are initialized to 0 when an SA is established. (The first packet sent using a given SA will have a Sequence Number of 1; see Section 3.3.3 for more details on how the Sequence Number is generated.) If anti-replay is enabled (the default), the transmitted Sequence Number must never be allowed to cycle. Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA. 2.3 Payload Data Payload Data is a variable-length field containing data described by the Next Header field. The Payload Data field is mandatory and is an Kent, Atkinson [Page 5] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) integral number of bytes in length. If the algorithm used to encrypt the payload requires cryptographic synchronization data, e.g., an Initialization Vector (IV), then this data MAY be carried explicitly in the Payload field. Any encryption algorithm that requires such explicit, per-packet synchronization data MUST indicate the length, any structure for such data, and the location of this data as part of an RFC specifying how the algorithm is used with ESP. If such synchronization data is implicit, the algorithm for deriving the data MUST be part of the RFC. Note that with regard to ensuring the alignment of the (real) ciphertext in the presence of an IV: o For some IV-based modes of operation, the receiver treats the IV as the start of the ciphertext, feeding it into the algorithm directly. In these modes, alignment of the start of the (real) ciphertext is not an issue at the receiver. o In some cases, the receiver reads the IV in separately from the ciphertext. In these cases, the algorithm specification MUST address how alignment of the (real) ciphertext is to be achieved. 2.4 Padding (for Encryption) Several factors require or motivate use of the Padding field. o If an encryption algorithm is employed that requires the plaintext to be a multiple of some number of bytes, e.g., the block size of a block cipher, the Padding field is used to fill the plaintext (consisting of the Payload Data, Pad Length and Next Header fields, as well as the Padding) to the size required by the algorithm. o Padding also may be required, irrespective of encryption algorithm requirements, to ensure that the resulting ciphertext terminates on a 4-byte boundary. Specifically, the Pad Length and Next Header fields must be right aligned within a 4-byte word, as illustrated in the ESP packet format figure above, to ensure that the Authentication Data field (if present) is aligned on a 4-byte boundary. o Padding beyond that required for the algorithm or alignment reasons cited above, may be used to conceal the actual length of the payload, in support of (partial) traffic flow confidentiality. However, inclusion of such additional padding has adverse bandwidth implications and thus its use should be undertaken with care. Kent, Atkinson [Page 6] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) The sender MAY add 0-255 bytes of padding. Inclusion of the Padding field in an ESP packet is optional, but all implementations MUST support generation and consumption of padding. The padding computation applies to the plaintext portion of the Payload Data, exclusive of the IV (if present). If Padding bytes are needed but the encryption algorithm does not specify the padding contents, then the following default processing MUST be used. The Padding bytes are initialized with a series of (unsigned, 1-byte) integer values. The first padding byte appended to the plaintext is numbered 1, with subsequent padding bytes making up a monotonically increasing sequence: 1, 2, 3, ... When this padding scheme is employed, the receiver SHOULD inspect the Padding field. (This scheme was selected because of its relative simplicity, ease of implementation in hardware, and because it offers limited protection against certain forms of "cut and paste" attacks in the absence of other integrity measures, if the receiver checks the padding values upon decryption.) Any encryption algorithm that requires Padding other than the default described above, MUST define the Padding contents (e.g., zeros or random data) and any required receiver processing of these Padding bytes in an RFC specifying how the algorithm is used with ESP. In such circumstances, the content of the Padding field will be determined by the encryption algorithm and mode selected and defined in the corresponding algorithm RFC. The relevant algorithm RFC MAY specify that a receiver MUST inspect the Padding field or that a receiver MUST inform senders of how the receiver will handle the Padding field. 2.5 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 no Padding bytes are present. The Pad Length field is mandatory. 2.6 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. Kent, Atkinson [Page 7] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) 2.7 Authentication Data The Authentication Data is a variable-length field containing an Integrity Check Value (ICV) computed over the ESP packet minus the Authentication Data. The length of the field is specified by the authentication function selected. The Authentication Data field is optional, and is included only if the authentication service has been selected for the SA in question. The authentication algorithm specification MUST specify the length of the ICV and the comparison rules and processing steps for validation. 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, note that for "bump-in-the-stack" or "bump-in-the- wire" implementations, as defined in the Security Architecture document, inbound and outbound IP fragments may require an IPsec implementation to perform extra IP reassembly/fragmentation in order to both conform to this specification and provide transparent IPsec support. Special care is required to perform such operations within these implementations when multiple interfaces are in use.) In transport mode, ESP is inserted after the IP header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other IPsec headers that have already been inserted. 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.) Kent, Atkinson [Page 8] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) BEFORE APPLYING ESP ---------------------------- IPv4 |orig IP hdr | | | |(any options)| TCP | Data | ---------------------------- AFTER APPLYING ESP ------------------------------------------------- IPv4 |orig IP hdr | ESP | | | ESP | ESP| |(any options)| Hdr | 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. BEFORE APPLYING ESP --------------------------------------- IPv6 | | ext hdrs | | | | orig IP hdr |if present| TCP | Data | --------------------------------------- AFTER APPLYING ESP --------------------------------------------------------- IPv6 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP| |IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer|Auth| --------------------------------------------------------- |<---- encrypted ---->| |<---- authenticated ---->| * = if present, could be before ESP, after ESP, or both ESP and AH headers can be combined in a variety of modes. The IPsec Architecture document describes the combinations of security associations that must be supported. 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 Kent, Atkinson [Page 9] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) "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* |new ext | | orig*|orig ext | | | ESP | ESP| |IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer|Auth| ------------------------------------------------------------ |<--------- encrypted ----------->| |<---------- authenticated ---------->| * = if present, construction of outer IP hdr/extensions and modification of inner IP hdr/extensions is discussed below. 3.2 Algorithms The mandatory-to-implement algorithms are described in Section 5, "Conformance Requirements". Other algorithms MAY be supported. 3.2.1 Encryption Algorithms 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 any data required to allow the receiver to establish cryptographic synchronization for decryption. This data may be carried explicitly in the payload field, e.g., as an IV (as described above), or the data may be derived from the packet header. Since ESP makes provision for padding of the plaintext, encryption algorithms employed with ESP may exhibit either block or stream mode characteristics. Kent, Atkinson [Page 10] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) 3.2.2 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 appropriate, though performance and space considerations currently preclude use of such algorithms. 3.3 Outbound Packet Processing In transport mode, the sender 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 Security Architecture document. If there is more than one IPsec header/extension required by security policy, the order of the application of the security headers MUST be defined by security policy. 3.3.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 Security Architecture document. 3.3.2 Packet Encryption The sender: 1. encapsulates (into the ESP Payload field): - for transport mode -- just the original upper layer protocol information. - for tunnel mode -- the entire original IP datagram. 2. adds any necessary padding. 3. encrypts the result (Payload Data, Padding, Pad Length, and Next Header) using the key, encryption algorithm, algorithm mode indicated by the SA and cryptographic synchronization data (if any). - If explicit cryptographic synchronization data, e.g., an IV, is indicated, it is input to the decryption algorithm per the algorithm specification and placed Kent, Atkinson [Page 11] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) in the Payload field. - If implicit cryptographic synchronication data, e.g., an IV, is indicated, it is constructed and input to the decryption algorithm as per the algorithm specification. The exact steps for constructing the outer IP header depend on the mode (transport or tunnel) and are described in the Security Architecture document. If authentication is 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. 3.3.3 Sequence Number Generation The sender's counter is initialized to 0 when an SA is established. The sender increments the Sequence Number for this SA and inserts the new value into the Sequence Number field. Thus the first packet sent using a given SA will have a Sequence Number of 1. If anti-replay is enabled (the default), the sender checks to ensure that the counter has not cycled before inserting the new value in the Sequence Number field. In other words, the sender MUST NOT send a packet on an SA if doing so would cause the Sequence Number to cycle. An attempt to transmit a packet that would result in Sequence Number overflow is an auditable event. (Note that this approach to Sequence Number management does not require use of modular arithmetic.) If anti-replay has been disabled, the sender does not need to monitor or reset the counter, e.g., in the case of manual key management (see Section 5). 3.3.4 Integrity Check Value Calculation If authentication is selected for the SA, the sender computes the ICV over the ESP packet minus the Authentication Data. Thus the SPI, Sequence Number, Payload Data, Padding (if present), Pad Length, and Next Header are all encompassed by the ICV computation. Note that the last 4 fields will be in ciphertext form, since encryption is Kent, Atkinson [Page 12] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) performed prior to authentication. 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, (after the Next Header field) 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. Note that MD5 and SHA-1 are viewed as having a 1-byte blocksize because of their internal padding conventions. 3.3.5 Fragmentation If necessary, fragmentation is performed after ESP processing within an IPsec implementation. Thus, transport mode ESP is applied only to whole IP datagrams (not to IP fragments). An IP packet to which ESP has been applied may itself be fragmented by routers en route, and such fragments must be reassembled prior to ESP processing at a receiver. In tunnel mode, ESP is applied to an IP packet, the payload of which may be a fragmented IP packet. For example, a security gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation (as defined in the Security Architecture document) may apply tunnel mode ESP to such fragments. NOTE: For transport mode -- As mentioned at the beginning of Section 3.1, bump-in-the-stack and bump-in-the-wire implementations may have to first reassemble a packet fragmented by the local IP layer, then apply IPsec, and then fragment the resulting packet. NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire implementations, it will be necessary to walk through all the extension headers to determine if there is a fragmentation header and hence that the packet needs reassembling prior to IPsec processing. 3.4 Inbound Packet Processing 3.4.1 Reassembly If required, reassembly is performed prior to ESP processing. If a packet offered to ESP for processing appears to be an IP fragment, i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, Kent, Atkinson [Page 13] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID. NOTE: For packet reassembly, the current IPv4 spec does NOT require either the zero'ing of the OFFSET field or the clearing of the MORE FRAGMENTS flag. In order for a reassembled packet to be processed by IPsec (as opposed to discarded as an apparent fragment), the IP code must do these two things after it reassembles a packet. 3.4.2 Security Association Lookup Upon receipt of a (reassembled) packet containing an ESP Header, the receiver determines the appropriate (unidirectional) SA, based on the destination IP address, security protocol (ESP), and the SPI. (This process is described in more detail in the Security Architecture document.) The SA indicates whether the Sequence Number field will be checked, whether the Authentication Data field 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 packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the cleartext Flow ID. 3.4.3 Sequence Number Verification All ESP implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. This service MUST NOT be enabled unless the authentication service also is enabled for the SA, since otherwise the Sequence Number field has not been integrity protected. (Note that there are no provisions for managing transmitted Sequence Number values among multiple senders directing traffic to a single SA (irrespective of whether the destination address is unicast, broadcast, or multicast). Thus the anti-replay service SHOULD NOT be used in a multi-sender environment that employs a single SA.) If the receiver does not enable anti-replay for an SA, no inbound checks are performed on the Sequence Number. The default for the sender is that the Sequence Number will be checked at the sender. Hence, if an SA establishment protocol such as ISAKMP/Oakley is employed, the receiver SHOULD notify the sender, during SA establishment, if the receiver will not provide anti-replay Kent, Atkinson [Page 14] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) protection. If the receiver has enabled the anti-replay service for this SA, the receive packet counter for the SA MUST be initialized to zero when the SA is established. For each received packet, 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 ESP 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.) A MINIMUM window size of 32 MUST be supported; but a window size of 64 is preferred and SHOULD be employed as the default. Another window size (larger than the MINIMUM) MAY be chosen by the receiver. (The receiver does NOT notify the sender of the window size.) The "right" edge of the window represents the highest, validated Sequence Number 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 the Security Architecture document. If the received packet falls within the window and is new, or if the packet is to the right of the window, then the receiver proceeds to ICV verification. If the ICV validation fails, the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, the Sequence Number, and (in IPv6) the Flow ID. The receive window is updated only if the ICV verification succeeds. DISCUSSION: Note that if the packet is either inside the window and new, or is outside the window on the "right" side, the receiver MUST authenticate the packet before updating the Sequence Number window data. Kent, Atkinson [Page 15] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) 3.4.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; this is an auditable event. The log data SHOULD include the SPI value, date/time received, Source Address, Destination Address, and (in IPv6) the cleartext Flow ID. 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 saved value, using the comparison rules defined by the algorithm specification. (For example, if a digital signature and one-way hash are used for the ICV computation, the matching process is more complex.) 3.4.5 Packet Decryption The receiver: 1. decrypts the ESP Payload Data, Padding, Pad Length, and Next Header using the key, encryption algorithm, algorithm mode, and cryptographic synchronization data (if any), indicated by the SA. - If explicit cryptographic synchronization data, e.g., an IV, is indicated, it is taken from the Payload field and input to the decryption algorithm as per the algorithm specification. - If implicit cryptographic synchronization data, e.g., an IV, is indicated, a local version of the IV is constructed and input to the decryption algorithm as per the algorithm specification. 2. processes any padding as specified in the encryption algorithm specification. The default action is to remove/ignore any padding. Kent, Atkinson [Page 16] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) 3. reconstructs the original IP datagram from: - for transport mode -- original IP header plus the original upper layer protocol information in the ESP Payload field - for tunnel mode -- tunnel IP header + the entire IP datagram in the ESP Payload field. The exact steps for reconstructing the original datagram depend on the mode (transport or tunnel) and are described in the Security Architecture document. At a minimum, in an IPv6 context, the receiver SHOULD ensure that the decrypted data is 8-byte aligned, to facilitate processing by the protocol identified in the Next Header field. If authentication has been selected, verification and decryption MAY be performed serially or in parallel. If performed serially, then ICV verification SHOULD be performed first. If performed in parallel, verification MUST be completed before the decrypted packet is passed on for further processing. 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. Note: If the receiver performs decryption in parallel with authentication, care must be taken to avoid possible race conditions with regard to packet access and reconstruction of the decrypted packet. Note that there are several ways in which the decryption can "fail": a. The selected SA may not be correct -- The SA may be mis-selected due to tampering with the SPI, destination address. or IPsec protocol type fields. Such errors, if they map the packet to another extant SA, will be indistinguishable from a corrupted packet, (case c). Tampering with the SPI can be detected by use of authentication. However, an SA mismatch might still occur due to tampering with the IP Destination Address or the IPsec protocol type field. b. The pad length or pad values could be erroneous -- Bad pad lengths or pad values can be detected irrespective of the use of authentication. c. The encrypted ESP packet could be corrupted -- This can be detected if authentication is selected for the SA., In case (a) or (c), the erroneous result of the decryption operation (an invalid IP datagram or transport-layer frame) will not Kent, Atkinson [Page 17] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) necessarily be detected by IPsec, and is the responsibility of later protocol processing. 4. Auditing Not all systems that implement ESP will implement auditing. However, if ESP is incorporated into a system that supports auditing, then the ESP implementation MUST also support auditing and MUST allow a system administrator to enable or disable auditing for ESP. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in this specification and for each of these events a minimum set of information that SHOULD be included in an audit log is defined. Additional information also MAY be included in the audit log for each of these events, and additional events, not explicitly called out in this specification, also MAY result in audit log entries. There is no requirement for the receiver to transmit any message to the purported sender in response to the detection of an auditable event, because of the potential to induce denial of service via such action. 5. 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 document. If the key used to compute an ICV is manually distributed, correct provision of the anti-replay service would require correct maintenance of the counter state at the sender, until the key is replaced, and there likely would be no automated recovery provision if counter overflow were imminent. Thus a compliant implementation SHOULD NOT provide this service in conjunction with SAs that are manually keyed. A compliant ESP implementation MUST support the following mandatory-to-implement algorithms: - DES in CBC mode [MD97] - HMAC with MD5 [MG97a] - HMAC with SHA-1 [MG97b] 6. Security Considerations Security is central to the design of this protocol, and thus security considerations permeate the specification. Additional security- relevant aspects of using the IPsec protocol are discussed in the Security Architecture document. Kent, Atkinson [Page 18] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) 7. Differences from RFC 1827 This document differs from RFC 1827 [ATK95] in several significant ways. The major difference is that, this document attempts to specify a complete framework and context for ESP, whereas RFC 1827 provided a "shell" that was completed through the definition of transforms. The combinatorial growth of transforms motivated the reformulation of the ESP specification as a more complete document, with options for security services that may be offered in the context of ESP. Thus, fields previously defined in transform documents are now part of this base ESP specification. For example, the fields necessary to support authentication (and anti-replay) are now defined here, even though the provision of this service is an option. The fields used to support padding for encryption, and for next protocol identification, are now defined here as well. Packet processing consistent with the definition of these fields also is included in the document. 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 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 Karen Seo for providing extensive help in the review, editing, background research, and coordination for this version of the specification. The authors would also 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, Norman Shulman, William Simpson and Nina Yuan. References [ATK95] R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 1827, August 1997. [Bel96] Steven M. Bellovin, "Problem Areas for the IP Security Protocols", Proceedings of the Sixth Usenix Unix Security Kent, Atkinson [Page 19] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) Symposium, July, 1996. [Bra97] S. Bradner, "Key words for use in RFCs to Indicate Requirement Level," RFC-2119, March 1997. [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. [KA97a] Steve Kent, Randall Atkinson, "Security Architecture for the Internet Protocol", Internet Draft, February 1998. [KA97b] Steve Kent, Randall Atkinson, "IP Authentication Header", Internet Draft, February 1998. [MD97] C. Madson & N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", Internet Draft, Deceber 1997. [MG97a] C. Madson & R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", Internet Draft, November 1997. [MG97b] C. Madson & R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", Internet Draft, November 1997. [STD-2] J. Reynolds and J. Postel, "Assigned Numbers", STD-2, 20 October 1994. [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. 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. Kent, Atkinson [Page 20] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) Author Information Stephen Kent BBN Corporation 70 Fawcett Street Cambridge, MA 02140 USA E-mail: kent@bbn.com Telephone: +1 (617) 873-3988 Randall Atkinson @Home Network 425 Broadway, Redwood City, CA 94063 USA E-mail: rja@inet.org Copyright (C) The Internet Society (February 1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Kent, Atkinson [Page 21] From owner-ipsec Mon Feb 16 07:41:44 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA20155 for ipsec-outgoing; Mon, 16 Feb 1998 07:41:43 -0500 (EST) Message-Id: <199802142321.SAA11507@relay.rv.tis.com> Date: Fri, 13 Feb 98 15:19:58 EST From: Karen Seo To: internet-drafts@ietf.org cc: tytso@mit.edu, rgm-sec@homebase.htt-consult.com, skent@bbn.com, kseo@bbn.com Subject: Internet Draft -- IPsec AH spec Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, Please find attached the Internet Draft for the IPsec AH specification. Thank you, Karen Network Working Group Stephen Kent, BBN Corp Internet Draft Randall Atkinson, @Home Network draft-ietf-ipsec-auth-header-04.txt February 1998 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 IPsec Working Group. 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. Copyright (C) The Internet Society (February 1998). All Rights Reserved. Kent, Atkinson [Page 1] Internet Draft IP Authentication Header February 1998 Table of Contents 1. Introduction......................................................3 2. Authentication Header Format......................................4 2.1 Next Header...................................................4 2.2 Payload Length................................................4 2.3 Reserved......................................................5 2.4 Security Parameters Index (SPI)...............................5 2.5 Sequence Number...............................................5 2.6 Authentication Data ..........................................6 3. Authentication Header Processing..................................6 3.1 Authentication Header Location...............................6 3.2 Authentication Algorithms....................................8 3.3 Outbound Packet Processing...................................8 3.3.1 Security Association Lookup.............................9 3.3.2 Sequence Number Generation..............................9 3.3.3 Integrity Check Value Calculation.......................9 3.3.3.1 Handling Mutable Fields...........................10 3.3.3.1.1 ICV Computation for IPv4.....................10 3.3.3.1.1.1 Base Header Fields.......................10 3.3.3.1.1.2 Options..................................11 3.3.3.1.2 ICV Computation for IPv6.....................11 3.3.3.1.2.1 Base Header Fields.......................11 3.3.3.1.2.2 Extension Headers -- Options.............12 3.3.3.1.2.3 Extension Headers -- non-Options.........12 3.3.3.2 Padding...........................................12 3.3.3.2.1 Authentication Data Padding..................12 3.3.3.2.2 Implicit Packet Padding......................13 3.3.4 Fragmentation..........................................13 3.4 Inbound Packet Processing...................................13 3.4.1 Reassembly.............................................13 3.4.2 Security Association Lookup............................14 3.4.3 Sequence Number Verification...........................14 3.4.4 Integrity Check Value Verification.....................15 4. Auditing.........................................................16 5. Conformance Requirements.........................................16 6. Security Considerations..........................................17 7. Differences from RFC 1826........................................17 Acknowledgements....................................................17 Appendix A -- Mutability of IP Options/Extension Headers............19 A1. IPv4 Options.................................................19 A2. IPv6 Extension Headers.......................................20 References..........................................................22 Disclaimer..........................................................22 Author Information..................................................22 Kent, Atkinson [Page 2] Internet Draft IP Authentication Header February 1998 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, by the receiver, when a Security Association is established. (Although the default calls for the sender to increment the Sequence Number used for anti-replay, the service is effective only if the receiver checks the Sequence Number.) 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 sender. 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 "Security Architecture for the Internet Protocol" [KA97a], hereafter referred to as the Security Architecture document). 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 a confidentiality (encryption) service. The primary difference between the authentication provided by ESP and AH is the extent of the coverage. Specifically, ESP does not protect any IP header fields unless those fields are encapsulated by ESP (tunnel mode). For more details on how to use AH and ESP in various network environments, see the Security Architecture document [KA97a]. It is assumed that the reader is familiar with the terms and concepts described in the Security Architecture document. In particular, the reader should be familiar with the definitions of security services offered by AH and ESP, the concept of Security Associations, the ways in which AH can be used in conjunction with ESP, and the different key management options available for AH and ESP. (With regard to the last topic, the current key management options required for both AH and ESP are manual keying and automated keying via ISAKMP/Oakley.) The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [Bra97]. Kent, Atkinson [Page 3] Internet Draft IP Authentication Header February 1998 2. Authentication Header Format The protocol header (IPv4, IPv6, or Extension) immediately preceding the AH header will contain the value 51 in its Protocol (IPv4) or Next Header (IPv6, Extension) field [STD-2]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Payload Len | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Authentication Data (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following subsections define the fields that comprise the AH format. All the fields described here are mandatory, i.e., they are always present in the AH format and are included in the Integrity Check Value (ICV) computation (see Sections 2.6 and 3.3.3). 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). 2.2 Payload Length This 8-bit field specifies the length of AH in 32-bit words (4-byte units), minus "2". (All IPv6 extension headers, as per RFC 1883, encode the "Hdr Ext Len" field by first subtracting 1 (64-bit word) from the header length (measured in 64-bit words). AH is an IPv6 extension header. However, since its length is measured in 32-bit words, the "Payload Length" is calculated by subtracting 2 (32 bit words).) In the "standard" case of a 96-bit authentication value plus the 3 32-bit word fixed portion, this length field will be "4". A "null" authentication algorithm may be used only for debugging purposes. Its use would result in a "1" value for this field for IPv4 or a "2" for IPv6, as there would be no corresponding Authentication Data field (see Section 3.3.3.2.1 on "Authentication Kent, Atkinson [Page 4] Internet Draft IP Authentication Header February 1998 Data Padding"). 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.) 2.4 Security Parameters Index (SPI) The SPI is an arbitrary 32-bit value that, in combination with the destination IP address and security protocol (AH), uniquely identifies the Security Association for this datagram. 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. It is ordinarily selected by the destination system upon establishment of an SA (see the Security Architecture document for more details). The SPI value of zero (0) is reserved for local, implementation- specific use and MUST NOT be sent on the wire. For example, a key management implementation MAY use the zero SPI value to mean "No Security Association Exists" during the period when the IPsec implementation has requested that its key management entity establish a new SA, but the SA has not yet been established. 2.5 Sequence Number This unsigned 32-bit field contains a monotonically increasing counter value (sequence number). It is mandatory and is always present even if the receiver does not elect to enable the anti-replay service for a specific SA. Processing of the Sequence Number field is at the discretion of the receiver, i.e., the sender MUST always transmit this field, but the receiver need not act upon it (see the discussion of Sequence Number Verification in the "Inbound Packet Processing" section below). The sender's counter and the receiver's counter are initialized to 0 when an SA is established. (The first packet sent using a given SA will have a Sequence Number of 1; see Section 3.3.2 for more details on how the Sequence Number is generated.) If anti-replay is enabled (the default), the transmitted Sequence Number must never be allowed to cycle. Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA. Kent, Atkinson [Page 5] Internet Draft IP Authentication Header February 1998 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.3.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 below. The authentication algorithm specification MUST specify the length of the ICV and the comparison rules and processing steps for validation. 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, note that for "bump-in- the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document, inbound and outbound IP fragments may require an IPsec implementation to perform extra IP reassembly/fragmentation in order to both conform to this specification and provide transparent IPsec support. Special care is required to perform such operations within these implementations when multiple interfaces are in use.) In transport mode, AH is inserted after the IP header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other IPsec headers that have already been inserted. 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. Kent, Atkinson [Page 6] Internet Draft IP Authentication Header February 1998 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. BEFORE APPLYING AH --------------------------------------- IPv6 | | ext hdrs | | | | orig IP hdr |if present| TCP | Data | --------------------------------------- AFTER APPLYING AH ------------------------------------------------------------ IPv6 | |hop-by-hop, dest*, | | dest | | | |orig IP hdr |routing, fragment. | AH | opt* | TCP | Data | ------------------------------------------------------------ |<---- authenticated except for mutable fields ----------->| * = if present, could be before AH, after AH, or both ESP and AH headers can be combined in a variety of modes. The IPsec Architecture document describes the combinations of security associations that must be supported. Tunnel mode AH may be employed in either hosts or security gateways (or in so-called "bump-in-the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document). When AH is implemented in a security gateway (to protect 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 Kent, Atkinson [Page 7] Internet Draft IP Authentication Header February 1998 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 -->| | in the new IP hdr | -------------------------------------------------------------- IPv6 | | ext hdrs*| | | ext hdrs*| | | |new IP hdr*|if present| AH |orig IP hdr*|if present|TCP|Data| -------------------------------------------------------------- |<-- authenticated except for mutable fields in new IP hdr ->| * = construction of outer IP hdr/extensions and modification of inner IP hdr/extensions is discussed below. 3.2 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 appropriate, though performance and space considerations currently preclude use of such algorithms. The mandatory-to-implement authentication algorithms are described in Section 5 "Conformance Requirements". Other algorithms MAY be supported. 3.3 Outbound Packet Processing In transport mode, the sender 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 Security Architecture document. If there is more than one IPsec header/extension required, the order of the application of the security headers MUST be defined by security policy. For simplicity of processing, each IPsec header Kent, Atkinson [Page 8] Internet Draft IP Authentication Header February 1998 SHOULD ignore the existence (i.e., not zero the contents or try to predict the contents) of IPsec headers to be applied later. (While a native IP or bump-in-the-stack implementation could predict the contents of later IPsec headers that it applies itself, it won't be possible for it to predict any IPsec headers added by a bump-in-the- wire implementation between the host and the network.) 3.3.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 Security Architecture document. 3.3.2 Sequence Number Generation The sender's counter is initialized to 0 when an SA is established. The sender increments the Sequence Number for this SA and inserts the new value into the Sequence Number Field. Thus the first packet sent using a given SA will have a Sequence Number of 1. If anti-replay is enabled (the default), the sender checks to ensure that the counter has not cycled before inserting the new value in the Sequence Number field. In other words, the sender MUST not send a packet on an SA if doing so would cause the Sequence Number to cycle. An attempt to transmit a packet that would result in Sequence Number overflow is an auditable event. (Note that this approach to Sequence Number management does not require use of modular arithmetic.) If anti-replay has been disabled, the sender does not need to monitor or reset the counter, e.g., in the case of manual key management. 3.3.3 Integrity Check Value Calculation The AH ICV is computed over: o IP header fields that are either immutable in transit or that are predictable in value upon arrival at the endpoint for the AH SA o the AH header (Next Header, Payload Len, Reserved, SPI, Sequence Number, and the Authentication Data (which is set to zero for this computation)) o the upper level protocol data, which is assumed to be immutable in transit Kent, Atkinson [Page 9] Internet Draft IP Authentication Header February 1998 3.3.3.1 Handling Mutable Fields If a field may be 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 is also 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. Also, the zero-fill approach ensures that the length of the fields that are so handled cannot be changed during transit, even though their contents are not explicitly covered by the ICV. As a new extension header or IPv4 option is created, it will be defined in its own RFC and SHOULD include (in the Security Considerations section) directions for how it should be handled when calculating the AH ICV. If the IPsec implementation encounters an extension header that it does not recognize, it MUST zero the whole header except for the Next Header and Hdr Ext Len fields. The length of the extension header MUST be computed by 8 * Hdr Ext Len value + 8. If the IPsec implementation encounters an IPv4 option that it does not recognize, it should zero the whole option, using the second byte of the option as the length. (IPv6 options contain a flag indicating mutability, which determines appropriate processing for such options.) 3.3.3.1.1 ICV Computation for IPv4 3.3.3.1.1.1 Base Header Fields The IPv4 base header fields are classified as follows: Immutable Version Internet Header Length Total Length Identification Protocol (This should be the value for AH.) Source Address Destination Address (without loose or strict source routing) Mutable but predictable Destination Address (with loose or strict source routing) Kent, Atkinson [Page 10] Internet Draft IP Authentication Header February 1998 Mutable (zeroed prior to ICV calculation) Type of Service (TOS) Flags Fragment Offset Time to Live (TTL) Header Checksum TOS -- This field is excluded 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. Flags -- This field is excluded since an intermediate router might set the DF bit, even if the source did not select it. Fragment Offset -- Since AH is applied only to non-fragmented IP packets, the Offset Field must always be zero, and thus it is excluded (even though it is predictable). TTL -- This is changed en-route as a normal course of processing by routers, and thus its value at the receiver is not predictable by the sender. Header Checksum -- This will change if any of these other fields changes, and thus its value upon reception cannot be predicted by the sender. 3.3.3.1.1.2 Options For IPv4 (unlike IPv6), there is no mechanism for tagging options as mutable in transit. Hence the IPv4 options are explicitly listed in Appendix A and classified as immutable, mutable but predictable, or mutable. For IPv4, the entire option is viewed as a unit; so even though the 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. 3.3.3.1.2 ICV Computation for IPv6 3.3.3.1.2.1 Base Header Fields The IPv6 base header fields are classified as follows: Immutable Version Payload Length Next Header (This should be the value for AH.) Source Address Destination Address (without Routing Extension Header) Kent, Atkinson [Page 11] Internet Draft IP Authentication Header February 1998 Mutable but predictable Destination Address (with Routing Extension Header) Mutable (zeroed prior to ICV calculation) Class Flow Label Hop Limit 3.3.3.1.2.2 Extension Headers -- Options The IPv6 extension headers (that are options) are explicitly listed in Appendix A and classified as immutable, mutable but predictable, or mutable. IPv6 options in the Hop-by-Hop and Destination Extension Headers contain a bit that indicates whether the option might change (unpredictably) 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 options for which the bit indicates immutability are included in the ICV calculation. See the IPv6 specification [DH95] for more information. 3.3.3.1.2.3 Extension Headers -- non-Options The IPv6 extension headers (that are not options) are explicitly listed in Appendix A and classified as immutable, mutable but predictable, or mutable. 3.3.3.2 Padding 3.3.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 two factors: - the length of the ICV - the IP protocol version (v4 or v6) For example, if the output of the selected algorithm is 96-bits, no padding is required for either IPv4 or for IPv6. However, if a different length ICV is generated, due to use of a different algorithm, then padding may be required depending on the length and IP protocol version. The content of the padding field is arbitrarily Kent, Atkinson [Page 12] Internet Draft IP Authentication Header February 1998 selected by the sender. (The padding is arbitrary, but need not be random to achieve security.) These padding 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.3.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. Note that MD5 and SHA-1 are viewed as having a 1-byte blocksize because of their internal padding conventions. 3.3.4 Fragmentation If required, IP fragmentation occurs after AH processing within an IPsec implementation. Thus, transport mode AH is applied only to whole IP datagrams (not to IP fragments). An IP packet to which AH has been applied may itself be fragmented by routers en route, and such fragments must be reassembled prior to AH processing at a receiver. In tunnel mode, AH is applied to an IP packet, the payload of which may be a fragmented IP packet. For example, a security gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation (see the Security Architecture document for details) may apply tunnel mode AH to such fragments. 3.4 Inbound Packet Processing If there is more than one IPsec header/extension present, the processing for each one ignores (does not zero, does not use) any IPsec headers applied subsequent to the header being processed. 3.4.1 Reassembly If required, reassembly is performed prior to AH processing. If a packet offered to AH for processing appears to be an IP fragment, i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID. Kent, Atkinson [Page 13] Internet Draft IP Authentication Header February 1998 NOTE: For packet reassembly, the current IPv4 spec does NOT require either the zero'ing of the OFFSET field or the clearing of the MORE FRAGMENTS flag. In order for a reassembled packet to be processed by IPsec (as opposed to discarded as an apparent fragment), the IP code must do these two things after it reassembles a packet. 3.4.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, security protocol (AH), and the SPI. (This process is described in more detail in the Security Architecture document.) The SA indicates whether the Sequence Number field will be checked, specifies the algorithm(s) employed for ICV computation, and indicates 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; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID. 3.4.3 Sequence Number Verification All AH implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. (Note that there are no provisions for managing transmitted Sequence Number values among multiple senders directing traffic to a single SA (irrespective of whether the destination address is unicast, broadcast, or multicast). Thus the anti-replay service SHOULD NOT be used in a multi-sender environment that employs a single SA.) If the receiver does not enable anti-replay for an SA, no inbound checks are performed on the Sequence Number. The default for the sender is that the Sequence Number will be checked at the sender. Hence, if an SA establishment protocol such as ISAKMP/Oakley is employed, the receiver SHOULD notify the sender, during SA establishment, if the receiver will not provide anti-replay protection. If the receiver has enabled the anti-replay service for this SA, the receiver packet counter for the SA MUST be initialized to zero when the SA is established. For each received packet, 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 14] Internet Draft IP Authentication Header February 1998 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.) A MINIMUM window size of 32 MUST be supported; but a window size of 64 is preferred and SHOULD be employed as the default. Another window size (larger than the MINIMUM) MAY be chosen by the receiver. (The receiver does NOT notify the sender of the window size.) The "right" edge of the window represents the highest, validated Sequence Number 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 the Security Architecture document. If the received packet falls within the window and is new, or if the packet is to the right of the window, then the receiver proceeds to ICV verification. If the ICV validation fails, the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, the Sequence Number, and (in IPv6) the Flow ID. The receive window is updated only if the ICV verification succeeds. DISCUSSION: Note that if the packet is either inside the window and new, or is outside the window on the "right" side, the receiver MUST authenticate the packet before updating the Sequence Number window data. 3.4.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; this is an auditable event. The audit log entry SHOULD include the SPI value, date/time received, Source Address, Destination Address, and (in IPv6) the Flow ID. DISCUSSION: Kent, Atkinson [Page 15] Internet Draft IP Authentication Header February 1998 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.3.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. Perform the ICV computation and compare the result with the saved value, using the comparison rules defined by the algorithm specification. (For example, if a digital signature and one-way hash are used for the ICV computation, the matching process is more complex.) 4. Auditing Not all systems that implement AH will implement auditing. However, if AH is incorporated into a system that supports auditing, then the AH implementation MUST also support auditing and MUST allow a system administrator to enable or disable auditing for AH. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in this specification and for each of these events a minimum set of information that SHOULD be included in an audit log is defined. Additional information also MAY be included in the audit log for each of these events, and additional events, not explicitly called out in this specification, also MAY result in audit log entries. There is no requirement for the receiver to transmit any message to the purported sender in response to the detection of an auditable event, because of the potential to induce denial of service via such action. 5. 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 document. If the key used to compute an ICV is manually distributed, correct provision of the anti-replay service would require correct maintenance of the counter state at the sender, until the key is replaced, and there likely would be no automated recovery provision if counter overflow were imminent. Thus a compliant implementation SHOULD NOT provide this service in conjunction with SAs that are manually keyed. A compliant AH implementation MUST support the following mandatory-to-implement algorithms: Kent, Atkinson [Page 16] Internet Draft IP Authentication Header February 1998 - HMAC with MD5 [MG97a] - HMAC with SHA-1 [MG97b] 6. Security Considerations Security is central to the design of this protocol, and these security considerations permeate the specification. Additional security-relevant aspects of using the IPsec protocol are discussed in the Security Architecture document. 7. Differences from RFC 1826 This specification of AH differs from RFC 1826 [ATK95] in several important respects, but the fundamental features of AH remain intact. One goal of the revision of RFC 1826 was to provide a complete framework for AH, with ancillary RFCs required only for algorithm specification. For example, the anti-replay service is now an integral, mandatory part of AH, not a feature of a transform defined in another RFC. Carriage of a sequence number to support this service is now required at all times. The default algorithms required for interoperability have been changed to HMAC with MD5 or SHA-1 (vs. keyed MD5), for security reasons. The list of IPv4 header fields excluded from the ICV computation has been expanded to include the OFFSET and FLAGS fields. Another motivation for revision was to provide additional detail and clarification of subtle points. This specification provides rationale for exclusion of selected IPv4 header fields from AH coverage and provides examples on positioning of AH in both the IPv4 and v6 contexts. Auditing requirements have been clarified in this version of the specification. Tunnel mode AH was mentioned only in passing in RFC 1826, but now is a mandatory feature of AH. Discussion of interactions with key management and with security labels have been moved to the Security Architecture document. 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 Karen Seo for providing extensive help in the review, editing, background research, and coordination for this version of the specification. The authors would also like to thank the members of the IPsec and IPng working groups, with special mention of the efforts of (in alphabetic order): Kent, Atkinson [Page 17] Internet Draft IP Authentication Header February 1998 Steve Bellovin, Steve Deering, Francis Dupont, Phil Karn, Frank Kastenholz, Perry Metzger, David Mihelcic, Hilarie Orman, Norman Shulman, William Simpson, and Nina Yuan. Kent, Atkinson [Page 18] Internet Draft IP Authentication Header February 1998 Appendix A -- Mutability of IP Options/Extension Headers A1. IPv4 Options This table shows how the IPv4 options are classified with regard to "mutability". Where two references are provided, the second one supercedes the first. This table is based in part on information provided in RFC1700, "ASSIGNED NUMBERS", (October 1994). Opt. Copy Class # Name Reference ---- ----- --- ------------------------- --------- IMMUTABLE -- included in ICV calculation 0 0 0 End of Options List [RFC791] 0 0 1 No Operation [RFC791] 1 0 2 Security [RFC1108(historic but in use)] 1 0 5 Extended Security [RFC1108(historic but in use)] 1 0 6 Commercial Security [expired I-D, now US MIL STD] 1 0 20 Router Alert [RFC2113] 1 0 21 Sender Directed Multi- [RFC1770] Destination Delivery MUTABLE -- zeroed 1 0 3 Loose Source Route [RFC791] 0 2 4 Time Stamp [RFC791] 0 0 7 Record Route [RFC791] 1 0 9 Strict Source Route [RFC791] 0 2 18 Traceroute [RFC1393] EXPERIMENTAL, SUPERCEDED -- zeroed 1 0 8 Stream ID [RFC791, RFC1122 (Host Req)] 0 0 11 MTU Probe [RFC1063, RFC1191 (PMTU)] 0 0 12 MTU Reply [RFC1063, RFC1191 (PMTU)] 1 0 17 Extended Internet Protocol [RFC1385, RFC1883 (IPv6)] 0 0 10 Experimental Measurement [ZSu] 1 2 13 Experimental Flow Control [Finn] 1 0 14 Experimental Access Ctl [Estrin] 0 0 15 ??? [VerSteeg] 1 0 16 IMI Traffic Descriptor [Lee] 1 0 19 Address Extension [Ullmann IPv7] NOTE: Use of the Router Alert option is potentially incompatible with use of IPsec. Although the option is immutable, its use implies that each router along a packet's path will "process" the packet and consequently might change the packet. This would happen on a hop by hop basis as the packet goes from router to router. Prior to being processed by the application to which the option contents are directed, e.g., RSVP/IGMP, the packet should encounter AH processing. Kent, Atkinson [Page 19] Internet Draft IP Authentication Header February 1998 However, AH processing would require that each router along the path is a member of a multicast-SA defined by the SPI. This might pose problems for packets that are not strictly source routed, and it requires multicast support techniques not currently available. NOTE: Addition or removal of any security labels (BSO, ESO, CIPSO) by systems along a packet's path conflicts with the classification of these IP Options as immutable and is incompatible with the use of IPsec. NOTE: End of Options List options SHOULD be repeated as necessary to ensure that the IP header ends on a 4 byte boundary in order to ensure that there are no unspecified bytes which could be used for a covert channel. A2. IPv6 Extension Headers This table shows how the IPv6 Extension Headers are classified with regard to "mutability". Option/Extension Name Reference ----------------------------------- --------- MUTABLE BUT PREDICTABLE -- included in ICV calculation Routing (Type 0) [RFC1883] BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING TRANSIT) Hop by Hop options [RFC1883] Destination options [RFC1883] NOT APPLICABLE Fragmentation [RFC1883] Options -- IPv6 options in the Hop-by-Hop and Destination Extension Headers contain a bit that indicates whether the option might change (unpredictably) 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 options for which the bit indicates immutability are included in the ICV calculation. See the IPv6 specification [DH95] for more information. Routing (Type 0) -- 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 Kent, Atkinson [Page 20] Internet Draft IP Authentication Header February 1998 included in the Authentication Data calculation as mutable but predictable. The sender must order the field so that it appears as it will at the receiver, prior to performing the ICV computation. Fragmentation -- Fragmentation occurs after outbound IPsec processing (section 3.3) and reassembly occurs before inbound IPsec processing (section 3.4). So the Fragmentation Extension Header, if it exists, is not seen by IPsec. Note that on the receive side, the IP implementation could leave a Fragmentation Extension Header in place when it does re-assembly. If this happens, then when AH receives the packet, before doing ICV processing, AH MUST "remove" (or skip over) this header and change the previous header's "Next Header" field to be the "Next Header" field in the Fragmentation Extension Header. Note that on the send side, the IP implementation could give the IPsec code a packet with a Fragmentation Extension Header with Offset of 0 (first fragment) and a More Fragments Flag of 0 (last fragment). If this happens, then before doing ICV processing, AH MUST first "remove" (or skip over) this header and change the previous header's "Next Header" field to be the "Next Header" field in the Fragmentation Extension Header. Kent, Atkinson [Page 21] Internet Draft IP Authentication Header February 1998 References [ATK95] R. Atkinson, "The IP Authentication Header," RFC 1826, August 1995. [Bra97] S. Bradner, "Key words for use in RFCs to Indicate Requirement Level," RFC-2119, March 1997. [DH95] Steve Deering & Bob Hinden, "Internet Protocol version 6 (IPv6) Specification", RFC-1883, December 1995. [KA97a] Steve Kent, Randall Atkinson, "Security Architecture for the Internet Protocol", Internet Draft, February, 1998. [KA97b] Steve Kent, Randall Atkinson, "IP Encapsulating Security Payload (ESP)", Internet Draft, February 1998. [MG97a] C. Madson & R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", Internet Draft, November 1997. [MG97b] C. Madson & R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", Internet Draft, November 1997. [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 E-mail: kent@bbn.com Telephone: +1 (617) 873-3988 Kent, Atkinson [Page 22] Internet Draft IP Authentication Header February 1998 Randall Atkinson @Home Network 425 Broadway, Redwood City, CA 94063 USA E-mail: rja@inet.org Copyright (C) The Internet Society (February 1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Kent, Atkinson [Page 23] From owner-ipsec Mon Feb 16 07:46:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA20194 for ipsec-outgoing; Mon, 16 Feb 1998 07:46:43 -0500 (EST) Message-Id: <3.0.5.32.19980216062241.009c77c0@homebase.htt-consult.com> Date: Mon, 16 Feb 1998 06:22:41 -0500 To: Engineering , Daniel Harkins From: Robert Moskowitz Subject: Re: Help - Details on March 2nd worshop at Raliegh requested ... Cc: ipsec@tis.com In-Reply-To: References: <199802122256.OAA20793@dharkins-ss20.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 02:03 PM 2/13/98 -0600, Engineering wrote: >> >> > What about firewall configurations ? >> >Interoperabilty with NAT... That is too broad a statement for a workshop. What senarios and tests would you recommend? Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Mon Feb 16 08:31:44 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA20475 for ipsec-outgoing; Mon, 16 Feb 1998 08:31:43 -0500 (EST) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C011D5A26@wade.reo.dec.com> From: Stephen Waters To: ipsec@tis.com Subject: IPSEC tunnel over TCP Date: Mon, 16 Feb 1998 13:43:07 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Is the following supported for an IPSEC tunnel-mode exchange : [IP2][TCP][ESP][IP1][Upper] ? Regards, Steve. From owner-ipsec Mon Feb 16 08:48:49 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA20572 for ipsec-outgoing; Mon, 16 Feb 1998 08:48:48 -0500 (EST) Message-Id: <199802161401.JAA21941@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;;@tis.com;@tis.com;;;;;;;;; Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-auth-hmac-sha196-02.txt Date: Mon, 16 Feb 1998 09:01:21 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Use of HMAC-SHA-1-96 within ESP and AH Author(s) : C. Madson, R. Glenn Filename : draft-ietf-ipsec-auth-hmac-sha196-02.txt Pages : 5 Date : 13-Feb-98 This draft describes the use of the HMAC algorithm [RFC-2104] in conjunction with the SHA-1 algorithm [FIPS-180-1] as an authentication mechanism within the revised IPSEC Encapsulating Security Payload [ESP] and the revised IPSEC Authentication Header [AH]. HMAC with SHA-1 provides data origin authentication and integrity protection. Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a]. 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-auth-hmac-sha196-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-sha196-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-auth-hmac-sha196-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: <19980213151552.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-auth-hmac-sha196-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-auth-hmac-sha196-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980213151552.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Feb 16 08:48:49 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA20573 for ipsec-outgoing; Mon, 16 Feb 1998 08:48:48 -0500 (EST) Message-Id: <199802161401.JAA21927@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;;@tis.com;@tis.com;;;;;;;;; Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-auth-hmac-md5-96-02.txt Date: Mon, 16 Feb 1998 09:01:13 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Use of HMAC-MD5-96 within ESP and AH Author(s) : C. Madson, R. Glenn Filename : draft-ietf-ipsec-auth-hmac-md5-96-02.txt Pages : 6 Date : 13-Feb-98 This draft describes the use of the HMAC algorithm [RFC-2104] in conjunction with the MD5 algorithm [RFC-1321] as an authentication mechanism within the revised IPSEC Encapsulating Security Payload [ESP] and the revised IPSEC Authentication Header [AH]. HMAC with MD5 provides data origin authentication and integrity protection. Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a]. 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-auth-hmac-md5-96-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-md5-96-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-auth-hmac-md5-96-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: <19980213151513.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-auth-hmac-md5-96-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-auth-hmac-md5-96-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980213151513.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Feb 16 08:51:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA20621 for ipsec-outgoing; Mon, 16 Feb 1998 08:51:47 -0500 (EST) Message-Id: <199802161404.JAA22160@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;;@tis.com;@tis.com;;;;;;;;; Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-esp-v2-03.txt Date: Mon, 16 Feb 1998 09:04:46 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IP Encapsulating Security Payload (ESP) Author(s) : S. Kent, R. Atkinson Filename : draft-ietf-ipsec-esp-v2-03.txt Pages : 21 Date : 13-Feb-98 The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-esp-v2-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v2-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-esp-v2-03.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: <19980213162537.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-v2-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-v2-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980213162537.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Feb 16 08:53:49 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA20679 for ipsec-outgoing; Mon, 16 Feb 1998 08:53:48 -0500 (EST) Message-Id: <199802161406.JAA22228@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;;@tis.com;@tis.com;;;;;;;;; Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-oakley-06.txt Date: Mon, 16 Feb 1998 09:06:51 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Internet Key Exchange (IKE) Author(s) : D. Carrel, D. Harkins Filename : draft-ietf-ipsec-isakmp-oakley-06.txt Pages : 39 Date : 13-Feb-98 [MSST97] (ISAKMP) provides a framework for authentication and key exchange but does not define them. ISAKMP is designed to be key exchange independant; that is, it is designed to support many different key exchanges. [Orm96] (Oakley) describes a series of key exchanges-- called ''modes''-- and details the services provided by each (e.g. perfect forward secrecy for keys, identity protection, and authentication). [Kra96] (SKEME) describes a versatile key exchange technique which provides anonymity, repudiability, and quick key refreshment. This document describes a protocol using part of Oakley and part of SKEME in conjunction with ISAKMP to obtain authenticated keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-isakmp-oakley-06.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-oakley-06.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-isakmp-oakley-06.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: <19980213183154.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-oakley-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-oakley-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980213183154.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Feb 16 08:53:51 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA20687 for ipsec-outgoing; Mon, 16 Feb 1998 08:53:50 -0500 (EST) Message-Id: <199802161407.JAA22297@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;;@tis.com;@tis.com;;;;;;;;; Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ciph-des-expiv-02.txt Date: Mon, 16 Feb 1998 09:07:16 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The ESP DES-CBC Cipher Algorithm With Explicit IV Author(s) : N. Doraswamy, C. Madson Filename : draft-ietf-ipsec-ciph-des-expiv-02.txt Pages : 8 Date : 13-Feb-98 This document describes the use of the DES Cipher algorithm in Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPSec Encapsulating Security Payload (ESP). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ciph-des-expiv-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-des-expiv-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-ciph-des-expiv-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: <19980213194700.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-des-expiv-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-des-expiv-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980213194700.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Feb 16 08:53:51 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA20688 for ipsec-outgoing; Mon, 16 Feb 1998 08:53:50 -0500 (EST) Message-Id: <199802161404.JAA22146@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-auth-header-04.txt Date: Mon, 16 Feb 1998 09:04:39 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IP Authentication Header Author(s) : S. Kent, R. Atkinson Filename : draft-ietf-ipsec-auth-header-04.txt Pages : 23 Date : 13-Feb-98 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, by the receiver, when a Security Association is established. (Although the default calls for the sender to increment the Sequence Number used for anti-replay, the service is effective only if the receiver checks the Sequence Number.) 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 sender. 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 ''Security Architecture for the Internet Protocol'' [KA97a], hereafter referred to as the Security Architecture document). 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 a confidentiality (encryption) service. The primary difference between the authentication provided by ESP and AH is the extent of the coverage. Specifically, ESP does not protect any IP header fields unless those fields are encapsulated by ESP (tunnel mode). For more details on how to use AH and ESP in various network environments, see the Security Architecture document [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-auth-header-04.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-auth-header-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-auth-header-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19980213162516.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-auth-header-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-auth-header-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980213162516.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Feb 16 08:54:46 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA20708 for ipsec-outgoing; Mon, 16 Feb 1998 08:54:46 -0500 (EST) Message-Id: <199802161407.JAA22267@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ipsec-doi-07.txt Date: Mon, 16 Feb 1998 09:07:07 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Internet IP Security Domain of Interpretation for ISAKMP Author(s) : D. Piper Filename : draft-ietf-ipsec-ipsec-doi-07.txt Pages : 29 Date : 13-Feb-98 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, payloads, and processing guidelines that occur within a given Domain of Interpretation (DOI). This document defines the Internet IP Security DOI (IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate security associations. For a description of how the IPSEC DOI fits into the overall IP Security Documentation framework, please see [ROADMAP]. For a list of changes since the previous version of the IPSEC DOI, please see Section 5. 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-07.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-ipsec-doi-07.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-07.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19980213191256.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ipsec-doi-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ipsec-doi-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980213191256.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Feb 16 17:05:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA23645 for ipsec-outgoing; Mon, 16 Feb 1998 16:56:58 -0500 (EST) Message-Id: <199802162156.QAA23645@portal.ex.tis.com> Date: Fri, 13 Feb 1998 08:41:31 -0500 (EST) To: ipsec@tis.com From: rob.glenn@nist.gov Subject: Summary of changes to HMAC-MD5-96 draft X-Mailer: Ishmail 1.3.2-970722-linux Sender: owner-ipsec@ex.tis.com Precedence: bulk draft-ietf-ipsec-auth-hmac-md5-96-02.txt has been submitted and should show up in the typical places in a couple of days. Here is a summary of the changes. In addition, a few typos were corrected and some references updated. 1. With regard to implicit packet padding... change: HMAC-MD5-96 operates on 64-byte blocks of data. Padding requirements are specified in [RFC-1321] and are part of the MD5 algorithm. Padding bits are only necessary in computing the HMAC-MD5 authenticator value and MUST NOT be included in the packet. to: HMAC-MD5-96 operates on 64-byte blocks of data. Padding requirements are specified in [RFC-1321] and are part of the MD5 algorithm. If MD5 is built according to [RFC-1321], there is no need to add any additional padding as far as HMAC-MD5-96 is concerned. With regard to "implicit packet padding" as defined in [AH], no implicit packet padding is required. 2. With regard to key lengths Change: Key lengths other than 128-bits SHALL NOT be supported. To: Key lengths other than 128-bits MUST NOT be supported (i.e. only 128-bit keys are to be used by HMAC-MD5-96). 3. In response to the document reading party's comments: >Section 3. Keying Material - The 4th paragraph references the ESP >doc (and not AH) as to how to obtain and process keying material. We >question why this paragraph exists at all. In addition, the ESP has NO such >description of how to do these things. and > [ESP] describes the general mechanism to obtain keying material for > the ESP transform. The derivation of the key from some amount of > keying material does not differ between the manual and automatic key > management mechanisms. > to [arch]... Change: [ESP] describes the general mechanism to obtain keying material for the ESP transform. The derivation of the key from some amount of keying material does not differ between the manual and automatic key management mechanisms. To: [ARCH] describes the general mechanism for obtaining keying material when multiple keys are required for a single SA (e.g. when an ESP SA requires a key for confidentiality and a key for authentication). Also, added a reference for [ARCH]. 4. In response to the document reading party's comment: >There is a requirment that "any known attacks" be discussed in the >Security Considerations section. The MD5-96-01 doc does not discuss this. The following as added to paragraph 1 of section 5. At the time of this writing there are no known cryptographic attacks against HMAC-MD5-96. Rob G. rob.glenn@nist.gov -- John Kelley johnk@tis.com Director, Systems Administration Trusted Information Systems, Inc. (A NASDAQ company: "TISX") http://www.tis.com From owner-ipsec Mon Feb 16 17:05:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA23664 for ipsec-outgoing; Mon, 16 Feb 1998 16:59:00 -0500 (EST) Message-Id: <199802162159.QAA23664@portal.ex.tis.com> From: Cheryl Madson Subject: Changes to the ciph-des-explicit-iv draft To: ipsec@tis.com Date: Fri, 13 Feb 1998 08:15:16 -0800 (PST) Cc: cmadson@cisco.com (Cheryl Madson) X-Mailer: ELM [version 2.4 PL25] Sender: owner-ipsec@ex.tis.com Precedence: bulk The following changes have been made to the "ciph-des-explicit-iv" draft. Special thanks go to Steve Bellovin and Carlisle Adams for fielding a flurry of last-minute questions. I will be submitting the draft to Cynthia today. Thx - C ================ 1. Bellovin has pointed out an attack based upon using low-Hamming distance IV values. Based on this, (a) In section 3, changed "The IV SHOULD be chosen at random." to "The IV MUST be a random value." (b) Added to the section 3 implementation note: To avoid ECB encryption of very similar plaintext blocks in different packets, implementations MUST NOT use a counter or other low-Hamming distance source for IVs. (c) Added to the Security Considerations section: The case for using random values for IVs has been refined with the following summary provided by Steve Bellovin. Refer to [Bell97] for further information. "The problem arises if you use a counter as an IV, or some other source with a low Hamming distance between successive IVs, for encryption in CBC mode. In CBC mode, the "effective plaintext" for an encryption is the XOR of the actual plaintext and the ciphertext of the preceeding block. Normally, that's a random value, which means that the effective plaintext is quite random. That's good, because many blocks of actual plaintext don't change very much from packet to packet, either. For the first block of plaintext, though, the IV takes the place of the previous block of ciphertext. If the IV doesn't differ much from the previous IV, and the actual plaintext block doesn't differ much from the previous packet's, then the effective plaintext won't differ much, either. This means that you have pairs of ciphertext blocks combined with plaintext blocks that differ in just a few bit positions. This can be a wedge for assorted cryptanalytic attacks." The discussion on IVs has been updated to require that an implementation not use a low-Hamming distance source for IVs. (d) Added a reference to his paper. 2. To clarify the points of key size/format, made the following changes: (a) In section 4, first paragraph, changed the text to: DES-CBC is a symmetric secret key algorithm. The key size is 64 bits. [It is commonly known as a 56-bit key as the key has 56 significant bits; the least significant bit in every byte is the parity bit.] (b) [ESP] doesn't describe the so-called slicing-and-dicing (which algorithm gets which chunk of the base key); the information is contained in [arch]. (c) To clarify the "56-vs-64 bits from key engine": This mechanism MUST derive a 64-bit key value for use by this cipher. The mechanism will derive raw key values, the derivation process itself is not responsible for handling parity or weak key checks. (d) w.r.t. parity -- as there is no technical reason for a MUST (the parity bits are ignored during key transformation and so are really a local implementation issue instead of an interoperability issue), removed the "MUST set parity" and added the following: Implementation note: If an implementation chooses to do weak key checking, it should recognize that the known weak keys [FIPS74] have been adjusted for parity. Otherwise the handling of parity is a local issue. (e) Added a statement requiring a strong PRF for key generation, aligning this draft with the other algorithm drafts. 3. Weak keys: the bulk of the feedback here said to simply refer to the FIPS draft. Removed the list of weak keys (although the FIPS draft does not identity "possibly weak" keys). 4. Key Lifetime. New text: [Blaze96] discusses the costs and key recovery time for brute force attacks. It presents various combinations of total cost/time to recover a key/cost per key recovered for 40-bit and 56-bit DES keys, based on late 1995 estimates. While a brute force search of a 56-bit DES keyspace can be considered infeasable for the so-called casual hacker, who is simply using spare CPU cycles or other low-cost resources, it is within reach of someone willing to spend a bit more money. For example, for a cost of $300,000, a 56-bit DES key can be recovered in an average of 19 days using off-the-shelf technology and in only 3 hours using a custom developed chip. It should be noted that there are other attacks which can recover the key faster, that brute force attacks are considered the "worst case", although the easiest to implement. [Wiener94] also discusses a $1M machine which can break a DES key in 3.5 hours (1993 estimates), using a known-plaintext attack. As discussed in the Security Considerations section, a known plaintext attack is reasonably likely. It should also be noted that over time, the total and average search costs as well as the average key recovery time will continue to drop. While the above does not provide specific recommendations for key lifetime, it does reinforce the point that for a given application the desired key lifetime is dependent upon the perceived threat (an educated guess as to the amount of resources available to the attacker) relative to the worth of the data to be protected. While there are no recommendations for volume-based lifetimes made here, it shoud be noted that given sufficient volume there is an increased probabilty that known plaintext can be accumulated. 5. Fixed references: (a) Fixed the inconsistent spelling of Mike Wiener's name. (b) FIPS-46-2 has superceded both FIPS-46 and FIPS-46-1. (c) Added URL references to HTTP versions of the relevant FIPS documents. [No more watching the printer barf on a WP5 document!] (d) Added: [Bell97] Bellovin, S., "Probable Plaintext Cryptanalysis of the IP Security Protocols", Proceedings of the Symposium on Network and Distributed System Security, San Diego, CA, pp. 155-160, February 1997 (also http://www.research.att.com/~smb/probtxt.{ps, pdf}). [Blaze96] Blaze, M., Diffie, W., Rivest, R., Schneier, B., Shimomura, T., Thompson, E., Wiener, M., "Minimal Key Lengths for Symmetric Ciphers to Provide Adequate Commercial Security", currently available at http://www.bsa.org/policy/encryption/cryptographers.html. (e) Additional locations to find [Wiener94]: [Reprinted in "Practical Cryptography for Data Internetworks", W.Stallings, editor, IEEE Computer Society Press, pp.31-79 (1996). Currently available at ftp://ripem.msu.edu/pub/crypt/docs/des-key-search.ps.] 6. Changed the contact info for Bob ;-). -- John Kelley johnk@tis.com Director, Systems Administration Trusted Information Systems, Inc. (A NASDAQ company: "TISX") http://www.tis.com From owner-ipsec Mon Feb 16 17:05:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA23682 for ipsec-outgoing; Mon, 16 Feb 1998 17:00:59 -0500 (EST) Message-Id: <199802162200.RAA23682@portal.ex.tis.com> Date: Fri, 13 Feb 98 15:38:06 EST From: Karen Seo To: ipsec@tis.com Subject: Internet Draft -- IPsec AH spec Sender: owner-ipsec@ex.tis.com Precedence: bulk Network Working Group Stephen Kent, BBN Corp Internet Draft Randall Atkinson, @Home Network draft-ietf-ipsec-auth-header-04.txt February 1998 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 IPsec Working Group. 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. Copyright (C) The Internet Society (February 1998). All Rights Reserved. Kent, Atkinson [Page 1] Internet Draft IP Authentication Header February 1998 Table of Contents 1. Introduction......................................................3 2. Authentication Header Format......................................4 2.1 Next Header...................................................4 2.2 Payload Length................................................4 2.3 Reserved......................................................5 2.4 Security Parameters Index (SPI)...............................5 2.5 Sequence Number...............................................5 2.6 Authentication Data ..........................................6 3. Authentication Header Processing..................................6 3.1 Authentication Header Location...............................6 3.2 Authentication Algorithms....................................8 3.3 Outbound Packet Processing...................................8 3.3.1 Security Association Lookup.............................9 3.3.2 Sequence Number Generation..............................9 3.3.3 Integrity Check Value Calculation.......................9 3.3.3.1 Handling Mutable Fields...........................10 3.3.3.1.1 ICV Computation for IPv4.....................10 3.3.3.1.1.1 Base Header Fields.......................10 3.3.3.1.1.2 Options..................................11 3.3.3.1.2 ICV Computation for IPv6.....................11 3.3.3.1.2.1 Base Header Fields.......................11 3.3.3.1.2.2 Extension Headers -- Options.............12 3.3.3.1.2.3 Extension Headers -- non-Options.........12 3.3.3.2 Padding...........................................12 3.3.3.2.1 Authentication Data Padding..................12 3.3.3.2.2 Implicit Packet Padding......................13 3.3.4 Fragmentation..........................................13 3.4 Inbound Packet Processing...................................13 3.4.1 Reassembly.............................................13 3.4.2 Security Association Lookup............................14 3.4.3 Sequence Number Verification...........................14 3.4.4 Integrity Check Value Verification.....................15 4. Auditing.........................................................16 5. Conformance Requirements.........................................16 6. Security Considerations..........................................17 7. Differences from RFC 1826........................................17 Acknowledgements....................................................17 Appendix A -- Mutability of IP Options/Extension Headers............19 A1. IPv4 Options.................................................19 A2. IPv6 Extension Headers.......................................20 References..........................................................22 Disclaimer..........................................................22 Author Information..................................................22 Kent, Atkinson [Page 2] Internet Draft IP Authentication Header February 1998 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, by the receiver, when a Security Association is established. (Although the default calls for the sender to increment the Sequence Number used for anti-replay, the service is effective only if the receiver checks the Sequence Number.) 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 sender. 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 "Security Architecture for the Internet Protocol" [KA97a], hereafter referred to as the Security Architecture document). 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 a confidentiality (encryption) service. The primary difference between the authentication provided by ESP and AH is the extent of the coverage. Specifically, ESP does not protect any IP header fields unless those fields are encapsulated by ESP (tunnel mode). For more details on how to use AH and ESP in various network environments, see the Security Architecture document [KA97a]. It is assumed that the reader is familiar with the terms and concepts described in the Security Architecture document. In particular, the reader should be familiar with the definitions of security services offered by AH and ESP, the concept of Security Associations, the ways in which AH can be used in conjunction with ESP, and the different key management options available for AH and ESP. (With regard to the last topic, the current key management options required for both AH and ESP are manual keying and automated keying via ISAKMP/Oakley.) The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [Bra97]. Kent, Atkinson [Page 3] Internet Draft IP Authentication Header February 1998 2. Authentication Header Format The protocol header (IPv4, IPv6, or Extension) immediately preceding the AH header will contain the value 51 in its Protocol (IPv4) or Next Header (IPv6, Extension) field [STD-2]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Payload Len | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Authentication Data (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following subsections define the fields that comprise the AH format. All the fields described here are mandatory, i.e., they are always present in the AH format and are included in the Integrity Check Value (ICV) computation (see Sections 2.6 and 3.3.3). 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). 2.2 Payload Length This 8-bit field specifies the length of AH in 32-bit words (4-byte units), minus "2". (All IPv6 extension headers, as per RFC 1883, encode the "Hdr Ext Len" field by first subtracting 1 (64-bit word) from the header length (measured in 64-bit words). AH is an IPv6 extension header. However, since its length is measured in 32-bit words, the "Payload Length" is calculated by subtracting 2 (32 bit words).) In the "standard" case of a 96-bit authentication value plus the 3 32-bit word fixed portion, this length field will be "4". A "null" authentication algorithm may be used only for debugging purposes. Its use would result in a "1" value for this field for IPv4 or a "2" for IPv6, as there would be no corresponding Authentication Data field (see Section 3.3.3.2.1 on "Authentication Kent, Atkinson [Page 4] Internet Draft IP Authentication Header February 1998 Data Padding"). 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.) 2.4 Security Parameters Index (SPI) The SPI is an arbitrary 32-bit value that, in combination with the destination IP address and security protocol (AH), uniquely identifies the Security Association for this datagram. 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. It is ordinarily selected by the destination system upon establishment of an SA (see the Security Architecture document for more details). The SPI value of zero (0) is reserved for local, implementation- specific use and MUST NOT be sent on the wire. For example, a key management implementation MAY use the zero SPI value to mean "No Security Association Exists" during the period when the IPsec implementation has requested that its key management entity establish a new SA, but the SA has not yet been established. 2.5 Sequence Number This unsigned 32-bit field contains a monotonically increasing counter value (sequence number). It is mandatory and is always present even if the receiver does not elect to enable the anti-replay service for a specific SA. Processing of the Sequence Number field is at the discretion of the receiver, i.e., the sender MUST always transmit this field, but the receiver need not act upon it (see the discussion of Sequence Number Verification in the "Inbound Packet Processing" section below). The sender's counter and the receiver's counter are initialized to 0 when an SA is established. (The first packet sent using a given SA will have a Sequence Number of 1; see Section 3.3.2 for more details on how the Sequence Number is generated.) If anti-replay is enabled (the default), the transmitted Sequence Number must never be allowed to cycle. Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA. Kent, Atkinson [Page 5] Internet Draft IP Authentication Header February 1998 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.3.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 below. The authentication algorithm specification MUST specify the length of the ICV and the comparison rules and processing steps for validation. 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, note that for "bump-in- the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document, inbound and outbound IP fragments may require an IPsec implementation to perform extra IP reassembly/fragmentation in order to both conform to this specification and provide transparent IPsec support. Special care is required to perform such operations within these implementations when multiple interfaces are in use.) In transport mode, AH is inserted after the IP header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other IPsec headers that have already been inserted. 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. Kent, Atkinson [Page 6] Internet Draft IP Authentication Header February 1998 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. BEFORE APPLYING AH --------------------------------------- IPv6 | | ext hdrs | | | | orig IP hdr |if present| TCP | Data | --------------------------------------- AFTER APPLYING AH ------------------------------------------------------------ IPv6 | |hop-by-hop, dest*, | | dest | | | |orig IP hdr |routing, fragment. | AH | opt* | TCP | Data | ------------------------------------------------------------ |<---- authenticated except for mutable fields ----------->| * = if present, could be before AH, after AH, or both ESP and AH headers can be combined in a variety of modes. The IPsec Architecture document describes the combinations of security associations that must be supported. Tunnel mode AH may be employed in either hosts or security gateways (or in so-called "bump-in-the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document). When AH is implemented in a security gateway (to protect 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 Kent, Atkinson [Page 7] Internet Draft IP Authentication Header February 1998 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 -->| | in the new IP hdr | -------------------------------------------------------------- IPv6 | | ext hdrs*| | | ext hdrs*| | | |new IP hdr*|if present| AH |orig IP hdr*|if present|TCP|Data| -------------------------------------------------------------- |<-- authenticated except for mutable fields in new IP hdr ->| * = construction of outer IP hdr/extensions and modification of inner IP hdr/extensions is discussed below. 3.2 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 appropriate, though performance and space considerations currently preclude use of such algorithms. The mandatory-to-implement authentication algorithms are described in Section 5 "Conformance Requirements". Other algorithms MAY be supported. 3.3 Outbound Packet Processing In transport mode, the sender 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 Security Architecture document. If there is more than one IPsec header/extension required, the order of the application of the security headers MUST be defined by security policy. For simplicity of processing, each IPsec header Kent, Atkinson [Page 8] Internet Draft IP Authentication Header February 1998 SHOULD ignore the existence (i.e., not zero the contents or try to predict the contents) of IPsec headers to be applied later. (While a native IP or bump-in-the-stack implementation could predict the contents of later IPsec headers that it applies itself, it won't be possible for it to predict any IPsec headers added by a bump-in-the- wire implementation between the host and the network.) 3.3.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 Security Architecture document. 3.3.2 Sequence Number Generation The sender's counter is initialized to 0 when an SA is established. The sender increments the Sequence Number for this SA and inserts the new value into the Sequence Number Field. Thus the first packet sent using a given SA will have a Sequence Number of 1. If anti-replay is enabled (the default), the sender checks to ensure that the counter has not cycled before inserting the new value in the Sequence Number field. In other words, the sender MUST not send a packet on an SA if doing so would cause the Sequence Number to cycle. An attempt to transmit a packet that would result in Sequence Number overflow is an auditable event. (Note that this approach to Sequence Number management does not require use of modular arithmetic.) If anti-replay has been disabled, the sender does not need to monitor or reset the counter, e.g., in the case of manual key management. 3.3.3 Integrity Check Value Calculation The AH ICV is computed over: o IP header fields that are either immutable in transit or that are predictable in value upon arrival at the endpoint for the AH SA o the AH header (Next Header, Payload Len, Reserved, SPI, Sequence Number, and the Authentication Data (which is set to zero for this computation)) o the upper level protocol data, which is assumed to be immutable in transit Kent, Atkinson [Page 9] Internet Draft IP Authentication Header February 1998 3.3.3.1 Handling Mutable Fields If a field may be 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 is also 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. Also, the zero-fill approach ensures that the length of the fields that are so handled cannot be changed during transit, even though their contents are not explicitly covered by the ICV. As a new extension header or IPv4 option is created, it will be defined in its own RFC and SHOULD include (in the Security Considerations section) directions for how it should be handled when calculating the AH ICV. If the IPsec implementation encounters an extension header that it does not recognize, it MUST zero the whole header except for the Next Header and Hdr Ext Len fields. The length of the extension header MUST be computed by 8 * Hdr Ext Len value + 8. If the IPsec implementation encounters an IPv4 option that it does not recognize, it should zero the whole option, using the second byte of the option as the length. (IPv6 options contain a flag indicating mutability, which determines appropriate processing for such options.) 3.3.3.1.1 ICV Computation for IPv4 3.3.3.1.1.1 Base Header Fields The IPv4 base header fields are classified as follows: Immutable Version Internet Header Length Total Length Identification Protocol (This should be the value for AH.) Source Address Destination Address (without loose or strict source routing) Mutable but predictable Destination Address (with loose or strict source routing) Kent, Atkinson [Page 10] Internet Draft IP Authentication Header February 1998 Mutable (zeroed prior to ICV calculation) Type of Service (TOS) Flags Fragment Offset Time to Live (TTL) Header Checksum TOS -- This field is excluded 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. Flags -- This field is excluded since an intermediate router might set the DF bit, even if the source did not select it. Fragment Offset -- Since AH is applied only to non-fragmented IP packets, the Offset Field must always be zero, and thus it is excluded (even though it is predictable). TTL -- This is changed en-route as a normal course of processing by routers, and thus its value at the receiver is not predictable by the sender. Header Checksum -- This will change if any of these other fields changes, and thus its value upon reception cannot be predicted by the sender. 3.3.3.1.1.2 Options For IPv4 (unlike IPv6), there is no mechanism for tagging options as mutable in transit. Hence the IPv4 options are explicitly listed in Appendix A and classified as immutable, mutable but predictable, or mutable. For IPv4, the entire option is viewed as a unit; so even though the 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. 3.3.3.1.2 ICV Computation for IPv6 3.3.3.1.2.1 Base Header Fields The IPv6 base header fields are classified as follows: Immutable Version Payload Length Next Header (This should be the value for AH.) Source Address Destination Address (without Routing Extension Header) Kent, Atkinson [Page 11] Internet Draft IP Authentication Header February 1998 Mutable but predictable Destination Address (with Routing Extension Header) Mutable (zeroed prior to ICV calculation) Class Flow Label Hop Limit 3.3.3.1.2.2 Extension Headers -- Options The IPv6 extension headers (that are options) are explicitly listed in Appendix A and classified as immutable, mutable but predictable, or mutable. IPv6 options in the Hop-by-Hop and Destination Extension Headers contain a bit that indicates whether the option might change (unpredictably) 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 options for which the bit indicates immutability are included in the ICV calculation. See the IPv6 specification [DH95] for more information. 3.3.3.1.2.3 Extension Headers -- non-Options The IPv6 extension headers (that are not options) are explicitly listed in Appendix A and classified as immutable, mutable but predictable, or mutable. 3.3.3.2 Padding 3.3.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 two factors: - the length of the ICV - the IP protocol version (v4 or v6) For example, if the output of the selected algorithm is 96-bits, no padding is required for either IPv4 or for IPv6. However, if a different length ICV is generated, due to use of a different algorithm, then padding may be required depending on the length and IP protocol version. The content of the padding field is arbitrarily Kent, Atkinson [Page 12] Internet Draft IP Authentication Header February 1998 selected by the sender. (The padding is arbitrary, but need not be random to achieve security.) These padding 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.3.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. Note that MD5 and SHA-1 are viewed as having a 1-byte blocksize because of their internal padding conventions. 3.3.4 Fragmentation If required, IP fragmentation occurs after AH processing within an IPsec implementation. Thus, transport mode AH is applied only to whole IP datagrams (not to IP fragments). An IP packet to which AH has been applied may itself be fragmented by routers en route, and such fragments must be reassembled prior to AH processing at a receiver. In tunnel mode, AH is applied to an IP packet, the payload of which may be a fragmented IP packet. For example, a security gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation (see the Security Architecture document for details) may apply tunnel mode AH to such fragments. 3.4 Inbound Packet Processing If there is more than one IPsec header/extension present, the processing for each one ignores (does not zero, does not use) any IPsec headers applied subsequent to the header being processed. 3.4.1 Reassembly If required, reassembly is performed prior to AH processing. If a packet offered to AH for processing appears to be an IP fragment, i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID. Kent, Atkinson [Page 13] Internet Draft IP Authentication Header February 1998 NOTE: For packet reassembly, the current IPv4 spec does NOT require either the zero'ing of the OFFSET field or the clearing of the MORE FRAGMENTS flag. In order for a reassembled packet to be processed by IPsec (as opposed to discarded as an apparent fragment), the IP code must do these two things after it reassembles a packet. 3.4.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, security protocol (AH), and the SPI. (This process is described in more detail in the Security Architecture document.) The SA indicates whether the Sequence Number field will be checked, specifies the algorithm(s) employed for ICV computation, and indicates 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; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID. 3.4.3 Sequence Number Verification All AH implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. (Note that there are no provisions for managing transmitted Sequence Number values among multiple senders directing traffic to a single SA (irrespective of whether the destination address is unicast, broadcast, or multicast). Thus the anti-replay service SHOULD NOT be used in a multi-sender environment that employs a single SA.) If the receiver does not enable anti-replay for an SA, no inbound checks are performed on the Sequence Number. The default for the sender is that the Sequence Number will be checked at the sender. Hence, if an SA establishment protocol such as ISAKMP/Oakley is employed, the receiver SHOULD notify the sender, during SA establishment, if the receiver will not provide anti-replay protection. If the receiver has enabled the anti-replay service for this SA, the receiver packet counter for the SA MUST be initialized to zero when the SA is established. For each received packet, 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 14] Internet Draft IP Authentication Header February 1998 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.) A MINIMUM window size of 32 MUST be supported; but a window size of 64 is preferred and SHOULD be employed as the default. Another window size (larger than the MINIMUM) MAY be chosen by the receiver. (The receiver does NOT notify the sender of the window size.) The "right" edge of the window represents the highest, validated Sequence Number 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 the Security Architecture document. If the received packet falls within the window and is new, or if the packet is to the right of the window, then the receiver proceeds to ICV verification. If the ICV validation fails, the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, the Sequence Number, and (in IPv6) the Flow ID. The receive window is updated only if the ICV verification succeeds. DISCUSSION: Note that if the packet is either inside the window and new, or is outside the window on the "right" side, the receiver MUST authenticate the packet before updating the Sequence Number window data. 3.4.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; this is an auditable event. The audit log entry SHOULD include the SPI value, date/time received, Source Address, Destination Address, and (in IPv6) the Flow ID. DISCUSSION: Kent, Atkinson [Page 15] Internet Draft IP Authentication Header February 1998 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.3.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. Perform the ICV computation and compare the result with the saved value, using the comparison rules defined by the algorithm specification. (For example, if a digital signature and one-way hash are used for the ICV computation, the matching process is more complex.) 4. Auditing Not all systems that implement AH will implement auditing. However, if AH is incorporated into a system that supports auditing, then the AH implementation MUST also support auditing and MUST allow a system administrator to enable or disable auditing for AH. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in this specification and for each of these events a minimum set of information that SHOULD be included in an audit log is defined. Additional information also MAY be included in the audit log for each of these events, and additional events, not explicitly called out in this specification, also MAY result in audit log entries. There is no requirement for the receiver to transmit any message to the purported sender in response to the detection of an auditable event, because of the potential to induce denial of service via such action. 5. 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 document. If the key used to compute an ICV is manually distributed, correct provision of the anti-replay service would require correct maintenance of the counter state at the sender, until the key is replaced, and there likely would be no automated recovery provision if counter overflow were imminent. Thus a compliant implementation SHOULD NOT provide this service in conjunction with SAs that are manually keyed. A compliant AH implementation MUST support the following mandatory-to-implement algorithms: Kent, Atkinson [Page 16] Internet Draft IP Authentication Header February 1998 - HMAC with MD5 [MG97a] - HMAC with SHA-1 [MG97b] 6. Security Considerations Security is central to the design of this protocol, and these security considerations permeate the specification. Additional security-relevant aspects of using the IPsec protocol are discussed in the Security Architecture document. 7. Differences from RFC 1826 This specification of AH differs from RFC 1826 [ATK95] in several important respects, but the fundamental features of AH remain intact. One goal of the revision of RFC 1826 was to provide a complete framework for AH, with ancillary RFCs required only for algorithm specification. For example, the anti-replay service is now an integral, mandatory part of AH, not a feature of a transform defined in another RFC. Carriage of a sequence number to support this service is now required at all times. The default algorithms required for interoperability have been changed to HMAC with MD5 or SHA-1 (vs. keyed MD5), for security reasons. The list of IPv4 header fields excluded from the ICV computation has been expanded to include the OFFSET and FLAGS fields. Another motivation for revision was to provide additional detail and clarification of subtle points. This specification provides rationale for exclusion of selected IPv4 header fields from AH coverage and provides examples on positioning of AH in both the IPv4 and v6 contexts. Auditing requirements have been clarified in this version of the specification. Tunnel mode AH was mentioned only in passing in RFC 1826, but now is a mandatory feature of AH. Discussion of interactions with key management and with security labels have been moved to the Security Architecture document. 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 Karen Seo for providing extensive help in the review, editing, background research, and coordination for this version of the specification. The authors would also like to thank the members of the IPsec and IPng working groups, with special mention of the efforts of (in alphabetic order): Kent, Atkinson [Page 17] Internet Draft IP Authentication Header February 1998 Steve Bellovin, Steve Deering, Francis Dupont, Phil Karn, Frank Kastenholz, Perry Metzger, David Mihelcic, Hilarie Orman, Norman Shulman, William Simpson, and Nina Yuan. Kent, Atkinson [Page 18] Internet Draft IP Authentication Header February 1998 Appendix A -- Mutability of IP Options/Extension Headers A1. IPv4 Options This table shows how the IPv4 options are classified with regard to "mutability". Where two references are provided, the second one supercedes the first. This table is based in part on information provided in RFC1700, "ASSIGNED NUMBERS", (October 1994). Opt. Copy Class # Name Reference ---- ----- --- ------------------------- --------- IMMUTABLE -- included in ICV calculation 0 0 0 End of Options List [RFC791] 0 0 1 No Operation [RFC791] 1 0 2 Security [RFC1108(historic but in use)] 1 0 5 Extended Security [RFC1108(historic but in use)] 1 0 6 Commercial Security [expired I-D, now US MIL STD] 1 0 20 Router Alert [RFC2113] 1 0 21 Sender Directed Multi- [RFC1770] Destination Delivery MUTABLE -- zeroed 1 0 3 Loose Source Route [RFC791] 0 2 4 Time Stamp [RFC791] 0 0 7 Record Route [RFC791] 1 0 9 Strict Source Route [RFC791] 0 2 18 Traceroute [RFC1393] EXPERIMENTAL, SUPERCEDED -- zeroed 1 0 8 Stream ID [RFC791, RFC1122 (Host Req)] 0 0 11 MTU Probe [RFC1063, RFC1191 (PMTU)] 0 0 12 MTU Reply [RFC1063, RFC1191 (PMTU)] 1 0 17 Extended Internet Protocol [RFC1385, RFC1883 (IPv6)] 0 0 10 Experimental Measurement [ZSu] 1 2 13 Experimental Flow Control [Finn] 1 0 14 Experimental Access Ctl [Estrin] 0 0 15 ??? [VerSteeg] 1 0 16 IMI Traffic Descriptor [Lee] 1 0 19 Address Extension [Ullmann IPv7] NOTE: Use of the Router Alert option is potentially incompatible with use of IPsec. Although the option is immutable, its use implies that each router along a packet's path will "process" the packet and consequently might change the packet. This would happen on a hop by hop basis as the packet goes from router to router. Prior to being processed by the application to which the option contents are directed, e.g., RSVP/IGMP, the packet should encounter AH processing. Kent, Atkinson [Page 19] Internet Draft IP Authentication Header February 1998 However, AH processing would require that each router along the path is a member of a multicast-SA defined by the SPI. This might pose problems for packets that are not strictly source routed, and it requires multicast support techniques not currently available. NOTE: Addition or removal of any security labels (BSO, ESO, CIPSO) by systems along a packet's path conflicts with the classification of these IP Options as immutable and is incompatible with the use of IPsec. NOTE: End of Options List options SHOULD be repeated as necessary to ensure that the IP header ends on a 4 byte boundary in order to ensure that there are no unspecified bytes which could be used for a covert channel. A2. IPv6 Extension Headers This table shows how the IPv6 Extension Headers are classified with regard to "mutability". Option/Extension Name Reference ----------------------------------- --------- MUTABLE BUT PREDICTABLE -- included in ICV calculation Routing (Type 0) [RFC1883] BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING TRANSIT) Hop by Hop options [RFC1883] Destination options [RFC1883] NOT APPLICABLE Fragmentation [RFC1883] Options -- IPv6 options in the Hop-by-Hop and Destination Extension Headers contain a bit that indicates whether the option might change (unpredictably) 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 options for which the bit indicates immutability are included in the ICV calculation. See the IPv6 specification [DH95] for more information. Routing (Type 0) -- 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 Kent, Atkinson [Page 20] Internet Draft IP Authentication Header February 1998 included in the Authentication Data calculation as mutable but predictable. The sender must order the field so that it appears as it will at the receiver, prior to performing the ICV computation. Fragmentation -- Fragmentation occurs after outbound IPsec processing (section 3.3) and reassembly occurs before inbound IPsec processing (section 3.4). So the Fragmentation Extension Header, if it exists, is not seen by IPsec. Note that on the receive side, the IP implementation could leave a Fragmentation Extension Header in place when it does re-assembly. If this happens, then when AH receives the packet, before doing ICV processing, AH MUST "remove" (or skip over) this header and change the previous header's "Next Header" field to be the "Next Header" field in the Fragmentation Extension Header. Note that on the send side, the IP implementation could give the IPsec code a packet with a Fragmentation Extension Header with Offset of 0 (first fragment) and a More Fragments Flag of 0 (last fragment). If this happens, then before doing ICV processing, AH MUST first "remove" (or skip over) this header and change the previous header's "Next Header" field to be the "Next Header" field in the Fragmentation Extension Header. Kent, Atkinson [Page 21] Internet Draft IP Authentication Header February 1998 References [ATK95] R. Atkinson, "The IP Authentication Header," RFC 1826, August 1995. [Bra97] S. Bradner, "Key words for use in RFCs to Indicate Requirement Level," RFC-2119, March 1997. [DH95] Steve Deering & Bob Hinden, "Internet Protocol version 6 (IPv6) Specification", RFC-1883, December 1995. [KA97a] Steve Kent, Randall Atkinson, "Security Architecture for the Internet Protocol", Internet Draft, February, 1998. [KA97b] Steve Kent, Randall Atkinson, "IP Encapsulating Security Payload (ESP)", Internet Draft, February 1998. [MG97a] C. Madson & R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", Internet Draft, November 1997. [MG97b] C. Madson & R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", Internet Draft, November 1997. [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 E-mail: kent@bbn.com Telephone: +1 (617) 873-3988 Kent, Atkinson [Page 22] Internet Draft IP Authentication Header February 1998 Randall Atkinson @Home Network 425 Broadway, Redwood City, CA 94063 USA E-mail: rja@inet.org Copyright (C) The Internet Society (February 1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Kent, Atkinson [Page 23] ----- End of forwarded messages -- John Kelley johnk@tis.com Director, Systems Administration Trusted Information Systems, Inc. (A NASDAQ company: "TISX") http://www.tis.com From owner-ipsec Mon Feb 16 17:05:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA23663 for ipsec-outgoing; Mon, 16 Feb 1998 16:58:59 -0500 (EST) Message-Id: <199802162158.QAA23663@portal.ex.tis.com> Date: Fri, 13 Feb 1998 14:03:12 -0600 (CST) From: Engineering To: Daniel Harkins cc: ipsec@tis.com Subject: Re: Help - Details on March 2nd worshop at Raliegh requested ... Sender: owner-ipsec@ex.tis.com Precedence: bulk > > > What about firewall configurations ? > Interoperabilty with NAT... Jeff -- John Kelley johnk@tis.com Director, Systems Administration Trusted Information Systems, Inc. (A NASDAQ company: "TISX") http://www.tis.com From owner-ipsec Mon Feb 16 17:05:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA23675 for ipsec-outgoing; Mon, 16 Feb 1998 16:59:59 -0500 (EST) Message-Id: <199802162159.QAA23675@portal.ex.tis.com> Date: Fri, 13 Feb 98 15:35:40 EST From: Karen Seo To: ipsec@tis.com cc: kseo@bbn.com Subject: IPsec AH and ESP drafts Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, Here's a summary of IPsec AH and ESP edits/questions. This is based on the drafts distributed in 11/97 and subsequent email (up until 1/31). It does not include minor edits (typos), the addition of the new copyright text required by the RFC format instructions, updating of the reference section, etc. The issues have been divided into 3 groups: AH-ONLY ESP-ONLY AH AND ESP We have submitted the AH and ESP drafts to the IETF secretariat for distribution. Per direction from the working group chairs, we are also sending copies directly to the list to get them into folks' hands as soon as possible. Thank you for all the feedback/help both on the list and in private email. Karen AH-ONLY ============================================================================ === 1. Per email from Dave Mason (12/29-30) -- For IPv4, need to discuss how to handle the bytes of IP header after the last option. RFC 791 (IP) and RFC 1122 (Host Requirements) specify only that an "End of Options List" option is placed after the last option. "This might not coincide with the end of the internet header according to the internet header length.... and need only be used if the end of the options would not otherwise coincide with the end of the internet header." They do not say to insert "End of Options List" options until the IP header is 4-byte aligned or up to the end of the IP header. *Changed AH Appendix A.1 IPv4 Options -- added the following note at the end of the table. End of Options List options SHOULD be repeated as necessary to ensure that the IP header ends on a 4 byte boundary in order to ensure that there are no unspecified bytes which could be used for a covert channel. ESP-ONLY ============================================================================ === 1. Section 3.1 -- Per summary from IPsec document reading party, "3.1 Say that tunnel mode *MUST* be used." * Sorry, but could someone provide more context? There are several places where this statement might apply. 2. Section 3.3.3 Sequence Number Generation -- Add pointer to Section 5 to provide explanation for comment on manual key management. * Changed last paragraph of this section from: If anti-replay has been disabled, the sender does not need to monitor or reset the counter, e.g., in the case of manual key management. to: If anti-replay has been disabled, the sender does not need to monitor or reset the counter, e.g., in the case of manual key management (see Section 5). 3. Section 3.3.5 -- Per summary from IPsec document reading party, "3.3.5 I'm not convinced that the description of how to do fragmentation is correct. I'm especially concerned that transport and tunnel modes require different processing. The interaction of the rules here with IPv6 fragmentation is especially worthy of attention. (See the discussion of fragmentation in Wagner and Bellovin's "A Bump in the Stack Encryptor for MS-DOS"....) * Modified the existing Section "3.3.5 Fragmentation": If necessary, fragmentation is performed after ESP processing within an IPsec implementation. Thus, transport mode ESP is applied only to whole IP datagrams (not to IP fragments). An IP packet to which ESP has been applied may itself be fragmented by routers en route, and such fragments must be reassembled prior to ESP processing at a receiver. In tunnel mode, ESP is applied to an IP packet, the payload of which may be a fragmented IP packet. For example, a security gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation (as defined in the Security Architecture document) may apply tunnel mode ESP to such fragments. by adding the following two notes: NOTE: For transport mode -- As mentioned at the beginning of Section 3.1, bump-in-the-stack and bump-in-the-wire implementations may have to first reassemble a packet fragmented by the local IP layer, then apply IPsec, and then fragment the resulting packet. NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire implementations, it will be necessary to walk through all the extension headers to determine if there is a fragmentation header and hence that the packet needs reassembling prior to IPsec processing. 4. Section 3.4.5 -- Per summary from IPsec document reading party, need to correct the text to indicate additional ways in which decryption can "fail". * Changed Section 3.4.5 Packet Decryption, paragraph 4 (counting the indented steps 1,2,3 taken by the receiver as one paragraph) from: Note that there are two ways in which the decryption can "fail". o The selected SA may not be correct. o 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. to: Note that there are several ways in which the decryption can "fail": a. The selected SA may not be correct -- The SA may be mis-selected due to tampering with the SPI, destination address. or IPsec protocol type fields. Such errors, if they map the packet to another extant SA, will be indistinguishable from a corrupted packet, (case c). Tampering with the SPI can be detected by use of authentication. However, an SA mismatch might still occur due to tampering with the IP Destination Address or the IPsec protocol type field. b. The pad length or pad values could be erroneous -- Bad pad lengths or pad values can be detected irrespective of the use of authentication. c. The encrypted ESP packet could be corrupted -- This can be detected if authentication is selected for the SA., In case (a) or (c), 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. AH AND ESP ============================================================================ === 1. Section 2 -- Define "IV" (ESP-only) and "ICV" (AH and ESP) before/when using these terms. * In AH -- Changed the text following the header format diagram from: The following subsections define the fields that comprise the AH format. All the fields described here are mandatory, i.e., they are always present in the AH format and are included in the ICV computation. to: The following subsections define the fields that comprise the AH format. All the fields described here are mandatory, i.e., they are always present in the AH format and are included in the Integrity Check Value (ICV) computation (see Sections 2.6 and 3.3.3). * In ESP -- Changed text following header format diagram from: * If included in the Payload field, cryptographic synchronization data, e.g., an IV, usually is not encrypted per se, although it often is referred to as being part of the ciphertext. 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.... to: * If included in the Payload field, cryptographic synchronization data, e.g., an Initialization Vector (IV, see Section 2.3), usually is not encrypted per se, although it often is referred to as being part of the ciphertext. 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 Integrity Check Value (ICV, see Section 2.7)...... 2. Section 3.1 -- Per summary from IPsec document reading party, need to reconcile AH (Section 3.1) and ESP (Section 3.1) descriptions of support for combinations of SAs with the Architecture's description of support for combinations of SAs. *The Architecture document has been changed to more clearly reflect the 4 cases that the community agreed needed to be supported and remove some errors and inconsistencies. The AH and ESP text has been changed to point to the Architecture document. We removed the following text from AH and ESP Sections 3.1: If more than one IPsec header/extension is required, then starting with packet [IP1][upper], the following 5 cases plus any combination of one of the Tunnel cases followed by one of the Transport cases (i.e., 4 then 1, 4 then 2, 4 then 3, 5 then 1, 5 then 2, 5 then 3.) MUST be supported. Transport Tunnel ----------------- --------------------- 1. [IP1][AH][upper] 4. [IP2][AH][IP1][upper] 2. [IP1][ESP][upper] 5. [IP2][ESP][IP1][upper] 3. [IP1][AH][ESP][upper] Support for additional combinations of AH and ESP is optional. Use of other, optional combinations may adversely affect interoperability. and replaced it with: ESP and AH headers can be combined in a variety of modes. The IPsec Architecture document describes the combinations of security associations that must be supported. 3. Section 3.3.4 (ESP) and 3.3.3.2.2 (AH) -- Per discussion re: "implicit padding for authentication" (1/7-25), need to clarify that the input "block size" for MD5 and SHA-1 is such that no padding is needed even though their internal algorithms have an internal "block size" of 64 bytes. * Changed AH and ESP documents to clarify the above. This involved changing AH Section "3.3.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. by adding the following sentence at the end: Note that MD5 and SHA-1 are viewed as having a 1-byte blocksize because of their internal padding conventions. and changing ESP Section "3.3.4 Integrity Check Value Calculation", paragraph 2: 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, (after the Next Header field) 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. by adding the following sentence at the end: Note that MD5 and SHA-1 are viewed as having a 1-byte blocksize because of their internal padding conventions. 4. Section 3.4.1 -- Per summary from IPsec document reading party, need to clarify that the appearance of a "fragment" for ESP processing can result not just from a bug in the code but because the current IPv4 spec does NOT require (upon reassembly) the zero'ing of the OFFSET field or the clearing of the MORE FRAGMENTS flag. *Modified the following text in AH and ESP: 3.4.1 Reassembly If required, reassembly is performed prior to AH processing. If a packet offered to AH for processing appears to be an IP fragment, i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID. 3.4.1 Reassembly If required, reassembly is performed prior to ESP processing. If a packet offered to ESP for processing appears to be an IP fragment, i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID. by the addition of the following text: NOTE: For packet reassembly, the current IPv4 spec does NOT require either the zero'ing of the OFFSET field or the clearing of the MORE FRAGMENTS flag. In order for a reassembled packet to be processed by IPsec (as opposed to discarded as an apparent fragment), the IP code must do these two things after it reassembles a packet. 5. Section 3.4.3 -- Per suggestion from Dan McDonald (1/7), need to modify the documents to clarify that anti-replay is not supportable in the case of multiple senders to a single SA, irrespective of whether the destination address is unicast, broadcast, or multicast. *Changed AH and ESP documents to clarify the above. This involved changing AH Section "3.4.3 Sequence Number Verification" from: All AH implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. (Note that there are no provisions for managing transmitted Sequence Number values among multiple senders directing traffic to a single, multicast SA. Thus the anti-replay service SHOULD NOT be used in a multi-sender multicast environment that employs a single, multicast SA.) to: All AH implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. (Note that there are no provisions for managing transmitted Sequence Number values among multiple senders directing traffic to a single SA (irrespective of whether the destination address is unicast, broadcast, or multicast). Thus the anti-replay service SHOULD NOT be used in a multi-sender environment that employs a single SA.) and changing ESP Section "3.4.3 Sequence Number Verification" from: All ESP implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. This service MUST NOT be enabled unless the authentication service also is enabled for the SA, since otherwise the Sequence Number field has not been integrity protected. (Note that there are no provisions for managing transmitted Sequence Number values among multiple senders directing traffic to a single, multicast SA. Thus the anti-replay service SHOULD NOT be used in a multi-sender multicast environment that employs a single, multicast SA.) to: All ESP implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. This service MUST NOT be enabled unless the authentication service also is enabled for the SA, since otherwise the Sequence Number field has not been integrity protected. (Note that there are no provisions for managing transmitted Sequence Number values among multiple senders directing traffic to a single SA (irrespective of whether the destination address is unicast, broadcast, or multicast). Thus the anti-replay service SHOULD NOT be used in a multi-sender environment that employs a single SA.) -- John Kelley johnk@tis.com Director, Systems Administration Trusted Information Systems, Inc. (A NASDAQ company: "TISX") http://www.tis.com From owner-ipsec Mon Feb 16 17:05:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA23713 for ipsec-outgoing; Mon, 16 Feb 1998 17:01:58 -0500 (EST) Message-Id: <199802162201.RAA23713@portal.ex.tis.com> Date: Fri, 13 Feb 1998 16:32:39 -0500 (EST) From: Ben Rogers Reply-To: ben@Ascend.COM (Ben Rogers) To: dharkins@cisco.com, ipsec@tis.com Subject: Deriviation of Phase 1 keying material Sender: owner-ipsec@ex.tis.com Precedence: bulk >From IO-RES Appendix B: Encryption keys used to protect the ISAKMP SA are derived from SKEYID_e in an algorithm-specific manner. When SKEYID_e is not long enough to supply all the necessary keying material an algorithm requires, the key is derived from feeding the results of a pseudo- random function into itself, concatenating the results, and taking the highest necessary bits. For example, if (ficticious) algorithm AKULA requires 320-bits of key (and has no weak key check) and the prf used to generate SKEYID_e only generates 120 bits of material, the key for AKULA, would be the first 320-bits of Ka, where: Ka = K1 | K2 | K3 and K1 = prf(SKEYID_e, 0) K2 = prf(SKEYID_e, K1) K3 = prf(SKEYID_e, K2) I'm not really clear as to what we do if SKEYID_e has enough bits to provide us with the encryption key we're looking for. Perhaps one of the following clarifications is appropriate? Encryption keys used to protect the ISAKMP SA are derived from SKEYID_e in an algorithm-specific manner. If SKEYID_e is long enough to supply the necessary keying material the algorithm requires, then it is used without modification. If it is not long enough, the key is derived from feeding the results of a pseudo-random function into itself, concatenating the results, and taking the highest necessary bits. For example,... or Encryption keys used to protect the ISAKMP SA are derived from SKEYID_e in an algorithm-specific manner. The key material is generated by taking the high order bits of the following string K: K = K1 | K2 | K3 | ... where K1 = prf(SKEYID_e, 0) KN+1 = prf(SKEYID_e, KN) and 0 is represented by a single octet. For example, if (ficticious) algorithm AKULA requires 320-bits of key (and has no weak key check) and the prf used to generate SKEYID_e only generates 120 bits of material, the key for AKULA, would be the first 320-bits of Ka, where: Ka = K1 | K2 | K3 and K1 = prf(SKEYID_e, 0) K2 = prf(SKEYID_e, K1) K3 = prf(SKEYID_e, K2) where prf is the negotiated prf or the HMAC version of the negotiated hash function. Each result of the prf provides 120 bits of material for a total of 360 bits. AKULA would use the first 320 bits of that 360 bit string. I'm also not certain to do in the case where the first 8 bytes of this keystring are weak. Do we instead take bytes 1-9, or bytes 9-16? Does anyone see the need to include the weak key check in 3DES-CBC? If so, do we not allow keys for which any of the DES keys is weak, or only keys where all three are weak? If the first is the case, shold we allow non-contiguous keys? (ie, if bytes 9-16 are a weak key, do I build my 3DES key from bytes 1-8, 17-24 and 25-32, or take the contiguous block of bytes 17-40 or 25-48?) ben --QAA06833.887405184/relay.hq.tis.com-- -- John Kelley johnk@tis.com Director, Systems Administration Trusted Information Systems, Inc. (A NASDAQ company: "TISX") http://www.tis.com From owner-ipsec Mon Feb 16 17:05:46 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA23651 for ipsec-outgoing; Mon, 16 Feb 1998 16:57:59 -0500 (EST) Message-Id: <199802162157.QAA23651@portal.ex.tis.com> Date: Fri, 13 Feb 1998 10:29:14 -0500 (EST) From: Ben Rogers To: "Theodore Y. Ts'o" Cc: Bart Preneel , Rich Ankney , FUKUMOTO Atsushi , ipsec@tis.com Subject: Re: Generic CBC-MAC specification Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Theodore Y. Ts'o writes: > So, the main question before us is not that of security, but of > interoperability, with apparently more than one documented way of a > CBC-MAC. Question: has anyone actually implemented 3DES-CBC-MAC as a > PRF to be used in ISAKMP/Oakley? If so, how did you do it? The FIPS-81 > way, or X9.19 way? I have implemented it, and done it the FIPS-81 way. However, I have no problem dropping it, partly because I'm not comfortable with it and partly because it requires a lot of extra code to support. I will be more than happy to demonstrate a very peculiar result of using it as your prf at the workshop. ben -- John Kelley johnk@tis.com Director, Systems Administration Trusted Information Systems, Inc. (A NASDAQ company: "TISX") http://www.tis.com From owner-ipsec Mon Feb 16 17:05:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA23676 for ipsec-outgoing; Mon, 16 Feb 1998 17:00:00 -0500 (EST) Message-Id: <199802162200.RAA23676@portal.ex.tis.com> Date: Fri, 13 Feb 98 15:38:49 EST From: Karen Seo To: ipsec@tis.com Subject: Internet Draft -- IPsec ESP spec Sender: owner-ipsec@ex.tis.com Precedence: bulk Network Working Group Stephen Kent, BBN Corp Internet Draft Randall Atkinson, @Home Network draft-ietf-ipsec-esp-v2-03.txt February 1998 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 IPsec working group. 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. Copyright (C) The Internet Society (February 1998). All Rights Reserved. Kent, Atkinson [Page 1] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) Table of Contents 1. Introduction......................................................3 2. Encapsulating Security Payload Packet Format......................4 2.1 Security Parameters Index....................................5 2.2 Sequence Number .............................................5 2.3 Payload Data.................................................5 2.4 Padding (for Encryption).....................................6 2.5 Pad Length...................................................7 2.6 Next Header..................................................7 2.7 Authentication Data..........................................8 3. Encapsulating Security Protocol Processing........................8 3.1 ESP Header Location..........................................8 3.2 Algorithms..................................................10 3.2.1 Encryption Algorithms..................................10 3.2.2 Authentication Algorithms..............................11 3.3 Outbound Packet Processing..................................11 3.3.1 Security Association Lookup............................11 3.3.2 Packet Encryption......................................11 3.3.3 Sequence Number Generation.............................12 3.3.4 Integrity Check Value Calculation......................12 3.3.5 Fragmentation..........................................13 3.4 Inbound Packet Processing...................................13 3.4.1 Reassembly.............................................13 3.4.2 Security Association Lookup............................14 3.4.3 Sequence Number Verification...........................14 3.4.4 Integrity Check Value Verification.....................16 3.4.5 Packet Decryption......................................16 4. Auditing.........................................................18 5. Conformance Requirements.........................................18 6. Security Considerations..........................................18 7. Differences from RFC 1827........................................19 Acknowledgements....................................................19 References..........................................................19 Disclaimer..........................................................20 Author Information..................................................21 Kent, Atkinson [Page 2] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) 1. Introduction The Encapsulating Security Payload (ESP) header is designed to provide a mix of 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 "Security Architecture for the Internet Protocol" [KA97a], hereafter referred to as the Security Architecture document). 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 the Security Architecture document [KA97a]. The ESP header is inserted after the IP header and before the upper layer protocol header (transport mode) or before an encapsulated IP header (tunnel mode). These modes are described in more detail below. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. The set of services provided depends on options selected at the time of Security Association establishment and on the placement of the implementation. Confidentiality may be selected independent of all other services. However, use of confidentiality without integrity/authentication (either in ESP or separately in AH) may subject traffic to certain forms of active attacks that could undermine the confidentiality service (see [Bel96]). Data origin authentication and connectionless integrity are joint services (hereafter referred to jointly as "authentication) and are offered as an option in conjunction with confidentiality. The anti-replay service may be selected only if data origin authentication is selected, and its election is solely at the discretion of the receiver. (Although the default calls for the sender to increment the Sequence Number used for anti-replay, the service is effective only if the receiver checks the Sequence Number.) Traffic flow confidentiality requires selection of tunnel mode, and is most effective if implemented at a security gateway, where traffic aggregation may be able to mask true source-destination patterns. It is assumed that the reader is familiar with the terms and concepts described in the Security Architecture document. In particular, the reader should be familiar with the definitions of security services offered by ESP and AH, the concept of Security Associations, the ways in which ESP can be used in conjunction with the Authentication Header (AH), and the different key management options available for Kent, Atkinson [Page 3] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) ESP and AH. (With regard to the last topic, the current key management options required for both AH and ESP are manual keying and automated keying via ISAKMP/Oakley.) The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [Bra97]. 2. Encapsulating Security Payload Packet Format The protocol header (IPv4, IPv6, or Extension) immediately preceding the ESP header will contain the value 50 in its Protocol (IPv4) or Next Header (IPv6, Extension) field [STD-2]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- | Security Parameters Index (SPI) | ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Auth. | Sequence Number | |Coverage +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----- | Payload Data* (variable) | | ^ ~ ~ | | | | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Confid. | | Padding (0-255 bytes) | |Coverage* +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Pad Length | Next Header | v v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------- | Authentication Data (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * If included in the Payload field, cryptographic synchronization data, e.g., an Initialization Vector (IV, see Section 2.3), usually is not encrypted per se, although it often is referred to as being part of the ciphertext. 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 Integrity Check Value (ICV, see Section 2.7). 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 Kent, Atkinson [Page 4] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) 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 that, in combination with the destination IP address and security protocol (ESP), uniquely identifies the Security Association for this datagram. 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. It is ordinarily selected by the destination system upon establishment of an SA (see the Security Architecture document for more details). The SPI field is mandatory. The SPI value of zero (0) is reserved for local, implementation- specific use and MUST NOT be sent on the wire. For example, a key management implementation MAY use the zero SPI value to mean "No Security Association Exists" during the period when the IPsec implementation has requested that its key management entity establish a new SA, but the SA has not yet been established. 2.2 Sequence Number This unsigned 32-bit field contains a monotonically increasing counter value (sequence number). It is mandatory and is always present even if the receiver does not elect to enable the anti-replay service for a specific SA. Processing of the Sequence Number field is at the discretion of the receiver, i.e., the sender MUST always transmit this field, but the receiver need not act upon it (see the discussion of Sequence Number Verification in the "Inbound Packet Processing" section below). The sender's counter and the receiver's counter are initialized to 0 when an SA is established. (The first packet sent using a given SA will have a Sequence Number of 1; see Section 3.3.3 for more details on how the Sequence Number is generated.) If anti-replay is enabled (the default), the transmitted Sequence Number must never be allowed to cycle. Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA. 2.3 Payload Data Payload Data is a variable-length field containing data described by the Next Header field. The Payload Data field is mandatory and is an Kent, Atkinson [Page 5] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) integral number of bytes in length. If the algorithm used to encrypt the payload requires cryptographic synchronization data, e.g., an Initialization Vector (IV), then this data MAY be carried explicitly in the Payload field. Any encryption algorithm that requires such explicit, per-packet synchronization data MUST indicate the length, any structure for such data, and the location of this data as part of an RFC specifying how the algorithm is used with ESP. If such synchronization data is implicit, the algorithm for deriving the data MUST be part of the RFC. Note that with regard to ensuring the alignment of the (real) ciphertext in the presence of an IV: o For some IV-based modes of operation, the receiver treats the IV as the start of the ciphertext, feeding it into the algorithm directly. In these modes, alignment of the start of the (real) ciphertext is not an issue at the receiver. o In some cases, the receiver reads the IV in separately from the ciphertext. In these cases, the algorithm specification MUST address how alignment of the (real) ciphertext is to be achieved. 2.4 Padding (for Encryption) Several factors require or motivate use of the Padding field. o If an encryption algorithm is employed that requires the plaintext to be a multiple of some number of bytes, e.g., the block size of a block cipher, the Padding field is used to fill the plaintext (consisting of the Payload Data, Pad Length and Next Header fields, as well as the Padding) to the size required by the algorithm. o Padding also may be required, irrespective of encryption algorithm requirements, to ensure that the resulting ciphertext terminates on a 4-byte boundary. Specifically, the Pad Length and Next Header fields must be right aligned within a 4-byte word, as illustrated in the ESP packet format figure above, to ensure that the Authentication Data field (if present) is aligned on a 4-byte boundary. o Padding beyond that required for the algorithm or alignment reasons cited above, may be used to conceal the actual length of the payload, in support of (partial) traffic flow confidentiality. However, inclusion of such additional padding has adverse bandwidth implications and thus its use should be undertaken with care. Kent, Atkinson [Page 6] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) The sender MAY add 0-255 bytes of padding. Inclusion of the Padding field in an ESP packet is optional, but all implementations MUST support generation and consumption of padding. The padding computation applies to the plaintext portion of the Payload Data, exclusive of the IV (if present). If Padding bytes are needed but the encryption algorithm does not specify the padding contents, then the following default processing MUST be used. The Padding bytes are initialized with a series of (unsigned, 1-byte) integer values. The first padding byte appended to the plaintext is numbered 1, with subsequent padding bytes making up a monotonically increasing sequence: 1, 2, 3, ... When this padding scheme is employed, the receiver SHOULD inspect the Padding field. (This scheme was selected because of its relative simplicity, ease of implementation in hardware, and because it offers limited protection against certain forms of "cut and paste" attacks in the absence of other integrity measures, if the receiver checks the padding values upon decryption.) Any encryption algorithm that requires Padding other than the default described above, MUST define the Padding contents (e.g., zeros or random data) and any required receiver processing of these Padding bytes in an RFC specifying how the algorithm is used with ESP. In such circumstances, the content of the Padding field will be determined by the encryption algorithm and mode selected and defined in the corresponding algorithm RFC. The relevant algorithm RFC MAY specify that a receiver MUST inspect the Padding field or that a receiver MUST inform senders of how the receiver will handle the Padding field. 2.5 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 no Padding bytes are present. The Pad Length field is mandatory. 2.6 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. Kent, Atkinson [Page 7] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) 2.7 Authentication Data The Authentication Data is a variable-length field containing an Integrity Check Value (ICV) computed over the ESP packet minus the Authentication Data. The length of the field is specified by the authentication function selected. The Authentication Data field is optional, and is included only if the authentication service has been selected for the SA in question. The authentication algorithm specification MUST specify the length of the ICV and the comparison rules and processing steps for validation. 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, note that for "bump-in-the-stack" or "bump-in-the- wire" implementations, as defined in the Security Architecture document, inbound and outbound IP fragments may require an IPsec implementation to perform extra IP reassembly/fragmentation in order to both conform to this specification and provide transparent IPsec support. Special care is required to perform such operations within these implementations when multiple interfaces are in use.) In transport mode, ESP is inserted after the IP header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other IPsec headers that have already been inserted. 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.) Kent, Atkinson [Page 8] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) BEFORE APPLYING ESP ---------------------------- IPv4 |orig IP hdr | | | |(any options)| TCP | Data | ---------------------------- AFTER APPLYING ESP ------------------------------------------------- IPv4 |orig IP hdr | ESP | | | ESP | ESP| |(any options)| Hdr | 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. BEFORE APPLYING ESP --------------------------------------- IPv6 | | ext hdrs | | | | orig IP hdr |if present| TCP | Data | --------------------------------------- AFTER APPLYING ESP --------------------------------------------------------- IPv6 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP| |IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer|Auth| --------------------------------------------------------- |<---- encrypted ---->| |<---- authenticated ---->| * = if present, could be before ESP, after ESP, or both ESP and AH headers can be combined in a variety of modes. The IPsec Architecture document describes the combinations of security associations that must be supported. 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 Kent, Atkinson [Page 9] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) "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* |new ext | | orig*|orig ext | | | ESP | ESP| |IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer|Auth| ------------------------------------------------------------ |<--------- encrypted ----------->| |<---------- authenticated ---------->| * = if present, construction of outer IP hdr/extensions and modification of inner IP hdr/extensions is discussed below. 3.2 Algorithms The mandatory-to-implement algorithms are described in Section 5, "Conformance Requirements". Other algorithms MAY be supported. 3.2.1 Encryption Algorithms 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 any data required to allow the receiver to establish cryptographic synchronization for decryption. This data may be carried explicitly in the payload field, e.g., as an IV (as described above), or the data may be derived from the packet header. Since ESP makes provision for padding of the plaintext, encryption algorithms employed with ESP may exhibit either block or stream mode characteristics. Kent, Atkinson [Page 10] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) 3.2.2 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 appropriate, though performance and space considerations currently preclude use of such algorithms. 3.3 Outbound Packet Processing In transport mode, the sender 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 Security Architecture document. If there is more than one IPsec header/extension required by security policy, the order of the application of the security headers MUST be defined by security policy. 3.3.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 Security Architecture document. 3.3.2 Packet Encryption The sender: 1. encapsulates (into the ESP Payload field): - for transport mode -- just the original upper layer protocol information. - for tunnel mode -- the entire original IP datagram. 2. adds any necessary padding. 3. encrypts the result (Payload Data, Padding, Pad Length, and Next Header) using the key, encryption algorithm, algorithm mode indicated by the SA and cryptographic synchronization data (if any). - If explicit cryptographic synchronization data, e.g., an IV, is indicated, it is input to the decryption algorithm per the algorithm specification and placed Kent, Atkinson [Page 11] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) in the Payload field. - If implicit cryptographic synchronication data, e.g., an IV, is indicated, it is constructed and input to the decryption algorithm as per the algorithm specification. The exact steps for constructing the outer IP header depend on the mode (transport or tunnel) and are described in the Security Architecture document. If authentication is 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. 3.3.3 Sequence Number Generation The sender's counter is initialized to 0 when an SA is established. The sender increments the Sequence Number for this SA and inserts the new value into the Sequence Number field. Thus the first packet sent using a given SA will have a Sequence Number of 1. If anti-replay is enabled (the default), the sender checks to ensure that the counter has not cycled before inserting the new value in the Sequence Number field. In other words, the sender MUST NOT send a packet on an SA if doing so would cause the Sequence Number to cycle. An attempt to transmit a packet that would result in Sequence Number overflow is an auditable event. (Note that this approach to Sequence Number management does not require use of modular arithmetic.) If anti-replay has been disabled, the sender does not need to monitor or reset the counter, e.g., in the case of manual key management (see Section 5). 3.3.4 Integrity Check Value Calculation If authentication is selected for the SA, the sender computes the ICV over the ESP packet minus the Authentication Data. Thus the SPI, Sequence Number, Payload Data, Padding (if present), Pad Length, and Next Header are all encompassed by the ICV computation. Note that the last 4 fields will be in ciphertext form, since encryption is Kent, Atkinson [Page 12] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) performed prior to authentication. 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, (after the Next Header field) 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. Note that MD5 and SHA-1 are viewed as having a 1-byte blocksize because of their internal padding conventions. 3.3.5 Fragmentation If necessary, fragmentation is performed after ESP processing within an IPsec implementation. Thus, transport mode ESP is applied only to whole IP datagrams (not to IP fragments). An IP packet to which ESP has been applied may itself be fragmented by routers en route, and such fragments must be reassembled prior to ESP processing at a receiver. In tunnel mode, ESP is applied to an IP packet, the payload of which may be a fragmented IP packet. For example, a security gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation (as defined in the Security Architecture document) may apply tunnel mode ESP to such fragments. NOTE: For transport mode -- As mentioned at the beginning of Section 3.1, bump-in-the-stack and bump-in-the-wire implementations may have to first reassemble a packet fragmented by the local IP layer, then apply IPsec, and then fragment the resulting packet. NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire implementations, it will be necessary to walk through all the extension headers to determine if there is a fragmentation header and hence that the packet needs reassembling prior to IPsec processing. 3.4 Inbound Packet Processing 3.4.1 Reassembly If required, reassembly is performed prior to ESP processing. If a packet offered to ESP for processing appears to be an IP fragment, i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, Kent, Atkinson [Page 13] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID. NOTE: For packet reassembly, the current IPv4 spec does NOT require either the zero'ing of the OFFSET field or the clearing of the MORE FRAGMENTS flag. In order for a reassembled packet to be processed by IPsec (as opposed to discarded as an apparent fragment), the IP code must do these two things after it reassembles a packet. 3.4.2 Security Association Lookup Upon receipt of a (reassembled) packet containing an ESP Header, the receiver determines the appropriate (unidirectional) SA, based on the destination IP address, security protocol (ESP), and the SPI. (This process is described in more detail in the Security Architecture document.) The SA indicates whether the Sequence Number field will be checked, whether the Authentication Data field 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 packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the cleartext Flow ID. 3.4.3 Sequence Number Verification All ESP implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. This service MUST NOT be enabled unless the authentication service also is enabled for the SA, since otherwise the Sequence Number field has not been integrity protected. (Note that there are no provisions for managing transmitted Sequence Number values among multiple senders directing traffic to a single SA (irrespective of whether the destination address is unicast, broadcast, or multicast). Thus the anti-replay service SHOULD NOT be used in a multi-sender environment that employs a single SA.) If the receiver does not enable anti-replay for an SA, no inbound checks are performed on the Sequence Number. The default for the sender is that the Sequence Number will be checked at the sender. Hence, if an SA establishment protocol such as ISAKMP/Oakley is employed, the receiver SHOULD notify the sender, during SA establishment, if the receiver will not provide anti-replay Kent, Atkinson [Page 14] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) protection. If the receiver has enabled the anti-replay service for this SA, the receive packet counter for the SA MUST be initialized to zero when the SA is established. For each received packet, 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 ESP 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.) A MINIMUM window size of 32 MUST be supported; but a window size of 64 is preferred and SHOULD be employed as the default. Another window size (larger than the MINIMUM) MAY be chosen by the receiver. (The receiver does NOT notify the sender of the window size.) The "right" edge of the window represents the highest, validated Sequence Number 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 the Security Architecture document. If the received packet falls within the window and is new, or if the packet is to the right of the window, then the receiver proceeds to ICV verification. If the ICV validation fails, the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, the Sequence Number, and (in IPv6) the Flow ID. The receive window is updated only if the ICV verification succeeds. DISCUSSION: Note that if the packet is either inside the window and new, or is outside the window on the "right" side, the receiver MUST authenticate the packet before updating the Sequence Number window data. Kent, Atkinson [Page 15] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) 3.4.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; this is an auditable event. The log data SHOULD include the SPI value, date/time received, Source Address, Destination Address, and (in IPv6) the cleartext Flow ID. 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 saved value, using the comparison rules defined by the algorithm specification. (For example, if a digital signature and one-way hash are used for the ICV computation, the matching process is more complex.) 3.4.5 Packet Decryption The receiver: 1. decrypts the ESP Payload Data, Padding, Pad Length, and Next Header using the key, encryption algorithm, algorithm mode, and cryptographic synchronization data (if any), indicated by the SA. - If explicit cryptographic synchronization data, e.g., an IV, is indicated, it is taken from the Payload field and input to the decryption algorithm as per the algorithm specification. - If implicit cryptographic synchronization data, e.g., an IV, is indicated, a local version of the IV is constructed and input to the decryption algorithm as per the algorithm specification. 2. processes any padding as specified in the encryption algorithm specification. The default action is to remove/ignore any padding. Kent, Atkinson [Page 16] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) 3. reconstructs the original IP datagram from: - for transport mode -- original IP header plus the original upper layer protocol information in the ESP Payload field - for tunnel mode -- tunnel IP header + the entire IP datagram in the ESP Payload field. The exact steps for reconstructing the original datagram depend on the mode (transport or tunnel) and are described in the Security Architecture document. At a minimum, in an IPv6 context, the receiver SHOULD ensure that the decrypted data is 8-byte aligned, to facilitate processing by the protocol identified in the Next Header field. If authentication has been selected, verification and decryption MAY be performed serially or in parallel. If performed serially, then ICV verification SHOULD be performed first. If performed in parallel, verification MUST be completed before the decrypted packet is passed on for further processing. 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. Note: If the receiver performs decryption in parallel with authentication, care must be taken to avoid possible race conditions with regard to packet access and reconstruction of the decrypted packet. Note that there are several ways in which the decryption can "fail": a. The selected SA may not be correct -- The SA may be mis-selected due to tampering with the SPI, destination address. or IPsec protocol type fields. Such errors, if they map the packet to another extant SA, will be indistinguishable from a corrupted packet, (case c). Tampering with the SPI can be detected by use of authentication. However, an SA mismatch might still occur due to tampering with the IP Destination Address or the IPsec protocol type field. b. The pad length or pad values could be erroneous -- Bad pad lengths or pad values can be detected irrespective of the use of authentication. c. The encrypted ESP packet could be corrupted -- This can be detected if authentication is selected for the SA., In case (a) or (c), the erroneous result of the decryption operation (an invalid IP datagram or transport-layer frame) will not Kent, Atkinson [Page 17] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) necessarily be detected by IPsec, and is the responsibility of later protocol processing. 4. Auditing Not all systems that implement ESP will implement auditing. However, if ESP is incorporated into a system that supports auditing, then the ESP implementation MUST also support auditing and MUST allow a system administrator to enable or disable auditing for ESP. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in this specification and for each of these events a minimum set of information that SHOULD be included in an audit log is defined. Additional information also MAY be included in the audit log for each of these events, and additional events, not explicitly called out in this specification, also MAY result in audit log entries. There is no requirement for the receiver to transmit any message to the purported sender in response to the detection of an auditable event, because of the potential to induce denial of service via such action. 5. 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 document. If the key used to compute an ICV is manually distributed, correct provision of the anti-replay service would require correct maintenance of the counter state at the sender, until the key is replaced, and there likely would be no automated recovery provision if counter overflow were imminent. Thus a compliant implementation SHOULD NOT provide this service in conjunction with SAs that are manually keyed. A compliant ESP implementation MUST support the following mandatory-to-implement algorithms: - DES in CBC mode [MD97] - HMAC with MD5 [MG97a] - HMAC with SHA-1 [MG97b] 6. Security Considerations Security is central to the design of this protocol, and thus security considerations permeate the specification. Additional security- relevant aspects of using the IPsec protocol are discussed in the Security Architecture document. Kent, Atkinson [Page 18] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) 7. Differences from RFC 1827 This document differs from RFC 1827 [ATK95] in several significant ways. The major difference is that, this document attempts to specify a complete framework and context for ESP, whereas RFC 1827 provided a "shell" that was completed through the definition of transforms. The combinatorial growth of transforms motivated the reformulation of the ESP specification as a more complete document, with options for security services that may be offered in the context of ESP. Thus, fields previously defined in transform documents are now part of this base ESP specification. For example, the fields necessary to support authentication (and anti-replay) are now defined here, even though the provision of this service is an option. The fields used to support padding for encryption, and for next protocol identification, are now defined here as well. Packet processing consistent with the definition of these fields also is included in the document. 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 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 Karen Seo for providing extensive help in the review, editing, background research, and coordination for this version of the specification. The authors would also 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, Norman Shulman, William Simpson and Nina Yuan. References [ATK95] R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 1827, August 1997. [Bel96] Steven M. Bellovin, "Problem Areas for the IP Security Protocols", Proceedings of the Sixth Usenix Unix Security Kent, Atkinson [Page 19] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) Symposium, July, 1996. [Bra97] S. Bradner, "Key words for use in RFCs to Indicate Requirement Level," RFC-2119, March 1997. [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. [KA97a] Steve Kent, Randall Atkinson, "Security Architecture for the Internet Protocol", Internet Draft, February 1998. [KA97b] Steve Kent, Randall Atkinson, "IP Authentication Header", Internet Draft, February 1998. [MD97] C. Madson & N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", Internet Draft, Deceber 1997. [MG97a] C. Madson & R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", Internet Draft, November 1997. [MG97b] C. Madson & R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", Internet Draft, November 1997. [STD-2] J. Reynolds and J. Postel, "Assigned Numbers", STD-2, 20 October 1994. [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. 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. Kent, Atkinson [Page 20] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) Author Information Stephen Kent BBN Corporation 70 Fawcett Street Cambridge, MA 02140 USA E-mail: kent@bbn.com Telephone: +1 (617) 873-3988 Randall Atkinson @Home Network 425 Broadway, Redwood City, CA 94063 USA E-mail: rja@inet.org Copyright (C) The Internet Society (February 1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Kent, Atkinson [Page 21] ----- End of forwarded messages -- John Kelley johnk@tis.com Director, Systems Administration Trusted Information Systems, Inc. (A NASDAQ company: "TISX") http://www.tis.com From owner-ipsec Mon Feb 16 17:05:44 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA23716 for ipsec-outgoing; Mon, 16 Feb 1998 17:01:59 -0500 (EST) Message-Id: <199802162201.RAA23716@portal.ex.tis.com> Date: Sun, 15 Feb 1998 11:38:53 +0200 (IST) From: Hugo Krawczyk To: ipsec@tis.com, rob.glenn@nist.gov Subject: Re: Summary of changes to HMAC-MD5-96 draft Sender: owner-ipsec@ex.tis.com Precedence: bulk Rob, the addition below is not acceptable in the text: > >4. In response to the document reading party's comment: > >>There is a requirment that "any known attacks" be discussed in the >>Security Considerations section. The MD5-96-01 doc does not discuss this. > >The following as added to paragraph 1 of section 5. > >At the time of this writing there are no known cryptographic attacks against >HMAC-MD5-96. Of course, THERE ARE such attacks (exhaustive key recovery attack, MAC guessing attacks, on-line birthday attacks are all cryptographic attacks). Even if they are currently impractical they exist. You should refer to the following text of rfc 2104 or even adapt a part of it to your needs here (I stress that this text does apply to the 96-bit truncated output version used in ipsec). The strongest attack known against HMAC is based on the frequency of collisions for the hash function H ("birthday attack") [PV,BCK2], and is totally impractical for minimally reasonable hash functions. As an example, if we consider a hash function like MD5 where the output length equals L=16 bytes (128 bits) the attacker needs to acquire the correct message authentication tags computed (with the _same_ secret key K!) on about 2**64 known plaintexts. This would require the processing of at least 2**64 blocks under H, an impossible task in any realistic scenario (for a block length of 64 bytes this would take 250,000 years in a continuous 1Gbps link, and without changing the secret key K during all this time). This attack could become realistic only if serious flaws in the collision behavior of the function H are discovered (e.g. collisions found after 2**30 messages). Such a discovery would determine the immediate replacement of the function H (the effects of such failure would be far more severe for the traditional uses of H in the context of digital signatures, public key certificates, etc.). Another part of rfc 2104 that you may want to bring explicitly is: Keys need to be chosen at random (or using a cryptographically strong pseudo-random generator seeded with a random seed), and periodically refreshed. (Current attacks do not indicate a specific recommended frequency for key changes as these attacks are practically infeasible. However, periodic key refreshment is a fundamental security practice that helps against potential weaknesses of the function and keys, and limits the damage of an exposed key.) Hugo > >Rob G. >rob.glenn@nist.gov > > > -- John Kelley johnk@tis.com Director, Systems Administration Trusted Information Systems, Inc. (A NASDAQ company: "TISX") http://www.tis.com From owner-ipsec Mon Feb 16 17:05:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA23638 for ipsec-outgoing; Mon, 16 Feb 1998 16:55:59 -0500 (EST) Message-Id: <199802162155.QAA23638@portal.ex.tis.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 13 Feb 1998 08:09:25 -0500 To: Engineering , Daniel Harkins From: Robert Moskowitz Subject: Re: Help - Details on March 2nd worshop at Raliegh requested ... Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:54 PM 2/12/98 -0500, Robert Moskowitz wrote: >At 05:28 PM 2/12/98 -0600, Engineering wrote: >> >>What sort of space will be available to each vendor. Do we need to >>bring any special fixtures besides computer equipment and power fixtures. >>(Tables, chairs, banner or identification, ... ?) > >You will need to bring your own hubs and cables. I will be bringing the hub for non-vendor participants, a few cables, and a powerstrip... Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com -- John Kelley johnk@tis.com Director, Systems Administration Trusted Information Systems, Inc. (A NASDAQ company: "TISX") http://www.tis.com From owner-ipsec Mon Feb 16 17:06:23 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA23749 for ipsec-outgoing; Mon, 16 Feb 1998 17:04:58 -0500 (EST) Message-Id: <199802162204.RAA23749@portal.ex.tis.com> Date: Fri, 13 Feb 1998 17:28:12 -0600 (CST) From: Engineering To: Daniel Harkins cc: ipsec@tis.com Subject: Re: Help - Details on March 2nd worshop at Raliegh requested ... Sender: owner-ipsec@ex.tis.com Precedence: bulk > scenarios then the answer is yes. IPSec and NAT will most likely be tested. This was the answer I was looking for. Thanks, Jeffrey Goodwin ** Ashley Laurent,Inc. ** Software Development ** Consulting ** * * * * 707 West Avenue, Suite 201 * voice: 512-322-0676 * * Austin, Texas 78701 * fax : 512-322-0680 * * web: http://www.osgroup.com * * Microsoft Solution Provider * Complete Systems Design/Development * * Novell Professional Developer * Systems Software/Device Drivers * -- John Kelley johnk@tis.com Director, Systems Administration Trusted Information Systems, Inc. (A NASDAQ company: "TISX") http://www.tis.com From owner-ipsec Mon Feb 16 17:07:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA23787 for ipsec-outgoing; Mon, 16 Feb 1998 17:06:09 -0500 (EST) Message-Id: <199802162206.RAA23787@portal.ex.tis.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: ipsec@tis.com Subject: I like IKE! Date: Fri, 13 Feb 1998 15:17:41 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Changes have been made to the I-O Resolution Document and a new version has been submitted. Changes are: 0. The name has been changed from "The Resolution of ISAKMP with Oakley" to "The Internet Key Exchange (IKE)". 1. Mention that the final Aggressive Mode message need not be transmitted in the clear was added to section 5. 2. The payload explosion incorrectly set the SPI size of an AH offer to 8. It is now 4 octets. section 7.2. 3. A mention was made in Appendix A that the key length attribute MUST NOT be sent in a phase 1 offer when the encryption algorithm uses a fixed key length. 4. Section 5 now clarifies how multiple phase 1 offers are made. They MUST be a single SA payload with a single Proposal payload with possibly many transform payloads. 5. Appendix A incorrectly failed to reserved the value 6 to IANA. This was changed. 6. Added clarification to Appendix A on attribute encoding. Basic attributes MUST NOT be encoded as variable but if an attribute whose type is variable has a value that is small enough, it can be encoded as basic and that does not void the "responder can't change offers" rule. 7. Clarification that offers may not be changed in section 5. 8. Section 5.5 now states that phase 2 offers are logically related and must be consistant. 9. removed references to 3DES-CBC-MAC but left the PRF attribute to be negotiated using private use values until such time as IANA assigns a number. throughout. 10. added an IANA considerations section. So, for your consideration... IKE! Dan. ----------------------------------------------------------------------- IPSEC Working Group D. Harkins, D. Carrel INTERNET-DRAFT cisco Systems draft-ietf-ipsec-isakmp-oakley-06.txt February 1998 The Internet Key Exchange (IKE) Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inapproporiate to use Internet Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet Draft, please check the "1id-abstracts.txt" listing contained in the Internet Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Australia), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Table Of Contents 1 Abstract 2 Discussion 3 Terms and Definitions 3.1 Requirements Terminology 3.2 Notation 3.3 Perfect Forward Secrecty 3.4 Security Association 4 Introduction 5 Exchanges 5.1 Authentication with Digital Signatures 5.2 Authentication with Public Key Encryption 5.3 A Revised method of Authentication with Public Key Encryption 5.4 Authentication with a Pre-Shared Key 5.5 Quick Mode 5.6 New Group Mode 5.7 ISAKMP Informational Exchanges 6 Oakley Groups Harkins, Carrel [Page 1] INTERNET DRAFT February 1998 6.1 First Oakley Group 6.2 Second Oakley Group 6.3 Third Oakley Group 6.4 Fourth Oakley Group 7 Payload Explosion of Complete Exchange 7.1 Phase 1 with Main Mode 7.2 Phase 2 with Quick Mode 8 Perfect Forward Secrecy Example 9 Implementation Hints 10 Security Considerations 11 IANA Considerations 12 Acknowledgments 13 References Appendix A Appendix B 1. Abstract [MSST98] (ISAKMP) provides a framework for authentication and key exchange but does not define them. ISAKMP is designed to be key exchange independant; that is, it is designed to support many different key exchanges. [Orm96] (Oakley) describes a series of key exchanges-- called "modes"-- and details the services provided by each (e.g. perfect forward secrecy for keys, identity protection, and authentication). [Kra96] (SKEME) describes a versatile key exchange technique which provides anonymity, repudiability, and quick key refreshment. This document describes a protocol using part of Oakley and part of SKEME in conjunction with ISAKMP to obtain authenticated keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI. Harkins, Carrel [Page 2] INTERNET DRAFT February 1998 2. Discussion This draft describes a hybrid protocol. The purpose is to negotiate, and provide authenticated keying material for, security associations in a protected manner. Processes which implement this draft can be used for negotiating virtual private networks (VPNs) and also for providing a remote user from a remote site (whose IP address need not be known beforehand) access to a secure host or network. Client negotiation is supported. Client mode is where the negotiating parties are not the endpoints for which security association negotiation is taking place. When used in client mode, the identities of the end parties remain hidden. This does not implement the entire Oakley protocol, but only a subset necessary to satisfy its goals. It does not claim conformance or compliance with the entire Oakley protocol nor is it dependant in any way on the Oakley protocol. Likewise, this does not implement the entire SKEME protocol, but only the method of public key encryption for authentication and its concept of fast re-keying using an exchange of nonces. This protocol is not dependant in any way on the SKEME protocol. 3. Terms and Definitions 3.1 Requirements Terminology Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [Bra97]. 3.2 Notation The following notation is used throughout this draft. HDR is an ISAKMP header whose exchange type is the mode. When writen as HDR* it indicates payload encryption. SA is an SA negotiation payload with one or more proposals. An initiator MAY provide multiple proposals for negotiation; a responder MUST reply with only one.

_b indicates the body of payload

-- the ISAKMP generic payload is not included. Harkins, Carrel [Page 3] INTERNET DRAFT February 1998 SAi_b is the entire body of the SA payload (minus the ISAKMP generic header)-- i.e. the DOI, situation, all proposals and all transforms offered by the Initiator. CKY-I and CKY-R are the Initiator's cookie and the Responder's cookie, respectively, from the ISAKMP header. g^xi and g^xr are the Diffie-Hellman public values of the initiator and responder respectively. g^xy is the Diffie-Hellman shared secret. KE is the key exchange payload which contains the public information exchanged in a Diffie-Hellman exchange. There is no particular encoding used for the data of a KE payload. Nx is the nonce payload; x can be: i or r for the ISAKMP initiator and responder respectively. IDx is the identity payload for "x". x can be: "ii" or "ir" for the ISAKMP initiator and responder respectively during phase one negotiation; or "ui" or "ur" for the user initiator and responder respectively during phase two. The ID payload format for the Internet DOI is defined in [Pip97]. SIG is the signature payload. The data to sign is exchange- specific. CERT is the certificate payload. HASH (and any derivitive such as HASH(2) or HASH_I) is the hash payload. The contents of the hash are specific to the authentication method. prf(key, msg) is the keyed pseudo-random function-- often a keyed hash function-- used to generate a deterministic output that appears pseudo-random. prf's are used both for key derivations and for authentication (i.e. as a keyed MAC). (See [KBC96]). SKEYID is a string derived from secret material known only to the active players in the exchange. SKEYID_e is the keying material used by the ISAKMP SA to protect the confidentiality of its messages. SKEYID_a is the keying material used by the ISAKMP SA to authenticate its messages. Harkins, Carrel [Page 4] INTERNET DRAFT February 1998 SKEYID_d is the keying material used to derive keys for non-ISAKMP security associations. y indicates that "x" is encrypted with the key "y". --> signifies "initiator to responder" communication (requests). <-- signifies "responder to initiator" communication (replies). | signifies concatenation of information-- e.g. X | Y is the concatentation of X with Y. [x] indicates that x is optional. Message encryption (when noted by a '*' after the ISAKMP header) MUST begin immediately after the ISAKMP header. When communication is protected, all payloads following the ISAKMP header MUST be encrypted. Encryption keys are generated from SKEYID_e in a manner that is defined for each algorithm. 3.3 Perfect Forward Secrecy When used in the draft Perfect Forward Secrecy (PFS) refers to the notion that compromise of a single key will permit access to only data protected by a single key. For PFS to exist the key used to protect transmission of data MUST NOT be used to derive any additional keys, and if the key used to protect transmission of data was derived from some other keying material, that material MUST NOT be used to derive any more keys. Perfect Forward Secrecy for both keys and identities is provided in this protocol. (Sections 5.5 and 8). 3.4 Security Association A security association (SA) is a set of policy and key(s) used to protect information. The ISAKMP SA is the shared policy and key(s) used by the negotiating peers in this protocol to protect their communication. 4. Introduction Oakley and SKEME each define a method to establish an authenticated key exchange. This includes payloads construction, the information payloads carry, the order in which they are processed and how they are used. While Oakley defines "modes", ISAKMP defines "phases". The Harkins, Carrel [Page 5] INTERNET DRAFT February 1998 relationship between the two is very straightforward and IKE presents different exchanges as modes which operate in one of two phases. Phase 1 is where the two ISAKMP peers establish a secure, authenticated channel with which to communicate. This is called the ISAKMP Security Association (SA). "Main Mode" and "Aggressive Mode" each accomplish a phase 1 exchange. "Main Mode" and "Aggressive Mode" MUST ONLY be used in phase 1. Phase 2 is where Security Associations are negotiated on behalf of services such as IPsec or any other service which needs key material and/or parameter negotiation. "Quick Mode" accomplishes a phase 2 exchange. "Quick Mode" MUST ONLY be used in phase 2. "New Group Mode" is not really a phase 1 or phase 2. It follows phase 1, but serves to establish a new group which can be used in future negotiations. "New Group Mode" MUST ONLY be used after phase 1. The ISAKMP SA is bi-directional. That is, once established, either party may initiate Quick Mode, Informational, and New Group Mode Exchanges. Per the base ISAKMP document, the ISAKMP SA is identified by the Initiator's cookie followed by the Responder's cookie-- the role of each party in the phase 1 exchange dictates which cookie is the Initiator's. The cookie order established by the phase 1 exchange continues to identify the ISAKMP SA regardless of the direction the Quick Mode, Informational, or New Group exchange. In other words, the cookies MUST NOT swap places when the direction of the ISAKMP SA changes. With the use of ISAKMP phases, an implementation can accomplish very fast keying when necessary. A single phase 1 negotiation may be used for more than one phase 2 negotiation. Additionally a single phase 2 negotiation can request multiple Security Associations. With these optimizations, an implementation can see less than one round trip per SA as well as less than one DH exponentiation per SA. "Main Mode" for phase 1 provides identity protection. When identity protection is not needed, "Aggressive Mode" can be used to reduce round trips even further. Developer hints for doing these optimizations are included below. It should also be noted that using public key encryption to authenticate an Aggressive Mode exchange will still provide identity protection. This protocol does not define its own DOI per se. The ISAKMP SA, established in phase 1, MAY use the DOI and situation from a non- ISAKMP service (such as the IETF IPSec DOI [Pip97]). In this case an implementation MAY choose to restrict use of the ISAKMP SA for establishment of SAs for services of the same DOI. Alternately, an Harkins, Carrel [Page 6] INTERNET DRAFT February 1998 ISAKMP SA MAY be established with the value zero in both the DOI and situation (see [MSST98] for a description of these fields) and in this case implementations will be free to establish security services for any defined DOI using this ISAKMP SA. If a DOI of zero is used for establishment of a phase 1 SA, the syntax of the identity payloads used in phase 1 is that defined in [MSST98] and not from any DOI-- e.g. [Pip97]-- which may further expand the syntax and semantics of identities. The following attributes are used by IKE and are negotiated as part of the ISAKMP Security Association. (These attributes pertain only to the ISAKMP Security Association and not to any Security Associations that ISAKMP may be negotiating on behalf of other services.) - encryption algorithm (e.g. DES, IDEA, Blowfish). - hash algorithm (e.g. MD5, SHA) - authentication method (e.g. DSS sig, RSA sig, RSA encryption, pre-shared key) - information about a group over which to do Diffie-Hellman. All of these attributes are mandatory and MUST be negotiated. In addition, it is possible to optionally negotiate a psuedo-random function ("prf"). (There are currently no negotiable pseudo-random functions defined in this document. Private use attribute values can be used for prf negotiation between consenting parties). If a "prf" is not negotiation, the HMAC (see [KBC96]) version of the negotiated hash algorithm is used as a pseudo-random function. Other non- mandatory attributes are described in Appendix A. The selected hash algorithm MUST support both native and HMAC modes. The Diffie-Hellman group MUST be either specified using a defined group description (section 6) or by defining all attributes of a group (section 5.6). Group attributes (such as group type or prime-- see Appendix A) MUST NOT be offered in conjunction with a previously defined group (either a reserved group description or a private use description that is established after conclusion of a New Group Mode exchange). IKE implementations MUST support the following attribute values: - DES-CBC with a weak, and semi-weak, key check (weak and semi- weak keys are referenced in [Sch96] and listed in Appendix A). The key is derived according to Appendix B. Harkins, Carrel [Page 7] INTERNET DRAFT February 1998 - MD5 and SHA. - Authentication via pre-shared keys. The Digital Signature Standard SHOULD be supported; RSA-- both signatures and authentication with public key encryption-- SHOULD be supported. - MODP over the default group (see below). ECP and EC2N groups MAY be supported. The IKE modes described here MUST be implemented whenever the IETF IPsec DOI [Pip97] is implemented. Other DOIs MAY use the modes described here. 5. Exchanges There are two basic methods used to establish an authenticated key exchange: Main Mode and Aggressive Mode. Each generates authenticated keying material from an ephemeral Diffie-Hellman exchange. Main Mode MUST be implemented; Aggressive Mode SHOULD be implemented. In addition, Quick Mode MUST be implemented as a mechanism to generate fresh keying material and negotiate non-ISAKMP security services. In additon, New Group Mode SHOULD be implemented as a mechanism to define private groups for Diffie-Hellman exchanges. Implementations MUST NOT switch exchange types in the middle of an exchange. Exchanges conform to standard ISAKMP [MSST98] payload syntax, attribute encoding, timeouts and retransmits of messages, and informational messages-- e.g a notify response is sent when, for example, a proposal is unacceptable, or a signature verification or decryption was unsuccessful, etc. The SA payload MUST precede all other payloads in a phase 1 exchange. Except where otherwise noted, there are no requirements for ISAKMP payloads in any message to be in any particular order. Main Mode is an instantiation of the ISAKMP Identity Protect Exchange: The first two messages negotiate policy; the next two exchange Diffie-Hellman public values and ancillary data (e.g. nonces) necessary for the exchange; and the last two messages authenticate the Diffie-Hellman Exchange. The authentication method negotiated as part of the initial ISAKMP exchange influences the composition of the payloads but not their purpose. The XCHG for Main Mode is ISAKMP Identity Protect. Similarly, Aggressive Mode is an instantiation of the ISAKMP Aggressive Exchange. The first two messages negotiate policy, exchange Diffie-Hellman public values and ancillary data necessary for the exchange, and identities. In addition the second message Harkins, Carrel [Page 8] INTERNET DRAFT February 1998 authenticates the responder. The third message authenticates the initiator and provides a proof of participation in the exchange. The XCHG for Aggressive Mode is ISAKMP Aggressive. The final message MAY NOT be sent under protection of the ISAKMP SA allowing each party to postpone exponentiation, if desired, until negotiation of this exchange is complete. The graphic depictions of Aggressive Mode show the final payload in the clear; it need not be. Security Association negotiation is limited with Aggressive Mode. Due to message construction requirements the group in which the Diffie- Hellman exchange is performed cannot be negotiated. In addition, different authentication methods may further constrain attribute negotiation. For example, authentication with public key encryption cannot be negotiated and when using the revised method of public key encryption for authentication the cipher and hash cannot be negotiated. For situations where the rich attribute negotiation capabilities of IKE are required Main Mode may be required. Quick Mode and New Group Mode have no analog in ISAKMP. The XCHG values for Quick Mode and New Group Mode are defined in Appendix A. Main Mode, Aggressive Mode, and Quick Mode do security association negotiation. Security Association offers take the form of Tranform Payload(s) encapsulated in Proposal Payload(s) encapsulated in Security Association (SA) payload(s). If multiple offers are being made for phase 1 exchanges (Main Mode and Aggressive Mode) they MUST take the form of multiple Transform Payloads for a single Proposal Payload in a single SA payload. To put it another way, for phase 1 exchanges there MUST NOT be multiple Proposal Payloads for a single SA payload and there MUST NOT be multiple SA payloads. This document does not proscribe such behavior on offers in phase 2 exchanges. There is no limit on the number of offers the initiator may send to the responder but conformant implementations MAY choose to limit the number of offers it will inspect for performance reasons. During security association negotiation, initiators present offers for potential security associations to responders. Responders MUST NOT modify attributes of any offer, attribute encoding excepted (see Appendix A). If the initiator of an exchange notices that attribute values have changed or attributes have been added or deleted from an offer made, that response MUST be rejected. Four different authentication methods are allowed with either Main Mode or Aggressive Mode-- digital signature, two forms of authentication with public key encryption, or pre-shared key. The value SKEYID is computed seperately for each authentication method. Harkins, Carrel [Page 9] INTERNET DRAFT February 1998 For signatures: SKEYID = prf(Ni_b | Nr_b, g^xy) For public key encryption: SKEYID = prf(hash(Ni_b | Nr_b), CKY-I | CKY-R) For pre-shared keys: SKEYID = prf(pre-shared-key, Ni_b | Nr_b) The result of either Main Mode or Aggressive Mode is three groups of authenticated keying material: SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1) SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2) and agreed upon policy to protect further communications. The values of 0, 1, and 2 above are represented by a single octet. The key used for encryption is derived from SKEYID_e in an algorithm-specific manner (see appendix B). To authenticate either exchange the initiator of the protocol generates HASH_I and the responder generates HASH_R where: HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b ) HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b ) For authentication with digital signatures, HASH_I and HASH_R are signed and verified; for authentication with either public key encryption or pre-shared keys, HASH_I and HASH_R directly authenticate the exchange. The entire ID payload (including ID type, port, and protocol but excluding the generic header) is hashed into both HASH_I and HASH_R. As mentioned above, the negotiated authentication method influences the content and use of messages for Phase 1 Modes, but not their intent. When using public keys for authentication, the Phase 1 exchange can be accomplished either by using signatures or by using public key encryption (if the algorithm supports it). Following are Phase 1 exchanges with different authentication options. 5.1 IKE Phase 1 Authenticated With Signatures Using signatures, the ancillary information exchanged during the second roundtrip are nonces; the exchange is authenticated by signing a mutually obtainable hash. Main Mode with signature authentication is described as follows: Initiator Responder ---------- ----------- HDR, SA --> Harkins, Carrel [Page 10] INTERNET DRAFT February 1998 <-- HDR, SA HDR, KE, Ni --> <-- HDR, KE, Nr HDR*, IDii, [ CERT, ] SIG_I --> <-- HDR*, IDir, [ CERT, ] SIG_R Aggressive mode with signatures in conjunction with ISAKMP is described as follows: Initiator Responder ----------- ----------- HDR, SA, KE, Ni, IDii --> <-- HDR, SA, KE, Nr, IDir, [ CERT, ] SIG_R HDR, [ CERT, ] SIG_I --> In both modes, the signed data, SIG_I or SIG_R, is the result of the negotiated digital signature algorithm applied to HASH_I or HASH_R respectively. In general the signature will be over HASH_I and HASH_R as above using the negotiated prf, or the HMAC version of the negotiated hash function (if no prf is negotiated). However, this can be overridden for construction of the signature if the signature algorithm is tied to a particular hash algorithm (e.g. DSS is only defined with SHA's 160 bit output). In this case, the signature will be over HASH_I and HASH_R as above, except using the HMAC version of the hash algorithm associated with the signature method. The negotiated prf and hash function would continue to be used for all other prescribed pseudo- random functions. Since the hash algorithm used is already known there is no need to encode its OID into the signature. In addition, there is no binding between the OIDs used for RSA signatures in PKCS #1 and those used in this document. Therefore, RSA signatures MUST be encoded as a private key encryption in PKCS #1 format. DSS signatures MUST be encoded as r followed by s. One or more certificate payloads MAY be optionally passed. 5.2 Phase 1 Authenticated With Public Key Encryption Using public key encryption to authenticate the exchange, the ancillary information exchanged is encrypted nonces. Each party's ability to reconstruct a hash (proving that the other party decrypted the nonce) authenticates the exchange. In order to perform the public key encryption, the initiator must Harkins, Carrel [Page 11] INTERNET DRAFT February 1998 already have the responder's public key. In the case where the responder has multiple public keys, a hash of the certificate the initiator is using to encrypt the ancillary information is passed as part of the third message. In this way the responder can determine which corresponding private key to use to decrypt the encrypted payloads and identity protection is retained. In addition to the nonce, the identities of the parties (IDii and IDir) are also encrypted with the other party's 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, Main Mode is defined as follows. Initiator Responder ----------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, [ HASH(1), ] PubKey_r, PubKey_r --> HDR, KE, PubKey_i, <-- PubKey_i HDR*, HASH_I --> <-- HDR*, HASH_R Aggressive Mode authenticated with encryption is described as follows: Initiator Responder ----------- ----------- HDR, SA, [ HASH(1),] KE, Pubkey_r, Pubkey_r --> HDR, SA, KE, PubKey_i, <-- PubKey_i, HASH_R HDR, HASH_I --> Where HASH(1) is a hash (using the negotiated hash function) of the certificate which the initiator is using to encrypt the nonce and identity. RSA encryption MUST be encoded in PKCS #1 format. While only the body of the ID and nonce payloads is encrypted, the encrypted data must be preceded by a valid ISAKMP generic header. The payload length is the Harkins, Carrel [Page 12] INTERNET DRAFT February 1998 length of the entire encrypted payload plus header. The PKCS #1 encoding allows for determination of the actual length of the cleartext payload upon decryption. Using encryption for authentication provides for a plausably deniable exchange. There is no proof (as with a digital signature) that the conversation ever took place since each party can completely reconstruct both sides of the exchange. In addition, security is added to secret generation since an attacker would have to successfully break not only the Diffie-Hellman exchange but also both RSA encryptions. This exchange was motivated by [Kra96]. Note that, unlike other authentication methods, authentication with public key encryption allows for identity protection with Aggressive Mode. 5.3 Phase 1 Authenticated With a Revised Mode of Public Key Encryption Authentication with Public Key Encryption has significant advantages over authentication with signatures (see section 5.2 above). Unfortunately, this is at the cost of 4 public key operations-- two public key encryptions and two private key decryptions. This authentication mode retains the advantages of authentication using public key encryption but does so with half the public key operations. In this mode, the nonce is still encrypted using the public key of the peer, however the peer's identity (and the certificate if it is sent) is encrypted using the negotiated symmetric encryption algorithm (from the SA payload) with a key derived from the nonce. This solution adds minimal complexity and state yet saves two costly public key operations on each side. In addition, the Key Exchange payload is also encrypted using the same derived key. This provides additional protection against cryptanalysis of the Diffie-Hellman exchange. As with the public key encryption method of authentication (section 5.2), a HASH payload may be sent to identify a certificate if the responder has multiple certificates which contain useable public keys (e.g. if the certificate is not for signatures only, either due to certificate restrictions or algorithmic restrictions). If the HASH payload is sent it MUST be the first payload of the second message exchange and MUST be followed by the encrypted nonce. If the HASH payload is not sent, the first payload of the second message exchange MUST be the encrypted nonce. In addition, the initiator my optionally send a certificate payload to provide the responder with a public key with which to respond. Harkins, Carrel [Page 13] INTERNET DRAFT February 1998 When using the revised encryption mode for authentication, Main Mode is defined as follows. Initiator Responder ----------- ----------- HDR, SA --> <-- HDR, SA HDR, [ HASH(1), ] Pubkey_r, Ke_i, Ke_i, [<Ke_i] --> HDR, PubKey_i, Ke_r, <-- Ke_r, HDR*, HASH_I --> <-- HDR*, HASH_R Aggressive Mode authenticated with the revised encryption method is described as follows: Initiator Responder ----------- ----------- HDR, SA, [ HASH(1),] Pubkey_r, Ke_i, Ke_i [, Ke_i ] --> HDR, SA, PubKey_i, Ke_r, Ke_r, <-- HASH_R HDR, HASH_I --> where HASH(1) is identical to section 5.2. Ke_i and Ke_r are keys to the symmetric encryption algorithm negotiated in the SA payload exchange. Only the body of the payloads are encrypted (in both public key and symmetric operations), the generic payload headers are left in the clear. The payload length includes that added to perform encryption. The symmetric cipher keys are derived from the decrypted nonces as follows. First the values Ne_i and Ne_r are computed: Ne_i = prf(Ni_b, CKY-I) Ne_r = prf(Nr_b, CKY-R) The keys Ke_i and Ke_r are then taken from Ne_i and Ne_r respectively in the manner described in Appendix B used to derive symmetric keys for use with the negotiated encryption algorithm. If the length of Harkins, Carrel [Page 14] INTERNET DRAFT February 1998 the output of the negotiated prf is greater than or equal to the key length requirements of the cipher, Ke_i and Ke_r are derived from the most significant bits of Ne_i and Ne_r respectively. If the desired length of Ke_i and Ke_r exceed the length of the output of the prf the necessary number of bits is obtained by repeatedly feeding the results of the prf back into itself and concatenating the result until the necessary number has been achieved. For example, if the negotiated encryption algorithm requires 320 bits of key and the output of the prf is only 128 bits, Ke_i is the most significant 320 bits of K, where K = K1 | K2 | K3 and K1 = prf(Ne_i, 0) K2 = prf(Ne_i, K1) K3 = prf(Ne_i, K2) For brevity, only derivation of Ke_i is shown; Ke_r is identical. The length of the value 0 in the computation of K1 is a single octet. Note that Ne_i, Ne_r, Ke_i, and Ke_r are all ephemeral and MUST be discarded after use. Save the requirements on the location of the optional HASH payload and the mandatory nonce payload there are no further payload requirements. All payloads-- in whatever order-- following the encrypted nonce MUST be encrypted with Ke_i or Ke_r depending on the direction. If CBC mode is used for the symmetric encryption then the initialization vectors (IVs) are set as follows. The IV for encrypting the first payload following the nonce is set to 0 (zero). The IV for subsequent payloads encrypted with the ephemeral symmetric cipher key, Ke_i, is the last ciphertext block of the previous payload. Encrypted payloads are padded up to the nearest block size. All padding bytes, except for the last one, contain 0x00. The last byte of the padding contains the number of the padding bytes used, excluding the last one. Note that this means there will always be padding. 5.4 Phase 1 Authenticated With a Pre-Shared Key A key derived by some out-of-band mechanism may also be used to authenticate the exchange. The actual establishment of this key is out of the scope of this document. When doing a pre-shared key authentication, Main Mode is defined as follows: Initiator Responder Harkins, Carrel [Page 15] INTERNET DRAFT February 1998 ---------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, Ni --> <-- HDR, KE, Nr HDR*, IDii, HASH_I --> <-- HDR*, IDir, HASH_R Aggressive mode with a pre-shared key is described as follows: Initiator Responder ----------- ----------- HDR, SA, KE, Ni, IDii --> <-- HDR, SA, KE, Nr, IDir, HASH_R HDR, HASH_I --> When using pre-shared key authentication with Main Mode the key can only be identified by the IP address of the peers since HASH_I must be computed before the initiator has processed IDir. Aggressive Mode allows for a wider range of identifiers of the pre-shared secret to be used. In addition, Aggressive Mode allows two parties to maintain multiple, different pre-shared keys and identify the correct one for a particular exchange. 5.5 Phase 2 - Quick Mode Quick Mode is not a complete exchange itself, but is used as part of the ISAKMP SA negotiation process (phase 2) to derive keying material and negotiate shared policy for non-ISAKMP SAs. The information exchanged along with Quick Mode MUST be protected by the ISAKMP SA-- i.e. all payloads except the ISAKMP header are encrypted. In Quick Mode, a HASH payload MUST immediately follow the ISAKMP header and a SA payload MUST immediately follow the HASH. This HASH authenticates the message and also provides liveliness proofs. Quick Mode is essentially a SA negotiation and an exchange of nonces that provides replay protection. The nonces are used to generate fresh key material and prevent replay attacks from generating bogus security associations. An optional Key Exchange payload can be exchanged to allow for an additional Diffie-Hellman exchange and exponentiation per Quick Mode. While use of the key exchange payload with Quick Mode is optional it MUST be supported. Base Quick Mode (without the KE payload) refreshes the keying material derived from the exponentiation in phase 1. This does not provide PFS. Using the optional KE payload, an additional exponentiation is performed and PFS is provided for the keying material. Harkins, Carrel [Page 16] INTERNET DRAFT February 1998 If ISAKMP is acting as a client negotiator on behalf of another party the identities of the parties MUST be passed as IDci and then IDcr. Local policy will dictate whether the proposals are acceptible for the identities specified. If IDs are not exchanged, the negotiation MAY assumed to be done on behalf of each ISAKMP peer. If an ID range (see Appendix A of [Pip97]) is not acceptable (for example, the specified subnet is too large) a INVALID-ID-INFORMATION notify message (18) followed by an acceptible ID range, in an ID payload, SHOULD be sent. The client identities are used to identify and direct traffic to the appropriate tunnel in cases where multiple tunnels exist between two peers and also to allow for unique and shared SAs with different granularities. All offers made during a Quick Mode are logically related and must be consistant. For example, if a KE payload is sent, the attribute describing the Diffie-Hellman group (see section 6.1 and [Pip97]) MUST be included in every transform of every proposal of every SA being negotiated. Similarly, if client identities are used, they MUST apply to every SA in the negotiation. Quick Mode is defined as follows: Initiator Responder ----------- ----------- HDR*, HASH(1), SA, Ni [, KE ] [, IDci, IDcr ] --> <-- HDR*, HASH(2), SA, Nr [, KE ] [, IDci, IDcr ] HDR*, HASH(3) --> Where: HASH(1) is the prf over the message id (M-ID) from the ISAKMP header concatenated with the entire message that follows the hash including all payload headers, but excluding any padding added for encryption. HASH(2) is identical to HASH(1) except the initiator's nonce-- Ni, minus the payload header-- is added after M-ID but before the complete message. The addition of the nonce to HASH(2) is for a liveliness proof. 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-- minus the payload header. In other words, the hashes for the above exchange are: HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr ]) HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci | IDcr ]) Harkins, Carrel [Page 17] INTERNET DRAFT February 1998 HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b) With the exception of the HASH, SA, and the optional ID payloads, there are no payload ordering restrictions on Quick Mode. HASH(1) and HASH(2) may differ from the illustration above if the order of payloads in the message differs from the illustrative example. If PFS is not needed, and KE payloads are not exchanged, the new keying material is defined as KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b). If PFS is desired and KE payloads were exchanged, the new keying material is defined as KEYMAT = prf(SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | Nr_b) where g(qm)^xy is the shared secret from the ephemeral Diffie-Hellman exchange of this Quick Mode. In either case, "protocol" and "SPI" are from the ISAKMP Proposal Payload that contained the negotiated Transform. A single SA negotiation results in two security assocations-- one inbound and one outbound. Different SPIs for each SA (one chosen by the initiator, the other by the responder) guarantee a different key for each direction. The SPI chosen by the destination of the SA is used to derive KEYMAT for that SA. For situations where the amount of keying material desired is greater than that supplied by the prf, KEYMAT is expanded by feeding the results of the prf back into itself and concatenating results until the required keying material has been reached. In other words, KEYMAT = K1 | K2 | K3 | ... where K1 = prf(SKEYID_d, [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b) K2 = prf(SKEYID_d, K1 | [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b) K3 = prf(SKEYID_d, K2 | [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b) etc. This keying material (whether with PFS or without, and whether derived directly or through concatenation) MUST be used with the negotiated SA. It is up to the service to define how keys are derived from the keying material. Harkins, Carrel [Page 18] INTERNET DRAFT February 1998 In the case of an ephemeral Diffie-Hellman exchange in Quick Mode, the exponential (g(qm)^xy) is irretreivably removed from the current state and SKEYID_e and SKEYID_a (derived from phase 1 negotiation) continue to protect and authenticate the ISAKMP SA and SKEYID_d continues to be used to derive keys. Using Quick Mode, multiple SA's and keys can be negotiated with one exchange as follows: Initiator Responder ----------- ----------- HDR*, HASH(1), SA0, SA1, Ni, [, KE ] [, IDci, IDcr ] --> <-- HDR*, HASH(2), SA0, SA1, Nr, [, KE ] [, IDci, IDcr ] HDR*, HASH(3) --> The keying material is derived identically as in the case of a single SA. In this case (negotiation of two SA payloads) the result would be four security associations-- two each way for both SAs. 5.6 New Group Mode New Group Mode MUST NOT be used prior to establishment of an ISAKMP SA. The description of a new group MUST only follow phase 1 negotiation. (It is not a phase 2 exchange, though). Initiator Responder ----------- ----------- HDR*, HASH(1), SA --> <-- HDR*, HASH(2), SA where HASH(1) is the prf output, using SKEYID_a as the key, and the message-ID from the ISAKMP header concatenated with the entire SA proposal, body and header, as the data; HASH(2) is the prf output, using SKEYID_a as the key, and the message-ID from the ISAKMP header concatenated with the reply as the data. In other words the hashes for the above exchange are: HASH(1) = prf(SKEYID_a, M-ID | SA) HASH(2) = prf(SKEYID_a, M-ID | SA) The proposal will specify the characteristics of the group (see appendix A, "Attribute Assigned Numbers"). Group descriptions for private Groups MUST be greater than or equal to 2^15. If the group is not acceptable, the responder MUST reply with a Notify payload with the message type set to ATTRIBUTES-NOT-SUPPORTED (13). Harkins, Carrel [Page 19] INTERNET DRAFT February 1998 ISAKMP implementations MAY require private groups to expire with the SA under which they were established. Groups may be directly negotiated in the SA proposal with Main Mode. To do this the component parts-- for a MODP group, the type, prime and generator; for a EC2N group the type, the Irreducible Polynomial, Group Generator One, Group Generator Two, Group Curve A, Group Curve B and Group Order-- are passed as SA attributes (see Appendix A). Alternately, the nature of the group can be hidden using New Group Mode and only the group identifier is passed in the clear during phase 1 negotiation. 5.7 ISAKMP Informational Exchanges This protocol protects ISAKMP Informational Exchanges when possible. Once the ISAKMP security association has been established (and SKEYID_e and SKEYID_a have been generated) ISAKMP Information Exchanges, when used with this protocol, are as follows: Initiator Responder ----------- ----------- HDR*, HASH(1), N/D --> where N/D is either an ISAKMP Notify Payload or an ISAKMP Delete Payload and HASH(1) is the prf output, using SKEYID_a as the key, and a M-ID unique to this exchange concatenated with the entire informational payload (either a Notify or Delete) as the data. In other words, the hash for the above exchange is: HASH(1) = prf(SKEYID_a, M-ID | N/D) As noted the message ID in the ISAKMP header-- and used in the prf computation-- is unique to this exchange and MUST NOT be the same as the message ID of another phase 2 exchange which generated this informational exchange. The derivation of the initialization vector, used with SKEYID_e to encrypt this message, is described in Appendix B. If the ISAKMP security association has not yet been established at the time of the Informational Exchange, the exchange is done in the clear without an accompanying HASH payload. 6 Oakley Groups With IKE, the group in which to do the Diffie-Hellman exchange is negotiated. Four groups-- values 1 through 4-- are defined below. These groups originated with the Oakley protocol and are therefore called "Oakley Groups". The attribute class for "Group" is defined in Harkins, Carrel [Page 20] INTERNET DRAFT February 1998 Appendix A. All values 2^15 and higher are used for private group identifiers. For a discussion on the strength of the default Oakley groups please see the Security Considerations section below. 6.1 First Oakley Default Group Oakley implementations MUST support a MODP group with the following prime and generator. This group is assigned id 1 (one). The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } Its hexadecimal value is FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF The generator is: 2. 6.2 Second Oakley Group IKE implementations SHOULD support a MODP group with the following prime and generator. This group is assigned id 2 (two). The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. Its hexadecimal value is FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 FFFFFFFF FFFFFFFF The generator is 2 (decimal) 6.3 Third Oakley Group IKE implementations SHOULD support a EC2N group with the following characteristics. This group is assigned id 3 (three). The curve is based on the Galois Field GF[2^155]. The field size is 155. The irreducible polynomial for the field is: u^155 + u^62 + 1. The equation for the elliptic curve is: y^2 + xy = x^3 + ax^2 + b. Field Size: 155 Group Prime/Irreducible Polynomial: Harkins, Carrel [Page 21] INTERNET DRAFT February 1998 0x0800000000000000000000004000000000000001 Group Generator One: 0x7b Group Curve A: 0x0 Group Curve B: 0x07338f Group Order: 0X0800000000000000000057db5698537193aef944 The data in the KE payload when using this group is the value x from the solution (x,y), the point on the curve chosen by taking the randomly chosen secret Ka and computing Ka*P, where * is the repetition of the group addition and double operations, P is the curve point with x coordinate equal to generator 1 and the y coordinate determined from the defining equation. The equation of curve is implicitly known by the Group Type and the A and B coefficients. There are two possible values for the y coordinate; either one can be used successfully (the two parties need not agree on the selection). 6.4 Fourth Oakley Group IKE implementations SHOULD support a EC2N group with the following characteristics. This group is assigned id 4 (four). The curve is based on the Galois Field GF[2^185]. The field size is 185. The irreducible polynomial for the field is: u^185 + u^69 + 1. The equation for the elliptic curve is: y^2 + xy = x^3 + ax^2 + b. Field Size: 185 Group Prime/Irreducible Polynomial: 0x020000000000000000000000000000200000000000000001 Group Generator One: 0x18 Group Curve A: 0x0 Group Curve B: 0x1ee9 Group Order: 0X01ffffffffffffffffffffffdbf2f889b73e484175f94ebc The data in the KE payload when using this group will be identical to that as when using Oakley Group 3 (three). Other groups can be defined using New Group Mode. These default groups were generated by Richard Schroeppel at the University of Arizona. Properties of these primes are described in [Orm96]. 7. Payload Explosion for a Complete IKE Exchange This section illustrates how the IKE protocol is used to: Harkins, Carrel [Page 22] INTERNET DRAFT February 1998 - establish a secure and authenticated channel between ISAKMP processes (phase 1); and - generate key material for, and negotiate, an IPsec SA (phase 2). Harkins, Carrel [Page 23] INTERNET DRAFT February 1998 7.1 Phase 1 using Main Mode The following diagram illustrates the payloads exchanged between the two parties in the first round trip exchange. The initiator MAY propose several proposals; the responder MUST reply with one. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ISAKMP Header with XCHG of Main Mode, ~ ~ and Next Payload of ISA_SA ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Domain of Interpretation ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Situation ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Proposal #1 ! PROTO_ISAKMP ! SPI size = 0 | # Transforms ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_TRANS ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Transform #1 ! KEY_OAKLEY | RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ prefered SA attributes ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Transform #2 ! KEY_OAKLEY | RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ alternate SA attributes ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The responder replies in kind but selects, and returns, one transform proposal (the ISAKMP SA attributes). Harkins, Carrel [Page 24] INTERNET DRAFT February 1998 The second exchange consists of the following payloads: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ISAKMP Header with XCHG of Main Mode, ~ ~ and Next Payload of ISA_KE ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_NONCE ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ D-H Public Value (g^xi from initiator g^xr from responder) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Ni (from initiator) or Nr (from responder) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The shared keys, SKEYID_e and SKEYID_a, are now used to protect and authenticate all further communication. Note that both SKEYID_e and SKEYID_a are unauthenticated. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ISAKMP Header with XCHG of Main Mode, ~ ~ and Next Payload of ISA_ID and the encryption bit set ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_SIG ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Identification Data of the ISAKMP negotiator ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ signature verified by the public key of the ID above ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The key exchange is authenticated over a signed hash as described in section 5.1. Once the signature has been verified using the authentication algorithm negotiated as part of the ISAKMP SA, the shared keys, SKEYID_e and SKEYID_a can be marked as authenticated. (For brevity, certificate payloads were not exchanged). 7.2 Phase 2 using Quick Mode The following payloads are exchanged in the first round of Quick Mode with ISAKMP SA negotiation. In this hypothetical exchange, the ISAKMP negotiators are proxies for other parties which have requested authentication. Harkins, Carrel [Page 25] INTERNET DRAFT February 1998 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ISAKMP Header with XCHG of Quick Mode, ~ ~ Next Payload of ISA_HASH and the encryption bit set ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_SA ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ keyed hash of message ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_NONCE ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Domain Of Interpretation ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Situation ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Proposal #1 ! PROTO_IPSEC_AH! SPI size = 4 | # Transforms ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SPI (4 octets) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_TRANS ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Transform #1 ! AH_SHA | RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! other SA attributes ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Transform #2 ! AH_MD5 | RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! other SA attributes ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_ID ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ nonce ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_ID ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ID of source for which ISAKMP is a client ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ID of destination for which ISAKMP is a client ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where the contents of the hash are described in 5.5 above. The responder replies with a similar message which only contains one Harkins, Carrel [Page 26] INTERNET DRAFT February 1998 transform-- the selected AH transform. Upon receipt, the initiator can provide the key engine with the negotiated security association and the keying material. As a check against replay attacks, the responder waits until receipt of the next message. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ISAKMP Header with XCHG of Quick Mode, ~ ~ Next Payload of ISA_HASH and the encryption bit set ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ hash data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where the contents of the hash are described in 5.5 above. 8 Perfect Forward Secrecy Example This protocol can provide PFS of both keys and identities. The identies of both the ISAKMP negotiating peer and, if applicable, the identities for whom the peers are negotiating can be protected with PFS. To provide Perfect Forward Secrecy of both keys and all identities, two parties would perform the following: o A Main Mode Exchange to protect the identities of the ISAKMP peers. This establishes an ISAKMP SA. o A Quick Mode Exchange to negotiate other security protocol protection. This establishes a SA on each end for this protocol. o Delete the ISAKMP SA and its associated state. Since the key for use in the non-ISAKMP SA was derived from the single ephemeral Diffie-Hellman exchange PFS is preserved. To provide Perfect Forward Secrecy of merely the keys of a non-ISAKMP security association, it in not necessary to do a phase 1 exchange if an ISAKMP SA exists between the two peers. A single Quick Mode in which the optional KE payload is passed, and an additional Diffie- Hellman exchange is performed, is all that is required. At this point the state derived from this Quick Mode must be deleted from the ISAKMP SA as described in section 5.5. Harkins, Carrel [Page 27] INTERNET DRAFT February 1998 9. Implementation Hints Using a single ISAKMP Phase 1 negotiation makes subsequent Phase 2 negotiations extremely quick. As long as the Phase 1 state remains cached, and PFS is not needed, Phase 2 can proceed without any exponentiation. How many Phase 2 negotiations can be performed for a single Phase 1 is a local policy issue. The decision will depend on the strength of the algorithms being used and level of trust in the peer system. An implementation may wish to negotiate a range of SAs when performing Quick Mode. By doing this they can speed up the "re- keying". Quick Mode defines how KEYMAT is defined for a range of SAs. When one peer feels it is time to change SAs they simply use the next one within the stated range. A range of SAs can be established by negotiating multiple SAs (identical attributes, different SPIs) with one Quick Mode. An optimization that is often useful is to establish Security Associations with peers before they are needed so that when they become needed they are already in place. This ensures there would be no delays due to key management before initial data transmission. This optimization is easily implemented by setting up more than one Security Association with a peer for each requested Security Association and caching those not immediately used. Also, if an ISAKMP implementation is alerted that a SA will soon be needed (e.g. to replace an existing SA that will expire in the near future), then it can establish the new SA before that new SA is needed. The base ISAKMP specification describes conditions in which one party of the protocol may inform the other party of some activity-- either deletion of a security association or in response to some error in the protocol such as a signature verification failed or a payload failed to decrypt. It is strongly suggested that these Informational exchanges not be responded to under any circumstances. Such a condition may result in a "notify war" in which failure to understand a message results in a notify to the peer who cannot understand it and sends his own notify back which is also not understood. 10. Security Considerations This entire draft discusses a hybrid protocol, combining parts of Oakley and parts of SKEME with ISAKMP, to negotiate, and derive keying material for, security associations in a secure and authenticated manner. Harkins, Carrel [Page 28] INTERNET DRAFT February 1998 Confidentiality is assured by the use of a negotiated encryption algorithm. Authentication is assured by the use of a negotiated method: a digital signature algorithm; a public key algorithm which supports encryption; or, a pre-shared key. The confidentiality and authentication of this exchange is only as good as the attributes negotiated as part of the ISAKMP security association. Repeated re-keying using Quick Mode can consume the entropy of the Diffie- Hellman shared secret. Implementors should take note of this fact and set a limit on Quick Mode Exchanges between exponentiations. This draft does not prescribe such a limit. Perfect Forward Secrecy (PFS) of both keying material and identities is possible with this protocol. By specifying a Diffie-Hellman group, and passing public values in KE payloads, ISAKMP peers can establish PFS of keys-- the identities would be protected by SKEYID_e from the ISAKMP SA and would therefore not be protected by PFS. If PFS of both keying material and identities is desired, an ISAKMP peer MUST establish only one non-ISAKMP security association (e.g. IPsec Security Association) per ISAKMP SA. PFS for keys and identities is accomplished by deleting the ISAKMP SA (and optionally issuing a DELETE message) upon establishment of the single non-ISAKMP SA. In this way a phase one negotiation is uniquely tied to a single phase two negotiation, and the ISAKMP SA established during phase one negotiation is never used again. The strength of a key derived from a Diffie-Hellman exchange using any of the groups defined here depends on the inherent strength of the group, the size of the exponent used, and the entropy provided by the random number generator used. Due to these inputs it is difficult to determine the strength of a key for any of the defined groups. The default Diffie-Hellman group (number one) when used with a strong random number generator and an exponent no less than 160 bits is sufficient to use for DES. Groups two through four provide greater security. Implementations should make note of these conservative estimates when establishing policy and negotiating security parameters. Note that these limitations are on the Diffie-Hellman groups themselves. There is nothing in IKE which prohibits using stronger groups nor is there anything which will dilute the strength obtained from stronger groups. In fact, the extensible framework of IKE encourages the definition of more groups; use of elliptical curve groups will greatly increase strength using much smaller numbers. For situations where defined groups provide insufficient strength New Group Mode can be used to exchange a Diffie-Hellman group which provides the necessary strength. In is incumbent upon implementations Harkins, Carrel [Page 29] INTERNET DRAFT February 1998 to check the primality in groups being offered and independently arrive at strength estimates. It is assumed that the Diffie-Hellman exponents in this exchange are erased from memory after use. In particular, these exponents must not be derived from long-lived secrets like the seed to a pseudo-random generator. 11. IANA Considerations This document contains many "magic numbers" to be maintained by the IANA. This section explains the criteria to be used by the IANA to assign additional numbers in each of these lists. 11.1 Attribute Classes Attributes negotiated in this protocol are identified by their class. Requests for assignment of new classes must be accompanied by a standards- track RFC which describes the use of this attribute. 11.2 Encryption Algorithm Class Values of the Encryption Algorithm Class define an encryption algorithm to use when called for in this document. Requests for assignment of new encryption algorithm values must be accompanied by a reference to a standards-track or Informational RFC or a reference to published cryptographic literature which describes this algorithm. 11.3 Hash Algorithm Values of the Hash Algorithm Class define a hash algorithm to use when called for in this document. Requests for assignment of new hash algorithm values must be accompanied by a reference to a standards- track or Informational RFC or a reference to published cryptographic literature which describes this algorithm. 11.4 Group Description and Group Type Values of the Group Description Class identify a group to use in a Diffie-Hellman exchange. Values of the Group Type Class define the type of group. Requests for assignment of new groups must be accompanied by a reference to a standards-track or Informational RFC which describes this group. Requests for assignment of new group types must be accompanied by a reference to a standards-track or Informational RFC or by a reference to published cryptographic or mathmatical literature which describes the new type. 11.5 Life Type Values of the Life Type Class define a type of lifetime to which the ISAKMP Security Association applies. Requests for assignment of new life types must be accompanied by a detailed description of the units of this type and its expiry. 12. Acknowledgements This document is the result of close consultation with Hugo Krawczyk, Douglas Maughan, Hilarie Orman, Mark Schertler, Mark Schneider, and Jeff Turner. It relies on protocols which were written by them. Harkins, Carrel [Page 30] INTERNET DRAFT February 1998 Without their interest and dedication, this would not have been written. Special thanks Rob Adams, Cheryl Madson, Derrell Piper, Harry Varnis, and Elfed Weaver for technical input, encouragement, and various sanity checks along the way. We would also like to thank the many members of the IPSec working group that contributed to the development of this protocol over the past year. 13. References [Acm97] Adams, C.M., "The CAST-128 Encryption Algorithm", RFC 2144, May 1997. [Bra97] Bradner, S., "Key Words for use in RFCs to indicate Requirement Levels", RFC2119, March 1997. [KBC96] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [Kra96] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange Mechanism for Internet", from IEEE Proceedings of the 1996 Symposium on Network and Distributed Systems Security. [MSST98] Maughhan, D., Schertler, M., Schneider, M., and Turner, J., "Internet Security Association and Key Management Protocol (ISAKMP)", version 9, draft-ietf-ipsec-isakmp-09.{ps,txt}. [Orm96] Orman, H., "The Oakley Key Determination Protocol", version 2, draft-ietf-ipsec-oakley-02.txt [Pip98] Piper, D., "The Internet IP Security Domain Of Interpretation for ISAKMP", version 7, draft-ietf-ipsec-ipsec-doi-07.txt. [Sch96] Schneier, B., "Applied Cryptography, Protocols, Algorithms, and Source Code in C", 2nd edition. Harkins, Carrel [Page 31] INTERNET DRAFT February 1998 Appendix A This is a list of DES Weak and Semi-Weak keys. The keys come from [Sch96]. All keys are listed in hexidecimal. DES Weak Keys 0101 0101 0101 0101 1F1F 1F1F E0E0 E0E0 E0E0 E0E0 1F1F 1F1F FEFE FEFE FEFE FEFE DES Semi-Weak Keys 01FE 01FE 01FE 01FE 1FE0 1FE0 0EF1 0EF1 01E0 01E0 01F1 01F1 1FFE 1FFE 0EFE 0EFE 011F 011F 010E 010E E0FE E0FE F1FE F1FE FE01 FE01 FE01 FE01 E01F E01F F10E F10E E001 E001 F101 F101 FE1F FE1F FE0E FE0E 1F01 1F01 0E01 0E01 FEE0 FEE0 FEF1 FEF1 Attribute Assigned Numbers Attributes negotiated during phase one use the following definitions. Phase two attributes are defined in the applicable DOI specification (for example, IPsec attributes are defined in the IPsec DOI), with the exception of a group description when Quick Mode includes an ephemeral Diffie-Hellman exchange. Attribute types can be either Basic (B) or Variable-length (V). Encoding of these attributes is defined in the base ISAKMP specification as Type/Value (Basic) and Type/Length/Value (Variable). Attributes described as basic MUST NOT be encoded as variable. Variable length attributes MAY be encoded as basic attributes if their value can fit into two octets. If this is the case, an attribute offered as variable (or basic) by the initiator of this protocol MAY be returned to the initiator as a basic (or variable). Harkins, Carrel [Page 32] INTERNET DRAFT February 1998 Attribute Classes class value type ------------------------------------------------------------------- Encryption Algorithm 1 B Hash Algorithm 2 B Authentication Method 3 B Group Description 4 B Group Type 5 B Group Prime/Irreducible Polynomial 6 V Group Generator One 7 V Group Generator Two 8 V Group Curve A 9 V Group Curve B 10 V Life Type 11 B Life Duration 12 V PRF 13 B Key Length 14 B Field Size 15 B Group Order 16 V values 17-16383 are reserved to IANA. Values 16384-32767 are for private use among mutually consenting parties. Class Values - Encryption Algorithm DEC-CBC 1 IDEA-CBC 2 Blowfish-CBC 3 RC5-R16-B64-CBC 4 3DES-CBC 5 CAST-CBC 6 values 7-65000 are reserved to IANA. Values 65001-65535 are for private use among mutually consenting parties. - Hash Algorithm MD5 1 SHA 2 Tiger 3 values 4-65000 are reserved to IANA. Values 65001-65535 are for private use among mutually consenting parties. - Authentication Method pre-shared key 1 DSS signatures 2 Harkins, Carrel [Page 33] INTERNET DRAFT February 1998 RSA signatures 3 Encryption with RSA 4 Revised encryption with RSA 5 values 6-65000 are reserved to IANA. Values 65001-65535 are for private use among mutually consenting parties. - Group Description default 768-bit MODP group (section 6.1) 1 alternate 1024-bit MODP group (section 6.2) 2 .sp EC2N group on GP[2^155] (section 6.3) 3 .sp EC2N group on GP[2^185] (section 6.4) 4 values 5-32767 are reserved to IANA. Values 32768-65535 are for private use among mutually consenting parties. - Group Type MODP (modular exponentiation group) 1 ECP (elliptic curve group over GF[P]) 2 EC2N (elliptic curve group over GF[2^N]) 3 values 4-65000 are reserved to IANA. Values 65001-65535 are for private use among mutually consenting parties. - Life Type seconds 1 kilobytes 2 values 3-65000 are reserved to IANA. Values 65001-65535 are for private use among mutually consenting parties. For a given "Life Type" the value of the "Life Duration" attribute defines the actual length of the SA life-- either a number of seconds, or a number of kbytes protected. - PRF There are currently no pseudo-random functions defined. values 1-65000 are reserved to IANA. Values 65001-65535 are for private use among mutually consenting parties. - Key Length When using an Encryption Algorithm that has a variable length key, this attribute specifies the key length in bits. (MUST use network byte order). This attribute MUST NOT be used when the specified Harkins, Carrel [Page 34] INTERNET DRAFT February 1998 Encryption Algorithm uses a fixed length key. - Field Size The field size, in bits, of a Diffie-Hellman group. - Group Order The group order of an elliptical curve group. Note the length of this attribute depends on the field size. Additional Exchanges Defined-- XCHG values Quick Mode 32 New Group Mode 33 Harkins, Carrel [Page 35] INTERNET DRAFT February 1998 Appendix B This appendix describes encryption details to be used ONLY when encrypting ISAKMP messages. When a service (such as an IPSEC transform) utilizes ISAKMP to generate keying material, all encryption algorithm specific details (such as key and IV generation, padding, etc...) MUST be defined by that service. ISAKMP does not purport to ever produce keys that are suitable for any encryption algorithm. ISAKMP produces the requested amount of keying material from which the service MUST generate a suitable key. Details, such as weak key checks, are the responsibility of the service. Use of negotiated PRFs may require the PRF output to be expanded due to the PRF feedback mechanism employed by this document. For example, if the (ficticious) DOORAK-MAC requires 24 bytes of key but produces only 8 bytes of output, the output must be expanded three times before being used as the key for another instance of itself. The output of a PRF is expanded by feeding back the results of the PRF into itself to generate successive blocks. These blocks are concatenated until the requisite number of bytes has been acheived. For example, for pre-shared key authentication with DOORAK-MAC as the negotiated PRF: BLOCK1-8 = prf(pre-shared-key, Ni_b | Nr_b) BLOCK9-16 = prf(pre-shared-key, BLOCK1-8 | Ni_b | Nr_b) BLOCK17-24 = prf(pre-shared-key, BLOCK9-16 | Ni_b | Nr_b) and SKEYID = BLOCK1-8 | BLOCK9-16 | BLOCK17-24 so therefore to derive SKEYID_d: BLOCK1-8 = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) BLOCK9-16 = prf(SKEYID, BLOCK1-8 | g^xy | CKY-I | CKY-R | 0) BLOCK17-24 = prf(SKEYID, BLOCK9-16 | g^xy | CKY-I | CKY-R | 0) and SKEYID_d = BLOCK1-8 | BLOCK9-16 | BLOCK17-24 Subsequent PRF derivations are done similarly. Encryption keys used to protect the ISAKMP SA are derived from SKEYID_e in an algorithm-specific manner. When SKEYID_e is not long enough to supply all the necessary keying material an algorithm requires, the key is derived from feeding the results of a pseudo- random function into itself, concatenating the results, and taking the highest necessary bits. For example, if (ficticious) algorithm AKULA requires 320-bits of key (and has no weak key check) and the prf used to generate SKEYID_e Harkins, Carrel [Page 36] INTERNET DRAFT February 1998 only generates 120 bits of material, the key for AKULA, would be the first 320-bits of Ka, where: Ka = K1 | K2 | K3 and K1 = prf(SKEYID_e, 0) K2 = prf(SKEYID_e, K1) K3 = prf(SKEYID_e, K2) where prf is the negotiated prf or the HMAC version of the negotiated hash function (if no prf was negotiated) and 0 is represented by a single octet. Each result of the prf provides 120 bits of material for a total of 360 bits. AKULA would use the first 320 bits of that 360 bit string. In phase 1, material for the initialization vector (IV material) for CBC mode encryption algorithms is derived from a hash of a concatenation of the initiator's public Diffie-Hellman value and the responder's public Diffie-Hellman value using the negotiated hash algorithm. This is used for the first message only. Each message should be padded up to the nearest block size using bytes containing 0x00. The message length in the header MUST include the length of the pad since this reflects the size of the cyphertext. Subsequent messages MUST use the last CBC encryption block from the previous message as their initialization vector. In phase 2, material for the initialization vector for CBC mode encryption of the first message of a Quick Mode exchange is derived from a hash of a concatenation of the last phase 1 CBC output block and the phase 2 message id using the negotiated hash algorithm. The IV for subsequent messages within a Quick Mode exchange is the CBC output block from the previous message. Padding and IVs for subsequent messages are done as in phase 1. After the ISAKMP SA has been authenticated all Informational Exchanges are encrypted using SKEYID_e. The initiaization vector for these exchanges is derived in exactly the same fashion as that for a Quick Mode-- i.e. it is derived from a hash of a concatenation of the last phase 1 CBC output block and the message id from the ISAKMP header of the Informational Exchange (not the message id from the message that may have prompted the Informational Exchange). Note that the final phase 1 CBC output block, the result of encryption/decryption of the last phase 1 message, must be retained in the ISAKMP SA state to allow for generation of unique IVs for each Quick Mode. Each post- phase 1 exchange (Quick Modes and Informational Exchanges) generates IVs independantly to prevent IVs from getting out of sync when two different exchanges are started Harkins, Carrel [Page 37] INTERNET DRAFT February 1998 simultaneously. In all cases, there is a single bidirectional cipher/IV context. Having each Quick Mode and Informational Exchange maintain a unique context prevents IVs from getting out of sync. The key for DES-CBC is derived from the first eight (8) non-weak and non-semi-weak (see Appendix A) bytes of SKEYID_e. The IV is the first 8 bytes of the IV material derived above. The key for IDEA-CBC is derived from the first sixteen (16) bytes of SKEYID_e. The IV is the first eight (8) bytes of the IV material derived above. The key for Blowfish-CBC is either the negotiated key size, or the first fifty-six (56) bytes of a key (if no key size is negotiated) derived in the aforementioned pseudo-random function feedback method. The IV is the first eight (8) bytes of the IV material derived above. The key for RC5-R16-B64-CBC is the negotiated key size, or the first sixteen (16) bytes of a key (if no key size is negotiated) derived from the aforementioned pseudo-random function feedback method if necessary. The IV is the first eight (8) bytes of the IV material derived above. The number of rounds MUST be 16 and the block size MUST be 64. The key for 3DES-CBC is the first twenty-four (24) bytes of a key derived in the aforementioned pseudo-random function feedback method. 3DES-CBC is an encrypt-decrypt-encrypt operation using the first, middle, and last eight (8) bytes of the entire 3DES-CBC key. The IV is the first eight (8) bytes of the IV material derived above. The key for CAST-CBC is either the negotiated key size, or the first sixteen (16) bytes of a key derived in the aforementioned pseudo- random function feedback method. The IV is the first eight (8) bytes of the IV material derived above. Support for algorithms other than DES-CBC is purely optional. Some optional algorithms may be subject to intellectual property claims. Harkins, Carrel [Page 38] INTERNET DRAFT February 1998 Authors' Addresses: Dan Harkins cisco Systems 170 W. Tasman Dr. San Jose, California, 95134-1706 United States of America +1 408 526 4000 Dave Carrel 76 Lippard Ave. San Francisco, CA 94131-2947 United States of America +1 415 337 8469 Authors' Note: The authors encourage independent implementation, and interoperability testing, of this hybrid protocol. Harkins, Carrel [Page 39] -- John Kelley johnk@tis.com Director, Systems Administration Trusted Information Systems, Inc. (A NASDAQ company: "TISX") http://www.tis.com From owner-ipsec Mon Feb 16 17:08:31 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA23856 for ipsec-outgoing; Mon, 16 Feb 1998 17:07:01 -0500 (EST) Message-Id: <199802162207.RAA23856@portal.ex.tis.com> Date: Mon, 16 Feb 1998 06:22:41 -0500 To: Engineering , Daniel Harkins From: Robert Moskowitz Subject: Re: Help - Details on March 2nd worshop at Raliegh requested ... Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk At 02:03 PM 2/13/98 -0600, Engineering wrote: >> >> > What about firewall configurations ? >> >Interoperabilty with NAT... That is too broad a statement for a workshop. What senarios and tests would you recommend? Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com -- John Kelley johnk@tis.com Director, Systems Administration Trusted Information Systems, Inc. (A NASDAQ company: "TISX") http://www.tis.com From owner-ipsec Mon Feb 16 17:08:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA23857 for ipsec-outgoing; Mon, 16 Feb 1998 17:07:02 -0500 (EST) Message-Id: <199802162207.RAA23857@portal.ex.tis.com> Date: Fri, 13 Feb 98 15:19:58 EST From: Karen Seo To: internet-drafts@ietf.org cc: tytso@MIT.EDU, rgm-sec@homebase.htt-consult.com, skent@bbn.com, kseo@bbn.com Subject: Internet Draft -- IPsec AH spec Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, Please find attached the Internet Draft for the IPsec AH specification. Thank you, Karen Network Working Group Stephen Kent, BBN Corp Internet Draft Randall Atkinson, @Home Network draft-ietf-ipsec-auth-header-04.txt February 1998 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 IPsec Working Group. 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. Copyright (C) The Internet Society (February 1998). All Rights Reserved. Kent, Atkinson [Page 1] Internet Draft IP Authentication Header February 1998 Table of Contents 1. Introduction......................................................3 2. Authentication Header Format......................................4 2.1 Next Header...................................................4 2.2 Payload Length................................................4 2.3 Reserved......................................................5 2.4 Security Parameters Index (SPI)...............................5 2.5 Sequence Number...............................................5 2.6 Authentication Data ..........................................6 3. Authentication Header Processing..................................6 3.1 Authentication Header Location...............................6 3.2 Authentication Algorithms....................................8 3.3 Outbound Packet Processing...................................8 3.3.1 Security Association Lookup.............................9 3.3.2 Sequence Number Generation..............................9 3.3.3 Integrity Check Value Calculation.......................9 3.3.3.1 Handling Mutable Fields...........................10 3.3.3.1.1 ICV Computation for IPv4.....................10 3.3.3.1.1.1 Base Header Fields.......................10 3.3.3.1.1.2 Options..................................11 3.3.3.1.2 ICV Computation for IPv6.....................11 3.3.3.1.2.1 Base Header Fields.......................11 3.3.3.1.2.2 Extension Headers -- Options.............12 3.3.3.1.2.3 Extension Headers -- non-Options.........12 3.3.3.2 Padding...........................................12 3.3.3.2.1 Authentication Data Padding..................12 3.3.3.2.2 Implicit Packet Padding......................13 3.3.4 Fragmentation..........................................13 3.4 Inbound Packet Processing...................................13 3.4.1 Reassembly.............................................13 3.4.2 Security Association Lookup............................14 3.4.3 Sequence Number Verification...........................14 3.4.4 Integrity Check Value Verification.....................15 4. Auditing.........................................................16 5. Conformance Requirements.........................................16 6. Security Considerations..........................................17 7. Differences from RFC 1826........................................17 Acknowledgements....................................................17 Appendix A -- Mutability of IP Options/Extension Headers............19 A1. IPv4 Options.................................................19 A2. IPv6 Extension Headers.......................................20 References..........................................................22 Disclaimer..........................................................22 Author Information..................................................22 Kent, Atkinson [Page 2] Internet Draft IP Authentication Header February 1998 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, by the receiver, when a Security Association is established. (Although the default calls for the sender to increment the Sequence Number used for anti-replay, the service is effective only if the receiver checks the Sequence Number.) 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 sender. 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 "Security Architecture for the Internet Protocol" [KA97a], hereafter referred to as the Security Architecture document). 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 a confidentiality (encryption) service. The primary difference between the authentication provided by ESP and AH is the extent of the coverage. Specifically, ESP does not protect any IP header fields unless those fields are encapsulated by ESP (tunnel mode). For more details on how to use AH and ESP in various network environments, see the Security Architecture document [KA97a]. It is assumed that the reader is familiar with the terms and concepts described in the Security Architecture document. In particular, the reader should be familiar with the definitions of security services offered by AH and ESP, the concept of Security Associations, the ways in which AH can be used in conjunction with ESP, and the different key management options available for AH and ESP. (With regard to the last topic, the current key management options required for both AH and ESP are manual keying and automated keying via ISAKMP/Oakley.) The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [Bra97]. Kent, Atkinson [Page 3] Internet Draft IP Authentication Header February 1998 2. Authentication Header Format The protocol header (IPv4, IPv6, or Extension) immediately preceding the AH header will contain the value 51 in its Protocol (IPv4) or Next Header (IPv6, Extension) field [STD-2]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Payload Len | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Authentication Data (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following subsections define the fields that comprise the AH format. All the fields described here are mandatory, i.e., they are always present in the AH format and are included in the Integrity Check Value (ICV) computation (see Sections 2.6 and 3.3.3). 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). 2.2 Payload Length This 8-bit field specifies the length of AH in 32-bit words (4-byte units), minus "2". (All IPv6 extension headers, as per RFC 1883, encode the "Hdr Ext Len" field by first subtracting 1 (64-bit word) from the header length (measured in 64-bit words). AH is an IPv6 extension header. However, since its length is measured in 32-bit words, the "Payload Length" is calculated by subtracting 2 (32 bit words).) In the "standard" case of a 96-bit authentication value plus the 3 32-bit word fixed portion, this length field will be "4". A "null" authentication algorithm may be used only for debugging purposes. Its use would result in a "1" value for this field for IPv4 or a "2" for IPv6, as there would be no corresponding Authentication Data field (see Section 3.3.3.2.1 on "Authentication Kent, Atkinson [Page 4] Internet Draft IP Authentication Header February 1998 Data Padding"). 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.) 2.4 Security Parameters Index (SPI) The SPI is an arbitrary 32-bit value that, in combination with the destination IP address and security protocol (AH), uniquely identifies the Security Association for this datagram. 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. It is ordinarily selected by the destination system upon establishment of an SA (see the Security Architecture document for more details). The SPI value of zero (0) is reserved for local, implementation- specific use and MUST NOT be sent on the wire. For example, a key management implementation MAY use the zero SPI value to mean "No Security Association Exists" during the period when the IPsec implementation has requested that its key management entity establish a new SA, but the SA has not yet been established. 2.5 Sequence Number This unsigned 32-bit field contains a monotonically increasing counter value (sequence number). It is mandatory and is always present even if the receiver does not elect to enable the anti-replay service for a specific SA. Processing of the Sequence Number field is at the discretion of the receiver, i.e., the sender MUST always transmit this field, but the receiver need not act upon it (see the discussion of Sequence Number Verification in the "Inbound Packet Processing" section below). The sender's counter and the receiver's counter are initialized to 0 when an SA is established. (The first packet sent using a given SA will have a Sequence Number of 1; see Section 3.3.2 for more details on how the Sequence Number is generated.) If anti-replay is enabled (the default), the transmitted Sequence Number must never be allowed to cycle. Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA. Kent, Atkinson [Page 5] Internet Draft IP Authentication Header February 1998 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.3.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 below. The authentication algorithm specification MUST specify the length of the ICV and the comparison rules and processing steps for validation. 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, note that for "bump-in- the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document, inbound and outbound IP fragments may require an IPsec implementation to perform extra IP reassembly/fragmentation in order to both conform to this specification and provide transparent IPsec support. Special care is required to perform such operations within these implementations when multiple interfaces are in use.) In transport mode, AH is inserted after the IP header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other IPsec headers that have already been inserted. 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. Kent, Atkinson [Page 6] Internet Draft IP Authentication Header February 1998 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. BEFORE APPLYING AH --------------------------------------- IPv6 | | ext hdrs | | | | orig IP hdr |if present| TCP | Data | --------------------------------------- AFTER APPLYING AH ------------------------------------------------------------ IPv6 | |hop-by-hop, dest*, | | dest | | | |orig IP hdr |routing, fragment. | AH | opt* | TCP | Data | ------------------------------------------------------------ |<---- authenticated except for mutable fields ----------->| * = if present, could be before AH, after AH, or both ESP and AH headers can be combined in a variety of modes. The IPsec Architecture document describes the combinations of security associations that must be supported. Tunnel mode AH may be employed in either hosts or security gateways (or in so-called "bump-in-the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document). When AH is implemented in a security gateway (to protect 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 Kent, Atkinson [Page 7] Internet Draft IP Authentication Header February 1998 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 -->| | in the new IP hdr | -------------------------------------------------------------- IPv6 | | ext hdrs*| | | ext hdrs*| | | |new IP hdr*|if present| AH |orig IP hdr*|if present|TCP|Data| -------------------------------------------------------------- |<-- authenticated except for mutable fields in new IP hdr ->| * = construction of outer IP hdr/extensions and modification of inner IP hdr/extensions is discussed below. 3.2 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 appropriate, though performance and space considerations currently preclude use of such algorithms. The mandatory-to-implement authentication algorithms are described in Section 5 "Conformance Requirements". Other algorithms MAY be supported. 3.3 Outbound Packet Processing In transport mode, the sender 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 Security Architecture document. If there is more than one IPsec header/extension required, the order of the application of the security headers MUST be defined by security policy. For simplicity of processing, each IPsec header Kent, Atkinson [Page 8] Internet Draft IP Authentication Header February 1998 SHOULD ignore the existence (i.e., not zero the contents or try to predict the contents) of IPsec headers to be applied later. (While a native IP or bump-in-the-stack implementation could predict the contents of later IPsec headers that it applies itself, it won't be possible for it to predict any IPsec headers added by a bump-in-the- wire implementation between the host and the network.) 3.3.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 Security Architecture document. 3.3.2 Sequence Number Generation The sender's counter is initialized to 0 when an SA is established. The sender increments the Sequence Number for this SA and inserts the new value into the Sequence Number Field. Thus the first packet sent using a given SA will have a Sequence Number of 1. If anti-replay is enabled (the default), the sender checks to ensure that the counter has not cycled before inserting the new value in the Sequence Number field. In other words, the sender MUST not send a packet on an SA if doing so would cause the Sequence Number to cycle. An attempt to transmit a packet that would result in Sequence Number overflow is an auditable event. (Note that this approach to Sequence Number management does not require use of modular arithmetic.) If anti-replay has been disabled, the sender does not need to monitor or reset the counter, e.g., in the case of manual key management. 3.3.3 Integrity Check Value Calculation The AH ICV is computed over: o IP header fields that are either immutable in transit or that are predictable in value upon arrival at the endpoint for the AH SA o the AH header (Next Header, Payload Len, Reserved, SPI, Sequence Number, and the Authentication Data (which is set to zero for this computation)) o the upper level protocol data, which is assumed to be immutable in transit Kent, Atkinson [Page 9] Internet Draft IP Authentication Header February 1998 3.3.3.1 Handling Mutable Fields If a field may be 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 is also 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. Also, the zero-fill approach ensures that the length of the fields that are so handled cannot be changed during transit, even though their contents are not explicitly covered by the ICV. As a new extension header or IPv4 option is created, it will be defined in its own RFC and SHOULD include (in the Security Considerations section) directions for how it should be handled when calculating the AH ICV. If the IPsec implementation encounters an extension header that it does not recognize, it MUST zero the whole header except for the Next Header and Hdr Ext Len fields. The length of the extension header MUST be computed by 8 * Hdr Ext Len value + 8. If the IPsec implementation encounters an IPv4 option that it does not recognize, it should zero the whole option, using the second byte of the option as the length. (IPv6 options contain a flag indicating mutability, which determines appropriate processing for such options.) 3.3.3.1.1 ICV Computation for IPv4 3.3.3.1.1.1 Base Header Fields The IPv4 base header fields are classified as follows: Immutable Version Internet Header Length Total Length Identification Protocol (This should be the value for AH.) Source Address Destination Address (without loose or strict source routing) Mutable but predictable Destination Address (with loose or strict source routing) Kent, Atkinson [Page 10] Internet Draft IP Authentication Header February 1998 Mutable (zeroed prior to ICV calculation) Type of Service (TOS) Flags Fragment Offset Time to Live (TTL) Header Checksum TOS -- This field is excluded 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. Flags -- This field is excluded since an intermediate router might set the DF bit, even if the source did not select it. Fragment Offset -- Since AH is applied only to non-fragmented IP packets, the Offset Field must always be zero, and thus it is excluded (even though it is predictable). TTL -- This is changed en-route as a normal course of processing by routers, and thus its value at the receiver is not predictable by the sender. Header Checksum -- This will change if any of these other fields changes, and thus its value upon reception cannot be predicted by the sender. 3.3.3.1.1.2 Options For IPv4 (unlike IPv6), there is no mechanism for tagging options as mutable in transit. Hence the IPv4 options are explicitly listed in Appendix A and classified as immutable, mutable but predictable, or mutable. For IPv4, the entire option is viewed as a unit; so even though the 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. 3.3.3.1.2 ICV Computation for IPv6 3.3.3.1.2.1 Base Header Fields The IPv6 base header fields are classified as follows: Immutable Version Payload Length Next Header (This should be the value for AH.) Source Address Destination Address (without Routing Extension Header) Kent, Atkinson [Page 11] Internet Draft IP Authentication Header February 1998 Mutable but predictable Destination Address (with Routing Extension Header) Mutable (zeroed prior to ICV calculation) Class Flow Label Hop Limit 3.3.3.1.2.2 Extension Headers -- Options The IPv6 extension headers (that are options) are explicitly listed in Appendix A and classified as immutable, mutable but predictable, or mutable. IPv6 options in the Hop-by-Hop and Destination Extension Headers contain a bit that indicates whether the option might change (unpredictably) 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 options for which the bit indicates immutability are included in the ICV calculation. See the IPv6 specification [DH95] for more information. 3.3.3.1.2.3 Extension Headers -- non-Options The IPv6 extension headers (that are not options) are explicitly listed in Appendix A and classified as immutable, mutable but predictable, or mutable. 3.3.3.2 Padding 3.3.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 two factors: - the length of the ICV - the IP protocol version (v4 or v6) For example, if the output of the selected algorithm is 96-bits, no padding is required for either IPv4 or for IPv6. However, if a different length ICV is generated, due to use of a different algorithm, then padding may be required depending on the length and IP protocol version. The content of the padding field is arbitrarily Kent, Atkinson [Page 12] Internet Draft IP Authentication Header February 1998 selected by the sender. (The padding is arbitrary, but need not be random to achieve security.) These padding 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.3.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. Note that MD5 and SHA-1 are viewed as having a 1-byte blocksize because of their internal padding conventions. 3.3.4 Fragmentation If required, IP fragmentation occurs after AH processing within an IPsec implementation. Thus, transport mode AH is applied only to whole IP datagrams (not to IP fragments). An IP packet to which AH has been applied may itself be fragmented by routers en route, and such fragments must be reassembled prior to AH processing at a receiver. In tunnel mode, AH is applied to an IP packet, the payload of which may be a fragmented IP packet. For example, a security gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation (see the Security Architecture document for details) may apply tunnel mode AH to such fragments. 3.4 Inbound Packet Processing If there is more than one IPsec header/extension present, the processing for each one ignores (does not zero, does not use) any IPsec headers applied subsequent to the header being processed. 3.4.1 Reassembly If required, reassembly is performed prior to AH processing. If a packet offered to AH for processing appears to be an IP fragment, i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID. Kent, Atkinson [Page 13] Internet Draft IP Authentication Header February 1998 NOTE: For packet reassembly, the current IPv4 spec does NOT require either the zero'ing of the OFFSET field or the clearing of the MORE FRAGMENTS flag. In order for a reassembled packet to be processed by IPsec (as opposed to discarded as an apparent fragment), the IP code must do these two things after it reassembles a packet. 3.4.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, security protocol (AH), and the SPI. (This process is described in more detail in the Security Architecture document.) The SA indicates whether the Sequence Number field will be checked, specifies the algorithm(s) employed for ICV computation, and indicates 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; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID. 3.4.3 Sequence Number Verification All AH implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. (Note that there are no provisions for managing transmitted Sequence Number values among multiple senders directing traffic to a single SA (irrespective of whether the destination address is unicast, broadcast, or multicast). Thus the anti-replay service SHOULD NOT be used in a multi-sender environment that employs a single SA.) If the receiver does not enable anti-replay for an SA, no inbound checks are performed on the Sequence Number. The default for the sender is that the Sequence Number will be checked at the sender. Hence, if an SA establishment protocol such as ISAKMP/Oakley is employed, the receiver SHOULD notify the sender, during SA establishment, if the receiver will not provide anti-replay protection. If the receiver has enabled the anti-replay service for this SA, the receiver packet counter for the SA MUST be initialized to zero when the SA is established. For each received packet, 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 14] Internet Draft IP Authentication Header February 1998 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.) A MINIMUM window size of 32 MUST be supported; but a window size of 64 is preferred and SHOULD be employed as the default. Another window size (larger than the MINIMUM) MAY be chosen by the receiver. (The receiver does NOT notify the sender of the window size.) The "right" edge of the window represents the highest, validated Sequence Number 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 the Security Architecture document. If the received packet falls within the window and is new, or if the packet is to the right of the window, then the receiver proceeds to ICV verification. If the ICV validation fails, the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, the Sequence Number, and (in IPv6) the Flow ID. The receive window is updated only if the ICV verification succeeds. DISCUSSION: Note that if the packet is either inside the window and new, or is outside the window on the "right" side, the receiver MUST authenticate the packet before updating the Sequence Number window data. 3.4.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; this is an auditable event. The audit log entry SHOULD include the SPI value, date/time received, Source Address, Destination Address, and (in IPv6) the Flow ID. DISCUSSION: Kent, Atkinson [Page 15] Internet Draft IP Authentication Header February 1998 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.3.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. Perform the ICV computation and compare the result with the saved value, using the comparison rules defined by the algorithm specification. (For example, if a digital signature and one-way hash are used for the ICV computation, the matching process is more complex.) 4. Auditing Not all systems that implement AH will implement auditing. However, if AH is incorporated into a system that supports auditing, then the AH implementation MUST also support auditing and MUST allow a system administrator to enable or disable auditing for AH. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in this specification and for each of these events a minimum set of information that SHOULD be included in an audit log is defined. Additional information also MAY be included in the audit log for each of these events, and additional events, not explicitly called out in this specification, also MAY result in audit log entries. There is no requirement for the receiver to transmit any message to the purported sender in response to the detection of an auditable event, because of the potential to induce denial of service via such action. 5. 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 document. If the key used to compute an ICV is manually distributed, correct provision of the anti-replay service would require correct maintenance of the counter state at the sender, until the key is replaced, and there likely would be no automated recovery provision if counter overflow were imminent. Thus a compliant implementation SHOULD NOT provide this service in conjunction with SAs that are manually keyed. A compliant AH implementation MUST support the following mandatory-to-implement algorithms: Kent, Atkinson [Page 16] Internet Draft IP Authentication Header February 1998 - HMAC with MD5 [MG97a] - HMAC with SHA-1 [MG97b] 6. Security Considerations Security is central to the design of this protocol, and these security considerations permeate the specification. Additional security-relevant aspects of using the IPsec protocol are discussed in the Security Architecture document. 7. Differences from RFC 1826 This specification of AH differs from RFC 1826 [ATK95] in several important respects, but the fundamental features of AH remain intact. One goal of the revision of RFC 1826 was to provide a complete framework for AH, with ancillary RFCs required only for algorithm specification. For example, the anti-replay service is now an integral, mandatory part of AH, not a feature of a transform defined in another RFC. Carriage of a sequence number to support this service is now required at all times. The default algorithms required for interoperability have been changed to HMAC with MD5 or SHA-1 (vs. keyed MD5), for security reasons. The list of IPv4 header fields excluded from the ICV computation has been expanded to include the OFFSET and FLAGS fields. Another motivation for revision was to provide additional detail and clarification of subtle points. This specification provides rationale for exclusion of selected IPv4 header fields from AH coverage and provides examples on positioning of AH in both the IPv4 and v6 contexts. Auditing requirements have been clarified in this version of the specification. Tunnel mode AH was mentioned only in passing in RFC 1826, but now is a mandatory feature of AH. Discussion of interactions with key management and with security labels have been moved to the Security Architecture document. 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 Karen Seo for providing extensive help in the review, editing, background research, and coordination for this version of the specification. The authors would also like to thank the members of the IPsec and IPng working groups, with special mention of the efforts of (in alphabetic order): Kent, Atkinson [Page 17] Internet Draft IP Authentication Header February 1998 Steve Bellovin, Steve Deering, Francis Dupont, Phil Karn, Frank Kastenholz, Perry Metzger, David Mihelcic, Hilarie Orman, Norman Shulman, William Simpson, and Nina Yuan. Kent, Atkinson [Page 18] Internet Draft IP Authentication Header February 1998 Appendix A -- Mutability of IP Options/Extension Headers A1. IPv4 Options This table shows how the IPv4 options are classified with regard to "mutability". Where two references are provided, the second one supercedes the first. This table is based in part on information provided in RFC1700, "ASSIGNED NUMBERS", (October 1994). Opt. Copy Class # Name Reference ---- ----- --- ------------------------- --------- IMMUTABLE -- included in ICV calculation 0 0 0 End of Options List [RFC791] 0 0 1 No Operation [RFC791] 1 0 2 Security [RFC1108(historic but in use)] 1 0 5 Extended Security [RFC1108(historic but in use)] 1 0 6 Commercial Security [expired I-D, now US MIL STD] 1 0 20 Router Alert [RFC2113] 1 0 21 Sender Directed Multi- [RFC1770] Destination Delivery MUTABLE -- zeroed 1 0 3 Loose Source Route [RFC791] 0 2 4 Time Stamp [RFC791] 0 0 7 Record Route [RFC791] 1 0 9 Strict Source Route [RFC791] 0 2 18 Traceroute [RFC1393] EXPERIMENTAL, SUPERCEDED -- zeroed 1 0 8 Stream ID [RFC791, RFC1122 (Host Req)] 0 0 11 MTU Probe [RFC1063, RFC1191 (PMTU)] 0 0 12 MTU Reply [RFC1063, RFC1191 (PMTU)] 1 0 17 Extended Internet Protocol [RFC1385, RFC1883 (IPv6)] 0 0 10 Experimental Measurement [ZSu] 1 2 13 Experimental Flow Control [Finn] 1 0 14 Experimental Access Ctl [Estrin] 0 0 15 ??? [VerSteeg] 1 0 16 IMI Traffic Descriptor [Lee] 1 0 19 Address Extension [Ullmann IPv7] NOTE: Use of the Router Alert option is potentially incompatible with use of IPsec. Although the option is immutable, its use implies that each router along a packet's path will "process" the packet and consequently might change the packet. This would happen on a hop by hop basis as the packet goes from router to router. Prior to being processed by the application to which the option contents are directed, e.g., RSVP/IGMP, the packet should encounter AH processing. Kent, Atkinson [Page 19] Internet Draft IP Authentication Header February 1998 However, AH processing would require that each router along the path is a member of a multicast-SA defined by the SPI. This might pose problems for packets that are not strictly source routed, and it requires multicast support techniques not currently available. NOTE: Addition or removal of any security labels (BSO, ESO, CIPSO) by systems along a packet's path conflicts with the classification of these IP Options as immutable and is incompatible with the use of IPsec. NOTE: End of Options List options SHOULD be repeated as necessary to ensure that the IP header ends on a 4 byte boundary in order to ensure that there are no unspecified bytes which could be used for a covert channel. A2. IPv6 Extension Headers This table shows how the IPv6 Extension Headers are classified with regard to "mutability". Option/Extension Name Reference ----------------------------------- --------- MUTABLE BUT PREDICTABLE -- included in ICV calculation Routing (Type 0) [RFC1883] BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING TRANSIT) Hop by Hop options [RFC1883] Destination options [RFC1883] NOT APPLICABLE Fragmentation [RFC1883] Options -- IPv6 options in the Hop-by-Hop and Destination Extension Headers contain a bit that indicates whether the option might change (unpredictably) 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 options for which the bit indicates immutability are included in the ICV calculation. See the IPv6 specification [DH95] for more information. Routing (Type 0) -- 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 Kent, Atkinson [Page 20] Internet Draft IP Authentication Header February 1998 included in the Authentication Data calculation as mutable but predictable. The sender must order the field so that it appears as it will at the receiver, prior to performing the ICV computation. Fragmentation -- Fragmentation occurs after outbound IPsec processing (section 3.3) and reassembly occurs before inbound IPsec processing (section 3.4). So the Fragmentation Extension Header, if it exists, is not seen by IPsec. Note that on the receive side, the IP implementation could leave a Fragmentation Extension Header in place when it does re-assembly. If this happens, then when AH receives the packet, before doing ICV processing, AH MUST "remove" (or skip over) this header and change the previous header's "Next Header" field to be the "Next Header" field in the Fragmentation Extension Header. Note that on the send side, the IP implementation could give the IPsec code a packet with a Fragmentation Extension Header with Offset of 0 (first fragment) and a More Fragments Flag of 0 (last fragment). If this happens, then before doing ICV processing, AH MUST first "remove" (or skip over) this header and change the previous header's "Next Header" field to be the "Next Header" field in the Fragmentation Extension Header. Kent, Atkinson [Page 21] Internet Draft IP Authentication Header February 1998 References [ATK95] R. Atkinson, "The IP Authentication Header," RFC 1826, August 1995. [Bra97] S. Bradner, "Key words for use in RFCs to Indicate Requirement Level," RFC-2119, March 1997. [DH95] Steve Deering & Bob Hinden, "Internet Protocol version 6 (IPv6) Specification", RFC-1883, December 1995. [KA97a] Steve Kent, Randall Atkinson, "Security Architecture for the Internet Protocol", Internet Draft, February, 1998. [KA97b] Steve Kent, Randall Atkinson, "IP Encapsulating Security Payload (ESP)", Internet Draft, February 1998. [MG97a] C. Madson & R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", Internet Draft, November 1997. [MG97b] C. Madson & R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", Internet Draft, November 1997. [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 E-mail: kent@bbn.com Telephone: +1 (617) 873-3988 Kent, Atkinson [Page 22] Internet Draft IP Authentication Header February 1998 Randall Atkinson @Home Network 425 Broadway, Redwood City, CA 94063 USA E-mail: rja@inet.org Copyright (C) The Internet Society (February 1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Kent, Atkinson [Page 23] -- John Kelley johnk@tis.com Director, Systems Administration Trusted Information Systems, Inc. (A NASDAQ company: "TISX") http://www.tis.com From owner-ipsec Mon Feb 16 17:08:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA23850 for ipsec-outgoing; Mon, 16 Feb 1998 17:07:00 -0500 (EST) Message-Id: <199802162207.RAA23850@portal.ex.tis.com> Date: Fri, 13 Feb 98 15:21:11 EST From: Karen Seo To: internet-drafts@ietf.org cc: tytso@MIT.EDU, rgm-sec@homebase.htt-consult.com, skent@bbn.com, kseo@bbn.com Subject: Internet Draft -- IPsec ESP spec Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, Please find attached the Internet Draft for the IPsec ESP specification. Thank you, Karen Network Working Group Stephen Kent, BBN Corp Internet Draft Randall Atkinson, @Home Network draft-ietf-ipsec-esp-v2-03.txt February 1998 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 IPsec working group. 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. Copyright (C) The Internet Society (February 1998). All Rights Reserved. Kent, Atkinson [Page 1] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) Table of Contents 1. Introduction......................................................3 2. Encapsulating Security Payload Packet Format......................4 2.1 Security Parameters Index....................................5 2.2 Sequence Number .............................................5 2.3 Payload Data.................................................5 2.4 Padding (for Encryption).....................................6 2.5 Pad Length...................................................7 2.6 Next Header..................................................7 2.7 Authentication Data..........................................8 3. Encapsulating Security Protocol Processing........................8 3.1 ESP Header Location..........................................8 3.2 Algorithms..................................................10 3.2.1 Encryption Algorithms..................................10 3.2.2 Authentication Algorithms..............................11 3.3 Outbound Packet Processing..................................11 3.3.1 Security Association Lookup............................11 3.3.2 Packet Encryption......................................11 3.3.3 Sequence Number Generation.............................12 3.3.4 Integrity Check Value Calculation......................12 3.3.5 Fragmentation..........................................13 3.4 Inbound Packet Processing...................................13 3.4.1 Reassembly.............................................13 3.4.2 Security Association Lookup............................14 3.4.3 Sequence Number Verification...........................14 3.4.4 Integrity Check Value Verification.....................16 3.4.5 Packet Decryption......................................16 4. Auditing.........................................................18 5. Conformance Requirements.........................................18 6. Security Considerations..........................................18 7. Differences from RFC 1827........................................19 Acknowledgements....................................................19 References..........................................................19 Disclaimer..........................................................20 Author Information..................................................21 Kent, Atkinson [Page 2] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) 1. Introduction The Encapsulating Security Payload (ESP) header is designed to provide a mix of 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 "Security Architecture for the Internet Protocol" [KA97a], hereafter referred to as the Security Architecture document). 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 the Security Architecture document [KA97a]. The ESP header is inserted after the IP header and before the upper layer protocol header (transport mode) or before an encapsulated IP header (tunnel mode). These modes are described in more detail below. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. The set of services provided depends on options selected at the time of Security Association establishment and on the placement of the implementation. Confidentiality may be selected independent of all other services. However, use of confidentiality without integrity/authentication (either in ESP or separately in AH) may subject traffic to certain forms of active attacks that could undermine the confidentiality service (see [Bel96]). Data origin authentication and connectionless integrity are joint services (hereafter referred to jointly as "authentication) and are offered as an option in conjunction with confidentiality. The anti-replay service may be selected only if data origin authentication is selected, and its election is solely at the discretion of the receiver. (Although the default calls for the sender to increment the Sequence Number used for anti-replay, the service is effective only if the receiver checks the Sequence Number.) Traffic flow confidentiality requires selection of tunnel mode, and is most effective if implemented at a security gateway, where traffic aggregation may be able to mask true source-destination patterns. It is assumed that the reader is familiar with the terms and concepts described in the Security Architecture document. In particular, the reader should be familiar with the definitions of security services offered by ESP and AH, the concept of Security Associations, the ways in which ESP can be used in conjunction with the Authentication Header (AH), and the different key management options available for Kent, Atkinson [Page 3] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) ESP and AH. (With regard to the last topic, the current key management options required for both AH and ESP are manual keying and automated keying via ISAKMP/Oakley.) The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [Bra97]. 2. Encapsulating Security Payload Packet Format The protocol header (IPv4, IPv6, or Extension) immediately preceding the ESP header will contain the value 50 in its Protocol (IPv4) or Next Header (IPv6, Extension) field [STD-2]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- | Security Parameters Index (SPI) | ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Auth. | Sequence Number | |Coverage +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----- | Payload Data* (variable) | | ^ ~ ~ | | | | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Confid. | | Padding (0-255 bytes) | |Coverage* +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Pad Length | Next Header | v v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------- | Authentication Data (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * If included in the Payload field, cryptographic synchronization data, e.g., an Initialization Vector (IV, see Section 2.3), usually is not encrypted per se, although it often is referred to as being part of the ciphertext. 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 Integrity Check Value (ICV, see Section 2.7). 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 Kent, Atkinson [Page 4] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) 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 that, in combination with the destination IP address and security protocol (ESP), uniquely identifies the Security Association for this datagram. 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. It is ordinarily selected by the destination system upon establishment of an SA (see the Security Architecture document for more details). The SPI field is mandatory. The SPI value of zero (0) is reserved for local, implementation- specific use and MUST NOT be sent on the wire. For example, a key management implementation MAY use the zero SPI value to mean "No Security Association Exists" during the period when the IPsec implementation has requested that its key management entity establish a new SA, but the SA has not yet been established. 2.2 Sequence Number This unsigned 32-bit field contains a monotonically increasing counter value (sequence number). It is mandatory and is always present even if the receiver does not elect to enable the anti-replay service for a specific SA. Processing of the Sequence Number field is at the discretion of the receiver, i.e., the sender MUST always transmit this field, but the receiver need not act upon it (see the discussion of Sequence Number Verification in the "Inbound Packet Processing" section below). The sender's counter and the receiver's counter are initialized to 0 when an SA is established. (The first packet sent using a given SA will have a Sequence Number of 1; see Section 3.3.3 for more details on how the Sequence Number is generated.) If anti-replay is enabled (the default), the transmitted Sequence Number must never be allowed to cycle. Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA. 2.3 Payload Data Payload Data is a variable-length field containing data described by the Next Header field. The Payload Data field is mandatory and is an Kent, Atkinson [Page 5] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) integral number of bytes in length. If the algorithm used to encrypt the payload requires cryptographic synchronization data, e.g., an Initialization Vector (IV), then this data MAY be carried explicitly in the Payload field. Any encryption algorithm that requires such explicit, per-packet synchronization data MUST indicate the length, any structure for such data, and the location of this data as part of an RFC specifying how the algorithm is used with ESP. If such synchronization data is implicit, the algorithm for deriving the data MUST be part of the RFC. Note that with regard to ensuring the alignment of the (real) ciphertext in the presence of an IV: o For some IV-based modes of operation, the receiver treats the IV as the start of the ciphertext, feeding it into the algorithm directly. In these modes, alignment of the start of the (real) ciphertext is not an issue at the receiver. o In some cases, the receiver reads the IV in separately from the ciphertext. In these cases, the algorithm specification MUST address how alignment of the (real) ciphertext is to be achieved. 2.4 Padding (for Encryption) Several factors require or motivate use of the Padding field. o If an encryption algorithm is employed that requires the plaintext to be a multiple of some number of bytes, e.g., the block size of a block cipher, the Padding field is used to fill the plaintext (consisting of the Payload Data, Pad Length and Next Header fields, as well as the Padding) to the size required by the algorithm. o Padding also may be required, irrespective of encryption algorithm requirements, to ensure that the resulting ciphertext terminates on a 4-byte boundary. Specifically, the Pad Length and Next Header fields must be right aligned within a 4-byte word, as illustrated in the ESP packet format figure above, to ensure that the Authentication Data field (if present) is aligned on a 4-byte boundary. o Padding beyond that required for the algorithm or alignment reasons cited above, may be used to conceal the actual length of the payload, in support of (partial) traffic flow confidentiality. However, inclusion of such additional padding has adverse bandwidth implications and thus its use should be undertaken with care. Kent, Atkinson [Page 6] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) The sender MAY add 0-255 bytes of padding. Inclusion of the Padding field in an ESP packet is optional, but all implementations MUST support generation and consumption of padding. The padding computation applies to the plaintext portion of the Payload Data, exclusive of the IV (if present). If Padding bytes are needed but the encryption algorithm does not specify the padding contents, then the following default processing MUST be used. The Padding bytes are initialized with a series of (unsigned, 1-byte) integer values. The first padding byte appended to the plaintext is numbered 1, with subsequent padding bytes making up a monotonically increasing sequence: 1, 2, 3, ... When this padding scheme is employed, the receiver SHOULD inspect the Padding field. (This scheme was selected because of its relative simplicity, ease of implementation in hardware, and because it offers limited protection against certain forms of "cut and paste" attacks in the absence of other integrity measures, if the receiver checks the padding values upon decryption.) Any encryption algorithm that requires Padding other than the default described above, MUST define the Padding contents (e.g., zeros or random data) and any required receiver processing of these Padding bytes in an RFC specifying how the algorithm is used with ESP. In such circumstances, the content of the Padding field will be determined by the encryption algorithm and mode selected and defined in the corresponding algorithm RFC. The relevant algorithm RFC MAY specify that a receiver MUST inspect the Padding field or that a receiver MUST inform senders of how the receiver will handle the Padding field. 2.5 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 no Padding bytes are present. The Pad Length field is mandatory. 2.6 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. Kent, Atkinson [Page 7] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) 2.7 Authentication Data The Authentication Data is a variable-length field containing an Integrity Check Value (ICV) computed over the ESP packet minus the Authentication Data. The length of the field is specified by the authentication function selected. The Authentication Data field is optional, and is included only if the authentication service has been selected for the SA in question. The authentication algorithm specification MUST specify the length of the ICV and the comparison rules and processing steps for validation. 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, note that for "bump-in-the-stack" or "bump-in-the- wire" implementations, as defined in the Security Architecture document, inbound and outbound IP fragments may require an IPsec implementation to perform extra IP reassembly/fragmentation in order to both conform to this specification and provide transparent IPsec support. Special care is required to perform such operations within these implementations when multiple interfaces are in use.) In transport mode, ESP is inserted after the IP header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other IPsec headers that have already been inserted. 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.) Kent, Atkinson [Page 8] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) BEFORE APPLYING ESP ---------------------------- IPv4 |orig IP hdr | | | |(any options)| TCP | Data | ---------------------------- AFTER APPLYING ESP ------------------------------------------------- IPv4 |orig IP hdr | ESP | | | ESP | ESP| |(any options)| Hdr | 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. BEFORE APPLYING ESP --------------------------------------- IPv6 | | ext hdrs | | | | orig IP hdr |if present| TCP | Data | --------------------------------------- AFTER APPLYING ESP --------------------------------------------------------- IPv6 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP| |IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer|Auth| --------------------------------------------------------- |<---- encrypted ---->| |<---- authenticated ---->| * = if present, could be before ESP, after ESP, or both ESP and AH headers can be combined in a variety of modes. The IPsec Architecture document describes the combinations of security associations that must be supported. 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 Kent, Atkinson [Page 9] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) "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* |new ext | | orig*|orig ext | | | ESP | ESP| |IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer|Auth| ------------------------------------------------------------ |<--------- encrypted ----------->| |<---------- authenticated ---------->| * = if present, construction of outer IP hdr/extensions and modification of inner IP hdr/extensions is discussed below. 3.2 Algorithms The mandatory-to-implement algorithms are described in Section 5, "Conformance Requirements". Other algorithms MAY be supported. 3.2.1 Encryption Algorithms 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 any data required to allow the receiver to establish cryptographic synchronization for decryption. This data may be carried explicitly in the payload field, e.g., as an IV (as described above), or the data may be derived from the packet header. Since ESP makes provision for padding of the plaintext, encryption algorithms employed with ESP may exhibit either block or stream mode characteristics. Kent, Atkinson [Page 10] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) 3.2.2 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 appropriate, though performance and space considerations currently preclude use of such algorithms. 3.3 Outbound Packet Processing In transport mode, the sender 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 Security Architecture document. If there is more than one IPsec header/extension required by security policy, the order of the application of the security headers MUST be defined by security policy. 3.3.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 Security Architecture document. 3.3.2 Packet Encryption The sender: 1. encapsulates (into the ESP Payload field): - for transport mode -- just the original upper layer protocol information. - for tunnel mode -- the entire original IP datagram. 2. adds any necessary padding. 3. encrypts the result (Payload Data, Padding, Pad Length, and Next Header) using the key, encryption algorithm, algorithm mode indicated by the SA and cryptographic synchronization data (if any). - If explicit cryptographic synchronization data, e.g., an IV, is indicated, it is input to the decryption algorithm per the algorithm specification and placed Kent, Atkinson [Page 11] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) in the Payload field. - If implicit cryptographic synchronication data, e.g., an IV, is indicated, it is constructed and input to the decryption algorithm as per the algorithm specification. The exact steps for constructing the outer IP header depend on the mode (transport or tunnel) and are described in the Security Architecture document. If authentication is 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. 3.3.3 Sequence Number Generation The sender's counter is initialized to 0 when an SA is established. The sender increments the Sequence Number for this SA and inserts the new value into the Sequence Number field. Thus the first packet sent using a given SA will have a Sequence Number of 1. If anti-replay is enabled (the default), the sender checks to ensure that the counter has not cycled before inserting the new value in the Sequence Number field. In other words, the sender MUST NOT send a packet on an SA if doing so would cause the Sequence Number to cycle. An attempt to transmit a packet that would result in Sequence Number overflow is an auditable event. (Note that this approach to Sequence Number management does not require use of modular arithmetic.) If anti-replay has been disabled, the sender does not need to monitor or reset the counter, e.g., in the case of manual key management (see Section 5). 3.3.4 Integrity Check Value Calculation If authentication is selected for the SA, the sender computes the ICV over the ESP packet minus the Authentication Data. Thus the SPI, Sequence Number, Payload Data, Padding (if present), Pad Length, and Next Header are all encompassed by the ICV computation. Note that the last 4 fields will be in ciphertext form, since encryption is Kent, Atkinson [Page 12] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) performed prior to authentication. 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, (after the Next Header field) 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. Note that MD5 and SHA-1 are viewed as having a 1-byte blocksize because of their internal padding conventions. 3.3.5 Fragmentation If necessary, fragmentation is performed after ESP processing within an IPsec implementation. Thus, transport mode ESP is applied only to whole IP datagrams (not to IP fragments). An IP packet to which ESP has been applied may itself be fragmented by routers en route, and such fragments must be reassembled prior to ESP processing at a receiver. In tunnel mode, ESP is applied to an IP packet, the payload of which may be a fragmented IP packet. For example, a security gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation (as defined in the Security Architecture document) may apply tunnel mode ESP to such fragments. NOTE: For transport mode -- As mentioned at the beginning of Section 3.1, bump-in-the-stack and bump-in-the-wire implementations may have to first reassemble a packet fragmented by the local IP layer, then apply IPsec, and then fragment the resulting packet. NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire implementations, it will be necessary to walk through all the extension headers to determine if there is a fragmentation header and hence that the packet needs reassembling prior to IPsec processing. 3.4 Inbound Packet Processing 3.4.1 Reassembly If required, reassembly is performed prior to ESP processing. If a packet offered to ESP for processing appears to be an IP fragment, i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, Kent, Atkinson [Page 13] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID. NOTE: For packet reassembly, the current IPv4 spec does NOT require either the zero'ing of the OFFSET field or the clearing of the MORE FRAGMENTS flag. In order for a reassembled packet to be processed by IPsec (as opposed to discarded as an apparent fragment), the IP code must do these two things after it reassembles a packet. 3.4.2 Security Association Lookup Upon receipt of a (reassembled) packet containing an ESP Header, the receiver determines the appropriate (unidirectional) SA, based on the destination IP address, security protocol (ESP), and the SPI. (This process is described in more detail in the Security Architecture document.) The SA indicates whether the Sequence Number field will be checked, whether the Authentication Data field 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 packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the cleartext Flow ID. 3.4.3 Sequence Number Verification All ESP implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. This service MUST NOT be enabled unless the authentication service also is enabled for the SA, since otherwise the Sequence Number field has not been integrity protected. (Note that there are no provisions for managing transmitted Sequence Number values among multiple senders directing traffic to a single SA (irrespective of whether the destination address is unicast, broadcast, or multicast). Thus the anti-replay service SHOULD NOT be used in a multi-sender environment that employs a single SA.) If the receiver does not enable anti-replay for an SA, no inbound checks are performed on the Sequence Number. The default for the sender is that the Sequence Number will be checked at the sender. Hence, if an SA establishment protocol such as ISAKMP/Oakley is employed, the receiver SHOULD notify the sender, during SA establishment, if the receiver will not provide anti-replay Kent, Atkinson [Page 14] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) protection. If the receiver has enabled the anti-replay service for this SA, the receive packet counter for the SA MUST be initialized to zero when the SA is established. For each received packet, 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 ESP 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.) A MINIMUM window size of 32 MUST be supported; but a window size of 64 is preferred and SHOULD be employed as the default. Another window size (larger than the MINIMUM) MAY be chosen by the receiver. (The receiver does NOT notify the sender of the window size.) The "right" edge of the window represents the highest, validated Sequence Number 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 the Security Architecture document. If the received packet falls within the window and is new, or if the packet is to the right of the window, then the receiver proceeds to ICV verification. If the ICV validation fails, the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, the Sequence Number, and (in IPv6) the Flow ID. The receive window is updated only if the ICV verification succeeds. DISCUSSION: Note that if the packet is either inside the window and new, or is outside the window on the "right" side, the receiver MUST authenticate the packet before updating the Sequence Number window data. Kent, Atkinson [Page 15] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) 3.4.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; this is an auditable event. The log data SHOULD include the SPI value, date/time received, Source Address, Destination Address, and (in IPv6) the cleartext Flow ID. 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 saved value, using the comparison rules defined by the algorithm specification. (For example, if a digital signature and one-way hash are used for the ICV computation, the matching process is more complex.) 3.4.5 Packet Decryption The receiver: 1. decrypts the ESP Payload Data, Padding, Pad Length, and Next Header using the key, encryption algorithm, algorithm mode, and cryptographic synchronization data (if any), indicated by the SA. - If explicit cryptographic synchronization data, e.g., an IV, is indicated, it is taken from the Payload field and input to the decryption algorithm as per the algorithm specification. - If implicit cryptographic synchronization data, e.g., an IV, is indicated, a local version of the IV is constructed and input to the decryption algorithm as per the algorithm specification. 2. processes any padding as specified in the encryption algorithm specification. The default action is to remove/ignore any padding. Kent, Atkinson [Page 16] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) 3. reconstructs the original IP datagram from: - for transport mode -- original IP header plus the original upper layer protocol information in the ESP Payload field - for tunnel mode -- tunnel IP header + the entire IP datagram in the ESP Payload field. The exact steps for reconstructing the original datagram depend on the mode (transport or tunnel) and are described in the Security Architecture document. At a minimum, in an IPv6 context, the receiver SHOULD ensure that the decrypted data is 8-byte aligned, to facilitate processing by the protocol identified in the Next Header field. If authentication has been selected, verification and decryption MAY be performed serially or in parallel. If performed serially, then ICV verification SHOULD be performed first. If performed in parallel, verification MUST be completed before the decrypted packet is passed on for further processing. 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. Note: If the receiver performs decryption in parallel with authentication, care must be taken to avoid possible race conditions with regard to packet access and reconstruction of the decrypted packet. Note that there are several ways in which the decryption can "fail": a. The selected SA may not be correct -- The SA may be mis-selected due to tampering with the SPI, destination address. or IPsec protocol type fields. Such errors, if they map the packet to another extant SA, will be indistinguishable from a corrupted packet, (case c). Tampering with the SPI can be detected by use of authentication. However, an SA mismatch might still occur due to tampering with the IP Destination Address or the IPsec protocol type field. b. The pad length or pad values could be erroneous -- Bad pad lengths or pad values can be detected irrespective of the use of authentication. c. The encrypted ESP packet could be corrupted -- This can be detected if authentication is selected for the SA., In case (a) or (c), the erroneous result of the decryption operation (an invalid IP datagram or transport-layer frame) will not Kent, Atkinson [Page 17] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) necessarily be detected by IPsec, and is the responsibility of later protocol processing. 4. Auditing Not all systems that implement ESP will implement auditing. However, if ESP is incorporated into a system that supports auditing, then the ESP implementation MUST also support auditing and MUST allow a system administrator to enable or disable auditing for ESP. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in this specification and for each of these events a minimum set of information that SHOULD be included in an audit log is defined. Additional information also MAY be included in the audit log for each of these events, and additional events, not explicitly called out in this specification, also MAY result in audit log entries. There is no requirement for the receiver to transmit any message to the purported sender in response to the detection of an auditable event, because of the potential to induce denial of service via such action. 5. 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 document. If the key used to compute an ICV is manually distributed, correct provision of the anti-replay service would require correct maintenance of the counter state at the sender, until the key is replaced, and there likely would be no automated recovery provision if counter overflow were imminent. Thus a compliant implementation SHOULD NOT provide this service in conjunction with SAs that are manually keyed. A compliant ESP implementation MUST support the following mandatory-to-implement algorithms: - DES in CBC mode [MD97] - HMAC with MD5 [MG97a] - HMAC with SHA-1 [MG97b] 6. Security Considerations Security is central to the design of this protocol, and thus security considerations permeate the specification. Additional security- relevant aspects of using the IPsec protocol are discussed in the Security Architecture document. Kent, Atkinson [Page 18] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) 7. Differences from RFC 1827 This document differs from RFC 1827 [ATK95] in several significant ways. The major difference is that, this document attempts to specify a complete framework and context for ESP, whereas RFC 1827 provided a "shell" that was completed through the definition of transforms. The combinatorial growth of transforms motivated the reformulation of the ESP specification as a more complete document, with options for security services that may be offered in the context of ESP. Thus, fields previously defined in transform documents are now part of this base ESP specification. For example, the fields necessary to support authentication (and anti-replay) are now defined here, even though the provision of this service is an option. The fields used to support padding for encryption, and for next protocol identification, are now defined here as well. Packet processing consistent with the definition of these fields also is included in the document. 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 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 Karen Seo for providing extensive help in the review, editing, background research, and coordination for this version of the specification. The authors would also 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, Norman Shulman, William Simpson and Nina Yuan. References [ATK95] R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 1827, August 1997. [Bel96] Steven M. Bellovin, "Problem Areas for the IP Security Protocols", Proceedings of the Sixth Usenix Unix Security Kent, Atkinson [Page 19] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) Symposium, July, 1996. [Bra97] S. Bradner, "Key words for use in RFCs to Indicate Requirement Level," RFC-2119, March 1997. [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. [KA97a] Steve Kent, Randall Atkinson, "Security Architecture for the Internet Protocol", Internet Draft, February 1998. [KA97b] Steve Kent, Randall Atkinson, "IP Authentication Header", Internet Draft, February 1998. [MD97] C. Madson & N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", Internet Draft, Deceber 1997. [MG97a] C. Madson & R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", Internet Draft, November 1997. [MG97b] C. Madson & R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", Internet Draft, November 1997. [STD-2] J. Reynolds and J. Postel, "Assigned Numbers", STD-2, 20 October 1994. [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. 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. Kent, Atkinson [Page 20] Internet Draft IP Encapsulating February 1998 Security Payload (ESP) Author Information Stephen Kent BBN Corporation 70 Fawcett Street Cambridge, MA 02140 USA E-mail: kent@bbn.com Telephone: +1 (617) 873-3988 Randall Atkinson @Home Network 425 Broadway, Redwood City, CA 94063 USA E-mail: rja@inet.org Copyright (C) The Internet Society (February 1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Kent, Atkinson [Page 21] -- John Kelley johnk@tis.com Director, Systems Administration Trusted Information Systems, Inc. (A NASDAQ company: "TISX") http://www.tis.com From owner-ipsec Mon Feb 16 17:09:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA23878 for ipsec-outgoing; Mon, 16 Feb 1998 17:07:59 -0500 (EST) Message-Id: <199802162207.RAA23878@portal.ex.tis.com> To: IETF-Announce:;;;;;;@tis.com;@tis.com;;;;;;;;;;;;;;;;;;;;;; Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-auth-hmac-md5-96-02.txt Date: Mon, 16 Feb 1998 09:01:13 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Use of HMAC-MD5-96 within ESP and AH Author(s) : C. Madson, R. Glenn Filename : draft-ietf-ipsec-auth-hmac-md5-96-02.txt Pages : 6 Date : 13-Feb-98 This draft describes the use of the HMAC algorithm [RFC-2104] in conjunction with the MD5 algorithm [RFC-1321] as an authentication mechanism within the revised IPSEC Encapsulating Security Payload [ESP] and the revised IPSEC Authentication Header [AH]. HMAC with MD5 provides data origin authentication and integrity protection. Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a]. 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-auth-hmac-md5-96-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-md5-96-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-auth-hmac-md5-96-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: <19980213151513.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-auth-hmac-md5-96-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-auth-hmac-md5-96-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980213151513.I-D@ietf.org> --OtherAccess-- --NextPart-- -- John Kelley johnk@tis.com Director, Systems Administration Trusted Information Systems, Inc. (A NASDAQ company: "TISX") http://www.tis.com From owner-ipsec Mon Feb 16 17:09:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA23881 for ipsec-outgoing; Mon, 16 Feb 1998 17:08:01 -0500 (EST) Message-Id: <199802162208.RAA23881@portal.ex.tis.com> To: IETF-Announce:;;;;;;@tis.com;@tis.com;;;;;;;;;;;;;;;;;;;;;; Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-auth-hmac-sha196-02.txt Date: Mon, 16 Feb 1998 09:01:21 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Use of HMAC-SHA-1-96 within ESP and AH Author(s) : C. Madson, R. Glenn Filename : draft-ietf-ipsec-auth-hmac-sha196-02.txt Pages : 5 Date : 13-Feb-98 This draft describes the use of the HMAC algorithm [RFC-2104] in conjunction with the SHA-1 algorithm [FIPS-180-1] as an authentication mechanism within the revised IPSEC Encapsulating Security Payload [ESP] and the revised IPSEC Authentication Header [AH]. HMAC with SHA-1 provides data origin authentication and integrity protection. Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a]. 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-auth-hmac-sha196-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-sha196-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-auth-hmac-sha196-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: <19980213151552.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-auth-hmac-sha196-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-auth-hmac-sha196-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980213151552.I-D@ietf.org> --OtherAccess-- --NextPart-- -- John Kelley johnk@tis.com Director, Systems Administration Trusted Information Systems, Inc. (A NASDAQ company: "TISX") http://www.tis.com From owner-ipsec Mon Feb 16 17:09:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA23882 for ipsec-outgoing; Mon, 16 Feb 1998 17:08:01 -0500 (EST) Message-Id: <199802162208.RAA23882@portal.ex.tis.com> From: Stephen Waters To: ipsec@tis.com Subject: IPSEC tunnel over TCP Date: Mon, 16 Feb 1998 13:43:07 -0000 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ipsec@ex.tis.com Precedence: bulk Is the following supported for an IPSEC tunnel-mode exchange : [IP2][TCP][ESP][IP1][Upper] ? Regards, Steve. -- John Kelley johnk@tis.com Director, Systems Administration Trusted Information Systems, Inc. (A NASDAQ company: "TISX") http://www.tis.com From owner-ipsec Mon Feb 16 17:10:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA23917 for ipsec-outgoing; Mon, 16 Feb 1998 17:08:59 -0500 (EST) Message-Id: <199802162208.RAA23917@portal.ex.tis.com> To: IETF-Announce:;;;;;;@tis.com;@tis.com;;;;;;;;;;;;;;;;;;;;;; Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-esp-v2-03.txt Date: Mon, 16 Feb 1998 09:04:46 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IP Encapsulating Security Payload (ESP) Author(s) : S. Kent, R. Atkinson Filename : draft-ietf-ipsec-esp-v2-03.txt Pages : 21 Date : 13-Feb-98 The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-esp-v2-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v2-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-esp-v2-03.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: <19980213162537.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-v2-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-v2-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980213162537.I-D@ietf.org> --OtherAccess-- --NextPart-- -- John Kelley johnk@tis.com Director, Systems Administration Trusted Information Systems, Inc. (A NASDAQ company: "TISX") http://www.tis.com From owner-ipsec Mon Feb 16 17:10:32 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA23920 for ipsec-outgoing; Mon, 16 Feb 1998 17:09:01 -0500 (EST) Message-Id: <199802162209.RAA23920@portal.ex.tis.com> To: IETF-Announce:;;;;;;@tis.com;@tis.com;;;;;;;;;;;;;;;;;;;;;; Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ciph-des-expiv-02.txt Date: Mon, 16 Feb 1998 09:07:16 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The ESP DES-CBC Cipher Algorithm With Explicit IV Author(s) : N. Doraswamy, C. Madson Filename : draft-ietf-ipsec-ciph-des-expiv-02.txt Pages : 8 Date : 13-Feb-98 This document describes the use of the DES Cipher algorithm in Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPSec Encapsulating Security Payload (ESP). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ciph-des-expiv-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-des-expiv-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-ciph-des-expiv-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: <19980213194700.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-des-expiv-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-des-expiv-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980213194700.I-D@ietf.org> --OtherAccess-- --NextPart-- -- John Kelley johnk@tis.com Director, Systems Administration Trusted Information Systems, Inc. (A NASDAQ company: "TISX") http://www.tis.com From owner-ipsec Mon Feb 16 17:10:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA23921 for ipsec-outgoing; Mon, 16 Feb 1998 17:09:01 -0500 (EST) Message-Id: <199802162209.RAA23921@portal.ex.tis.com> To: IETF-Announce:;;;;;;@tis.com;@tis.com;;;;;;;;;;;;;;;;;;;;;; Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-oakley-06.txt Date: Mon, 16 Feb 1998 09:06:51 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Internet Key Exchange (IKE) Author(s) : D. Carrel, D. Harkins Filename : draft-ietf-ipsec-isakmp-oakley-06.txt Pages : 39 Date : 13-Feb-98 [MSST97] (ISAKMP) provides a framework for authentication and key exchange but does not define them. ISAKMP is designed to be key exchange independant; that is, it is designed to support many different key exchanges. [Orm96] (Oakley) describes a series of key exchanges-- called ''modes''-- and details the services provided by each (e.g. perfect forward secrecy for keys, identity protection, and authentication). [Kra96] (SKEME) describes a versatile key exchange technique which provides anonymity, repudiability, and quick key refreshment. This document describes a protocol using part of Oakley and part of SKEME in conjunction with ISAKMP to obtain authenticated keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-isakmp-oakley-06.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-oakley-06.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-isakmp-oakley-06.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: <19980213183154.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-oakley-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-oakley-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980213183154.I-D@ietf.org> --OtherAccess-- --NextPart-- -- John Kelley johnk@tis.com Director, Systems Administration Trusted Information Systems, Inc. (A NASDAQ company: "TISX") http://www.tis.com From owner-ipsec Mon Feb 16 17:11:24 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA23956 for ipsec-outgoing; Mon, 16 Feb 1998 17:10:00 -0500 (EST) Message-Id: <199802162210.RAA23956@portal.ex.tis.com> To: IETF-Announce:;;;;;@tis.com@tis.com;;;;;;;; Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-auth-header-04.txt Date: Mon, 16 Feb 1998 09:04:39 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IP Authentication Header Author(s) : S. Kent, R. Atkinson Filename : draft-ietf-ipsec-auth-header-04.txt Pages : 23 Date : 13-Feb-98 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, by the receiver, when a Security Association is established. (Although the default calls for the sender to increment the Sequence Number used for anti-replay, the service is effective only if the receiver checks the Sequence Number.) 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 sender. 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 ''Security Architecture for the Internet Protocol'' [KA97a], hereafter referred to as the Security Architecture document). 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 a confidentiality (encryption) service. The primary difference between the authentication provided by ESP and AH is the extent of the coverage. Specifically, ESP does not protect any IP header fields unless those fields are encapsulated by ESP (tunnel mode). For more details on how to use AH and ESP in various network environments, see the Security Architecture document [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-auth-header-04.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-auth-header-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-auth-header-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19980213162516.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-auth-header-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-auth-header-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980213162516.I-D@ietf.org> --OtherAccess-- --NextPart-- -- John Kelley johnk@tis.com Director, Systems Administration Trusted Information Systems, Inc. (A NASDAQ company: "TISX") http://www.tis.com From owner-ipsec Mon Feb 16 17:11:32 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA23955 for ipsec-outgoing; Mon, 16 Feb 1998 17:10:00 -0500 (EST) Message-Id: <199802162210.RAA23955@portal.ex.tis.com> To: IETF-Announce:;;;;;@tis.com@tis.com;;;;;;;; Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ipsec-doi-07.txt Date: Mon, 16 Feb 1998 09:07:07 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Internet IP Security Domain of Interpretation for ISAKMP Author(s) : D. Piper Filename : draft-ietf-ipsec-ipsec-doi-07.txt Pages : 29 Date : 13-Feb-98 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, payloads, and processing guidelines that occur within a given Domain of Interpretation (DOI). This document defines the Internet IP Security DOI (IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate security associations. For a description of how the IPSEC DOI fits into the overall IP Security Documentation framework, please see [ROADMAP]. For a list of changes since the previous version of the IPSEC DOI, please see Section 5. 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-07.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-ipsec-doi-07.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-07.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19980213191256.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ipsec-doi-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ipsec-doi-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980213191256.I-D@ietf.org> --OtherAccess-- --NextPart-- -- John Kelley johnk@tis.com Director, Systems Administration Trusted Information Systems, Inc. (A NASDAQ company: "TISX") http://www.tis.com From owner-ipsec Mon Feb 16 17:43:38 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA24184 for ipsec-outgoing; Mon, 16 Feb 1998 17:41:59 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199802162208.RAA23882@portal.ex.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 16 Feb 1998 17:39:12 -0500 To: Stephen Waters From: Stephen Kent Subject: Re: IPSEC tunnel over TCP Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk At 1:43 PM +0000 2/16/98, Stephen Waters wrote: >Is the following supported for an IPSEC tunnel-mode exchange : > >[IP2][TCP][ESP][IP1][Upper] ? > No. ESP is carried above IP, but not above a transport protocol such as TCP. Steve From owner-ipsec Mon Feb 16 17:45:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA24212 for ipsec-outgoing; Mon, 16 Feb 1998 17:44:09 -0500 (EST) Date: Mon, 16 Feb 1998 17:57:02 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199802162257.RAA25135@earth.hpc.org> To: dharkins@cisco.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199802162236.PAA01298@baskerville.CS.Arizona.EDU> Subject: Re: I like IKE! Sender: owner-ipsec@ex.tis.com Precedence: bulk I do too, and remember the campaign fondly, but 0. The name has been changed from "The Resolution of ISAKMP with Oakley" to "The Internet Key Exchange (IKE)". is TIKE! Hilarie From owner-ipsec Mon Feb 16 19:20:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA24914 for ipsec-outgoing; Mon, 16 Feb 1998 19:20:01 -0500 (EST) Message-Id: <199802170030.TAA00745@relay.hq.tis.com> Date: Mon, 16 Feb 98 19:30:46 EST From: Karen Seo To: ipsec@tis.com cc: kseo@bbn.com Subject: duplicate drafts Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, My apologies if you get 2 copies of the AH and ESP drafts. I sent them to the mailing list on Friday (2/13). When none of my colleagues had received copies by the evening of 2/14, I resent them thinking maybe I'd somehow mistyped the address or something. At any rate, I apologize for any inconvenience this causes. Karen From owner-ipsec Mon Feb 16 19:57:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA25201 for ipsec-outgoing; Mon, 16 Feb 1998 19:57:05 -0500 (EST) Date: Mon, 16 Feb 1998 20:09:45 -0500 (EST) Message-Id: <199802170109.UAA11834@carp.morningstar.com> From: Ben Rogers To: dharkins@cisco.com, ipsec@tis.com Subject: Derivation of Phase 1 keying material Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk [I appologize if this as a re-send -- my mailer (and evidently the IPsec list) is confused .. ben] >From IO-RES Appendix B: Encryption keys used to protect the ISAKMP SA are derived from SKEYID_e in an algorithm-specific manner. When SKEYID_e is not long enough to supply all the necessary keying material an algorithm requires, the key is derived from feeding the results of a pseudo- random function into itself, concatenating the results, and taking the highest necessary bits. For example, if (ficticious) algorithm AKULA requires 320-bits of key (and has no weak key check) and the prf used to generate SKEYID_e only generates 120 bits of material, the key for AKULA, would be the first 320-bits of Ka, where: Ka = K1 | K2 | K3 and K1 = prf(SKEYID_e, 0) K2 = prf(SKEYID_e, K1) K3 = prf(SKEYID_e, K2) I'm not really clear as to what we do if SKEYID_e has enough bits to provide us with the encryption key we're looking for. Perhaps one of the following clarifications is appropriate? Encryption keys used to protect the ISAKMP SA are derived from SKEYID_e in an algorithm-specific manner. If SKEYID_e is long enough to supply the necessary keying material the algorithm requires, then it is used without modification. If it is not long enough, the key is derived from feeding the results of a pseudo-random function into itself, concatenating the results, and taking the highest necessary bits. For example,... or Encryption keys used to protect the ISAKMP SA are derived from SKEYID_e in an algorithm-specific manner. The key material is generated by taking the high order bits of the following string K: K = K1 | K2 | K3 | ... where K1 = prf(SKEYID_e, 0) KN+1 = prf(SKEYID_e, KN) and 0 is represented by a single octet. For example, if (ficticious) algorithm AKULA requires 320-bits of key (and has no weak key check) and the prf used to generate SKEYID_e only generates 120 bits of material, the key for AKULA, would be the first 320-bits of Ka, where: Ka = K1 | K2 | K3 and K1 = prf(SKEYID_e, 0) K2 = prf(SKEYID_e, K1) K3 = prf(SKEYID_e, K2) where prf is the negotiated prf or the HMAC version of the negotiated hash function. Each result of the prf provides 120 bits of material for a total of 360 bits. AKULA would use the first 320 bits of that 360 bit string. I'm also not certain to do in the case where the first 8 bytes of this keystring are weak. Do we instead take bytes 1-9, or bytes 9-16? Does anyone see the need to include the weak key check in 3DES-CBC? If so, do we not allow keys for which any of the DES keys is weak, or only keys where all three are weak? If the first is the case, shold we allow non-contiguous keys? (ie, if bytes 9-16 are a weak key, do I build my 3DES key from bytes 1-8, 17-24 and 25-32, or take the contiguous block of bytes 17-40 or 25-48?) ben From owner-ipsec Mon Feb 16 22:21:23 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA26102 for ipsec-outgoing; Mon, 16 Feb 1998 22:20:00 -0500 (EST) Message-Id: <199802170330.WAA02364@relay.hq.tis.com> To: Daniel Harkins cc: ipsec@tis.com Subject: Re: I like IKE! In-reply-to: Your message of "Fri, 13 Feb 1998 15:17:41 PST." <199802162206.RAA23787@portal.ex.tis.com> Date: Mon, 16 Feb 1998 19:31:46 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk I like IKE too! The following is the list of changes to the IPSEC DOI. Changes resulting from the document readings are marked with "[Washington IETF]". 1) Added the IANA considerations section which describes how the various magic numbers will be doled out once this goes to RFC. 2) Moved most of the various "reserved to IANA" values under the new IANA section. The only ones whichi remain are the specific attribute values, which remain with the attribute descriptions. 3) Added restriction on sending variable-length encodings for attributes that are listed as basic-only. [Washington IETF] 4) Added restriction on sending Key Length attribute for fixed-length key ciphers (e.g. DES). [Washtington IETF] 5) Changed the name of ISAKMP/Oakley to IKE throughout. 6) Renamed ESP_ARCFOUR to ESP_RC4, since that's what it really is. (All of the names in the DOI are just names, it's only the values that matter anyway.) 7) Tweaked the text in the security considerations section gratuitously. 8) Updated the document references, but not before all of these other documents had been posted to the list. Sigh. See y'all in Raleigh. (Go Heels!) Derrell From owner-ipsec Tue Feb 17 06:55:16 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA29089 for ipsec-outgoing; Tue, 17 Feb 1998 06:53:16 -0500 (EST) Message-Id: <199802171205.HAA25459@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-auth-hmac-ripemd-160-96-01.txt Date: Tue, 17 Feb 1998 07:05:20 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Use of HMAC-RIPEMD-160-96 within ESP and AH Author(s) : N. Provos Filename : draft-ietf-ipsec-auth-hmac-ripemd-160-96-01.txt Pages : 6 Date : 16-Feb-98 This draft describes the use of the HMAC algorithm [RFC-2104] in conjunction with the RIPEMD-160 algorithm [RIPEMD-160] as an authentication mechanism within the revised IPSEC Encapsulating Security Payload [ESP] and the revised IPSEC Authentication Header [AH]. HMAC with RIPEMD-160 provides data origin authentication and integrity protection. Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a]. 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-auth-hmac-ripemd-160-96-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-ripemd-160-96-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-auth-hmac-ripemd-160-96-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19980216141608.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-auth-hmac-ripemd-160-96-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-auth-hmac-ripemd-160-96-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980216141608.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Feb 17 07:29:38 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA29294 for ipsec-outgoing; Tue, 17 Feb 1998 07:29:08 -0500 (EST) Message-Id: <3.0.3.32.19980217073006.02f91b90@pop.hq.tis.com> X-Sender: johnk@pop.hq.tis.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 17 Feb 1998 07:30:06 -0500 To: ipsec@tis.com From: "John C. Kelley" Subject: Resend of I-Ds Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Due to a problem we experienced with our majordomo server on Friday, Feb 13, we had to resend a number of articles last night. During that resend, a series of Internet-Drafts were sent, with inappropriate To: lines due to the interpretation of the original To: line by our mailer. This has caused a number of receiving mailers to balk. To be sure that these are received by all ipsec list members, we are resending them. We apologize to those where this is a second copy and thus "noise." Thank you for your understanding. -John Kelley TIS Majordomo Administration -- John Kelley johnk@tis.com Director, Systems Administration Trusted Information Systems, Inc. (A NASDAQ company: "TISX") http://www.tis.com From owner-ipsec Tue Feb 17 07:44:52 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA29403 for ipsec-outgoing; Tue, 17 Feb 1998 07:44:07 -0500 (EST) Message-Id: <199802171244.HAA29403@portal.ex.tis.com> To: IETF-Announce@tis.com Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-auth-hmac-sha196-02.txt Date: Mon, 16 Feb 1998 09:01:21 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Use of HMAC-SHA-1-96 within ESP and AH Author(s) : C. Madson, R. Glenn Filename : draft-ietf-ipsec-auth-hmac-sha196-02.txt Pages : 5 Date : 13-Feb-98 This draft describes the use of the HMAC algorithm [RFC-2104] in conjunction with the SHA-1 algorithm [FIPS-180-1] as an authentication mechanism within the revised IPSEC Encapsulating Security Payload [ESP] and the revised IPSEC Authentication Header [AH]. HMAC with SHA-1 provides data origin authentication and integrity protection. Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a]. 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-auth-hmac-sha196-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-sha196-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-auth-hmac-sha196-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: <19980213151552.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-auth-hmac-sha196-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-auth-hmac-sha196-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980213151552.I-D@ietf.org> --OtherAccess-- --NextPart-- -- John Kelley johnk@tis.com Director, Systems Administration Trusted Information Systems, Inc. (A NASDAQ company: "TISX") http://www.tis.com From owner-ipsec Tue Feb 17 07:45:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA29425 for ipsec-outgoing; Tue, 17 Feb 1998 07:45:09 -0500 (EST) Message-Id: <199802171245.HAA29425@portal.ex.tis.com> To: IETF-Announce@tis.com Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-esp-v2-03.txt Date: Mon, 16 Feb 1998 09:04:46 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IP Encapsulating Security Payload (ESP) Author(s) : S. Kent, R. Atkinson Filename : draft-ietf-ipsec-esp-v2-03.txt Pages : 21 Date : 13-Feb-98 The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-esp-v2-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v2-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-esp-v2-03.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: <19980213162537.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-v2-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-v2-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980213162537.I-D@ietf.org> --OtherAccess-- --NextPart-- -- John Kelley johnk@tis.com Director, Systems Administration Trusted Information Systems, Inc. (A NASDAQ company: "TISX") http://www.tis.com From owner-ipsec Tue Feb 17 07:45:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA29424 for ipsec-outgoing; Tue, 17 Feb 1998 07:45:09 -0500 (EST) Message-Id: <199802171245.HAA29424@portal.ex.tis.com> To: IETF-Announce@tis.com Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-auth-hmac-md5-96-02.txt Date: Mon, 16 Feb 1998 09:01:13 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Use of HMAC-MD5-96 within ESP and AH Author(s) : C. Madson, R. Glenn Filename : draft-ietf-ipsec-auth-hmac-md5-96-02.txt Pages : 6 Date : 13-Feb-98 This draft describes the use of the HMAC algorithm [RFC-2104] in conjunction with the MD5 algorithm [RFC-1321] as an authentication mechanism within the revised IPSEC Encapsulating Security Payload [ESP] and the revised IPSEC Authentication Header [AH]. HMAC with MD5 provides data origin authentication and integrity protection. Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a]. 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-auth-hmac-md5-96-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-md5-96-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-auth-hmac-md5-96-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: <19980213151513.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-auth-hmac-md5-96-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-auth-hmac-md5-96-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980213151513.I-D@ietf.org> --OtherAccess-- --NextPart-- -- John Kelley johnk@tis.com Director, Systems Administration Trusted Information Systems, Inc. (A NASDAQ company: "TISX") http://www.tis.com From owner-ipsec Tue Feb 17 07:46:12 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA29445 for ipsec-outgoing; Tue, 17 Feb 1998 07:46:08 -0500 (EST) Message-Id: <199802171246.HAA29445@portal.ex.tis.com> To: IETF-Announce@tis.com Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-oakley-06.txt Date: Mon, 16 Feb 1998 09:06:51 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Internet Key Exchange (IKE) Author(s) : D. Carrel, D. Harkins Filename : draft-ietf-ipsec-isakmp-oakley-06.txt Pages : 39 Date : 13-Feb-98 [MSST97] (ISAKMP) provides a framework for authentication and key exchange but does not define them. ISAKMP is designed to be key exchange independant; that is, it is designed to support many different key exchanges. [Orm96] (Oakley) describes a series of key exchanges-- called ''modes''-- and details the services provided by each (e.g. perfect forward secrecy for keys, identity protection, and authentication). [Kra96] (SKEME) describes a versatile key exchange technique which provides anonymity, repudiability, and quick key refreshment. This document describes a protocol using part of Oakley and part of SKEME in conjunction with ISAKMP to obtain authenticated keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-isakmp-oakley-06.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-oakley-06.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-isakmp-oakley-06.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: <19980213183154.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-oakley-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-oakley-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980213183154.I-D@ietf.org> --OtherAccess-- --NextPart-- -- John Kelley johnk@tis.com Director, Systems Administration Trusted Information Systems, Inc. (A NASDAQ company: "TISX") http://www.tis.com From owner-ipsec Tue Feb 17 07:47:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA29466 for ipsec-outgoing; Tue, 17 Feb 1998 07:47:08 -0500 (EST) Message-Id: <199802171247.HAA29466@portal.ex.tis.com> To: IETF-Announce@tis.com Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-auth-header-04.txt Date: Mon, 16 Feb 1998 09:04:39 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IP Authentication Header Author(s) : S. Kent, R. Atkinson Filename : draft-ietf-ipsec-auth-header-04.txt Pages : 23 Date : 13-Feb-98 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, by the receiver, when a Security Association is established. (Although the default calls for the sender to increment the Sequence Number used for anti-replay, the service is effective only if the receiver checks the Sequence Number.) 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 sender. 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 ''Security Architecture for the Internet Protocol'' [KA97a], hereafter referred to as the Security Architecture document). 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 a confidentiality (encryption) service. The primary difference between the authentication provided by ESP and AH is the extent of the coverage. Specifically, ESP does not protect any IP header fields unless those fields are encapsulated by ESP (tunnel mode). For more details on how to use AH and ESP in various network environments, see the Security Architecture document [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-auth-header-04.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-auth-header-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-auth-header-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19980213162516.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-auth-header-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-auth-header-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980213162516.I-D@ietf.org> --OtherAccess-- --NextPart-- -- John Kelley johnk@tis.com Director, Systems Administration Trusted Information Systems, Inc. (A NASDAQ company: "TISX") http://www.tis.com From owner-ipsec Tue Feb 17 07:47:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA29467 for ipsec-outgoing; Tue, 17 Feb 1998 07:47:09 -0500 (EST) Message-Id: <199802171247.HAA29467@portal.ex.tis.com> To: IETF-Announce@tis.com Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ciph-des-expiv-02.txt Date: Mon, 16 Feb 1998 09:07:16 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The ESP DES-CBC Cipher Algorithm With Explicit IV Author(s) : N. Doraswamy, C. Madson Filename : draft-ietf-ipsec-ciph-des-expiv-02.txt Pages : 8 Date : 13-Feb-98 This document describes the use of the DES Cipher algorithm in Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPSec Encapsulating Security Payload (ESP). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ciph-des-expiv-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-des-expiv-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-ciph-des-expiv-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: <19980213194700.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-des-expiv-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-des-expiv-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980213194700.I-D@ietf.org> --OtherAccess-- --NextPart-- -- John Kelley johnk@tis.com Director, Systems Administration Trusted Information Systems, Inc. (A NASDAQ company: "TISX") http://www.tis.com From owner-ipsec Tue Feb 17 07:48:11 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA29489 for ipsec-outgoing; Tue, 17 Feb 1998 07:48:07 -0500 (EST) Message-Id: <199802171248.HAA29489@portal.ex.tis.com> To: IETF-Announce@tis.com Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ipsec-doi-07.txt Date: Mon, 16 Feb 1998 09:07:07 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Internet IP Security Domain of Interpretation for ISAKMP Author(s) : D. Piper Filename : draft-ietf-ipsec-ipsec-doi-07.txt Pages : 29 Date : 13-Feb-98 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, payloads, and processing guidelines that occur within a given Domain of Interpretation (DOI). This document defines the Internet IP Security DOI (IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate security associations. For a description of how the IPSEC DOI fits into the overall IP Security Documentation framework, please see [ROADMAP]. For a list of changes since the previous version of the IPSEC DOI, please see Section 5. 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-07.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-ipsec-doi-07.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-07.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19980213191256.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ipsec-doi-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ipsec-doi-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980213191256.I-D@ietf.org> --OtherAccess-- --NextPart-- -- John Kelley johnk@tis.com Director, Systems Administration Trusted Information Systems, Inc. (A NASDAQ company: "TISX") http://www.tis.com From owner-ipsec Tue Feb 17 12:09:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA02005 for ipsec-outgoing; Tue, 17 Feb 1998 12:07:18 -0500 (EST) Date: Tue, 17 Feb 1998 12:20:23 -0500 From: "D. Hugh Redelmeier" To: IETF-Announce@tis.com cc: ipsec@tis.com Subject: Re: I-D ACTION:draft-ietf-ipsec-ipsec-doi-07.txt In-Reply-To: <199802171248.HAA29489@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 Mon, 16 Feb 1998 Internet-Drafts@ns.ietf.org wrote: | For a list of changes since the previous version of the IPSEC DOI, | please see Section 5. It turns out that the lists of changes are in section 7. Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253 From owner-ipsec Tue Feb 17 21:34:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA25699 for ipsec-outgoing; Tue, 17 Feb 1998 21:29:28 -0500 (EST) Date: Tue, 17 Feb 1998 21:38:16 -0600 (CST) From: Engineering To: ipsec@tis.com Subject: Re: Help - Details on March 2nd worshop at Raliegh requested ... In-Reply-To: <3.0.5.32.19980216062241.009c77c0@homebase.htt-consult.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > >> > What about firewall configurations ? > >> > >Interoperabilty with NAT... > > That is too broad a statement for a workshop. What senarios and tests > would you recommend? > Configurations: 1) Remote access client (dial up through an ISP) a) IPSEC Gateway configured with an inside address behind a firewall. b) IPSEC Gateway configured with an outside address, unprotected by the firewall, but packets passed on to a node on the other side of the firewall. c) User Authentication issues ?? d) Proxy Server ? 2) LAN Client a) configured with an inside address b) configured with an outside address c) multiple gateways on the same subnet Scenarios: a) Remote access, SA secures everything between two endpoints. b) Remote access, SA secures specific protocols/ports. Firewall also protects these ports. c) Firewall multiplexes inside sessions over a single outside ip address. Tests: a) icmp,http,ftp,smtp,pop3,udp b) shared drives and printers with uSoft NETBUI over TCP c) keep athentication,encryption,compression constant for simplicity This may not be applicable for the workshop, you tell me. I don't know how many people are prepared to run these tests either. Thanks, Jeffrey Goodwin ** Ashley Laurent,Inc. ** Software Development ** Consulting ** * * * * 707 West Avenue, Suite 201 * voice: 512-322-0676 * * Austin, Texas 78701 * fax : 512-322-0680 * * web: http://www.osgroup.com * * Microsoft Solution Provider * Complete Systems Design/Development * * Novell Professional Developer * Systems Software/Device Drivers * From owner-ipsec Tue Feb 17 23:22:32 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA02943 for ipsec-outgoing; Tue, 17 Feb 1998 23:21:28 -0500 (EST) Message-ID: <007701bd3c26$84eeaca0$238a9ccc@ramesh.redcreek> From: "Ramesh Kamath" To: Subject: Cisco Implementation Date: Tue, 17 Feb 1998 20:34:36 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0074_01BD3BE3.76991200" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@ex.tis.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0074_01BD3BE3.76991200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 In the latest Cisco implementation of ISAKMP source code,=20 =20 Why is that the ESP encapsulation attribute set based on the = proxy_dst.sin_family !=3D 0. This is the piece of code from oakley.c.=20 =20 if (sa->proxy_dst.sin_family !=3D 0){ sa_ipsec->other_sa.esp.tunnel =3D 1; } =20 if proxy_dst.sin_family is equal to 0, then it is neither tunnel or = transport. So what is ESP Encapsulation mode in that case. =20 The place sa->proxy_dst is set in the function initiator, if (proxy_dst && proxy_dst->sin_family =3D=3D AF_INET) bcopy(proxy_dst, &security_assoc->proxy_dst, sizeof(struct = sockaddr_in)); but the function is passed NULL for proxy_dst =20 Can you please give me some help here.=20 =20 Thanks Ramesh ------------------------------------------------------------- Ramesh Kamath RedCreek Communications Inc, 3900 Newpark Mall Road Newark, CA 94560 (510) 745 3974 Fax (510) 745 3999 ----------------------------------------------------------- ------=_NextPart_000_0074_01BD3BE3.76991200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,
 
In the latest Cisco implementation = of ISAKMP=20 source code,
 
Why is that the ESP encapsulation = attribute set=20 based on the proxy_dst.sin_family !=3D 0. This is the piece of code from = oakley.c.=20
 
 if (sa->proxy_dst.sin_family !=3D=20 0){
     sa_ipsec->other_sa.esp.tunnel =3D=20 1;
 }
 
if proxy_dst.sin_family is equal to 0, then it is = neither=20 tunnel or transport. So what is ESP Encapsulation mode in that=20 case.
 
The place sa->proxy_dst is = set in the=20 function initiator,
    if (proxy_dst &&=20 proxy_dst->sin_family =3D=3D=20 AF_INET)
         = bcopy(proxy_dst,=20 &security_assoc->proxy_dst, sizeof(struct = sockaddr_in));
but the function is passed NULL for proxy_dst
 
Can you please give me some help here.
 
Thanks
Ramesh
 
-------------------------------------------------------------Ramesh=20 Kamath
RedCreek Communications Inc,
3900 Newpark Mall = Road
Newark, CA=20 94560
(510) 745 3974  Fax (510) 745=20 3999
-----------------------------------------------------------
------=_NextPart_000_0074_01BD3BE3.76991200-- From owner-ipsec Wed Feb 18 07:51:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA21789 for ipsec-outgoing; Wed, 18 Feb 1998 07:47:21 -0500 (EST) Message-Id: <199802181255.HAA17107@ghostwheel.ncsl.nist.gov> Date: Wed, 18 Feb 1998 07:55:09 -0500 (EST) To: ipsec@tis.com From: rob.glenn@nist.gov Subject: three more changes to HMAC-MD5-96 & HMAC-SHA1-96 spec X-Mailer: Ishmail 1.3.2-970722-linux MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk After receiving comments from Bart Preneel and Hugo Krawczyk and having an e-mail discussion with Hugo over the weekend, the following changes have been made. 1). Change "no known cryptographic attacks" to no practical cryptographic attacks. 2). Move paragraph 6 in section 3 to paragraph 2 of section 5 which is a followup discussion on the "no practical" part from above. 3). Replace the last paragraph in section 3 with (taken almost directly from [RFC-2104]): [RFC-2104] makes the following recommendation with regard to rekeying. Current attacks do not indicate a specific recommended frequency for key changes as these attacks are practically infeasible. However, periodic key refreshment is a fundamental security practice that helps against potential weaknesses of the function and keys, reduces the information avaliable to a cryptanalyst, and limits the damage of an exposed key. The new drafts should be online in the next couple days. Rob G. rob.glenn@nist.gov From owner-ipsec Wed Feb 18 18:40:52 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA02064 for ipsec-outgoing; Wed, 18 Feb 1998 18:37:37 -0500 (EST) Date: Wed, 18 Feb 1998 18:50:29 -0500 Message-Id: <199802182350.SAA14498@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: IPSEC WORKING GROUP LAST CALL Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi all, Bob and I am initiating working group last call on the following documents: Last Modified Draft Name Jul 25 1997 draft-ietf-ipsec-oakley-02.txt Jul 28 1997 draft-ietf-ipsec-isakmp-08.txt Feb 13 1998 draft-ietf-ipsec-isakmp-oakley-06.txt Feb 16 1998 draft-ietf-ipsec-ipsec-doi-07.txt Feb 13 1998 draft-ietf-ipsec-auth-header-04.txt Feb 13 1998 draft-ietf-ipsec-esp-v2-03.txt Feb 18 1998 draft-ietf-ipsec-auth-hmac-md5-96-03.txt Feb 18 1998 draft-ietf-ipsec-auth-hmac-sha196-03.txt Feb 14 1998 draft-ietf-ipsec-ciph-des-expiv-02.txt This last call will last one week (until February 25, 1998), at which point they will go to IETF last call. These documents represent all of the core IPSEC documents except for the architecture and roadmap documents. These last two will go to working group last call as soon as they are ready. I'd like to take this opportunity to thank all those people who have worked hard on the IPSEC drafts, as document editors, document reviewers, implementors, or some combination of the above. We only have a little bit more work ahead of us before we're completely done with this round of the documents. Thanks again for your hard work. - Ted From owner-ipsec Wed Feb 18 19:07:46 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA02310 for ipsec-outgoing; Wed, 18 Feb 1998 19:07:34 -0500 (EST) Date: Wed, 18 Feb 1998 19:20:16 -0500 (EST) Message-Id: <199802190020.TAA17054@carp.morningstar.com> From: Ben Rogers To: "Theodore Y. Ts'o" Cc: ipsec@tis.com Subject: IPSEC WORKING GROUP LAST CALL In-Reply-To: <199802182350.SAA14498@dcl.MIT.EDU> References: <199802182350.SAA14498@dcl.MIT.EDU> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Theodore Y. Ts'o writes: > > Hi all, > > Bob and I am initiating working group last call on the following > documents: > > > Last Modified Draft Name > > Jul 25 1997 draft-ietf-ipsec-oakley-02.txt > Jul 28 1997 draft-ietf-ipsec-isakmp-08.txt > Feb 13 1998 draft-ietf-ipsec-isakmp-oakley-06.txt >From IKE Appendix B: Encryption keys used to protect the ISAKMP SA are derived from SKEYID_e in an algorithm-specific manner. When SKEYID_e is not long enough to supply all the necessary keying material an algorithm requires, the key is derived from feeding the results of a pseudo- random function into itself, concatenating the results, and taking the highest necessary bits. For example, if (ficticious) algorithm AKULA requires 320-bits of key (and has no weak key check) and the prf used to generate SKEYID_e only generates 120 bits of material, the key for AKULA, would be the first 320-bits of Ka, where: Ka = K1 | K2 | K3 and K1 = prf(SKEYID_e, 0) K2 = prf(SKEYID_e, K1) K3 = prf(SKEYID_e, K2) I'm not really clear as to what we do if SKEYID_e has enough bits to provide us with the encryption key we're looking for. Perhaps one of the following clarifications is appropriate? (Without the clarification, there exists a definite ambiuity). Encryption keys used to protect the ISAKMP SA are derived from SKEYID_e in an algorithm-specific manner. If SKEYID_e is long enough to supply the necessary keying material the algorithm requires, then it is used without modification. If it is not long enough, the key is derived from feeding the results of a pseudo-random function into itself, concatenating the results, and taking the highest necessary bits. For example,... or Encryption keys used to protect the ISAKMP SA are derived from SKEYID_e in an algorithm-specific manner. The key material is generated by taking the high order bits of the following string K: K = K1 | K2 | K3 | ... where K1 = prf(SKEYID_e, 0) KN+1 = prf(SKEYID_e, KN) and 0 is represented by a single octet. For example, if (ficticious) algorithm AKULA requires 320-bits of key (and has no weak key check) and the prf used to generate SKEYID_e only generates 120 bits of material, the key for AKULA, would be the first 320-bits of Ka, where: Ka = K1 | K2 | K3 and K1 = prf(SKEYID_e, 0) K2 = prf(SKEYID_e, K1) K3 = prf(SKEYID_e, K2) where prf is the negotiated prf or the HMAC version of the negotiated hash function. Each result of the prf provides 120 bits of material for a total of 360 bits. AKULA would use the first 320 bits of that 360 bit string. I'm also not certain to do in the case where the first 8 bytes of this keystring are weak. Do we instead take bytes 1-9, or bytes 9-16? Does anyone see the need to include the weak key check in 3DES-CBC? If so, do we not allow keys for which any of the DES keys is weak, or only keys where all three are weak? If the first is the case, shold we allow non-contiguous keys? (ie, if bytes 9-16 are a weak key, do I build my 3DES key from bytes 1-8, 17-24 and 25-32, or take the contiguous block of bytes 17-40 or 25-48?) ben From owner-ipsec Wed Feb 18 19:17:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA02396 for ipsec-outgoing; Wed, 18 Feb 1998 19:17:34 -0500 (EST) Message-Id: <199802190030.QAA00233@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: "Theodore Y. Ts'o" Cc: ipsec@tis.com Subject: Re: IPSEC WORKING GROUP LAST CALL In-Reply-To: Your message of "Wed, 18 Feb 1998 18:50:29 EST." <199802182350.SAA14498@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 18 Feb 1998 16:30:12 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk > Bob and I am initiating working group last call on the following > documents: > > > Last Modified Draft Name > > Jul 25 1997 draft-ietf-ipsec-oakley-02.txt > Jul 28 1997 draft-ietf-ipsec-isakmp-08.txt So this means that the base ISAKMP draft wasn't rev'd? That means that one of the issues from the document reading party wasn't addressed. The ISAKMP+IKE+DOI clique at the party came up with the following issue: 1. DOI of 0 in phase 1 says to use the ID semantics from the base ISAKMP draft but the base ISAKMP draft doesn't define any semantics. A minimal set of ID types has to be added to the base ISAKMP draft. Version -08 doesn't have this minimal set. Also, various vendors have in the past requested a Vendor ID payload which would carry some opaque blob. This also hasn't been added. Doug, can you make another rev of the base ISAKMP draft and address these two issues? The 1st one is critical the 2nd is merely very important. thanks, Dan. P.S. ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-08.txt has the date of Jul 26, 1997 so I hope I'm looking at the right one. From owner-ipsec Wed Feb 18 19:25:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA02454 for ipsec-outgoing; Wed, 18 Feb 1998 19:25:39 -0500 (EST) Date: Wed, 18 Feb 1998 19:38:22 -0500 (EST) Message-Id: <199802190038.TAA17070@carp.morningstar.com> From: Ben Rogers To: ipsec@tis.com Subject: Inconsistencies/Problems I have seen... Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk I've found the following in the past week (I don't mean to pick on you, Dan, it is just that I'm knee deep in coding ISAKMP right now, and your document needs to be referred to a lot): IKE Appendix B: The key for DES-CBC is derived from the first eight (8) non-weak and non-semi-weak (see Appendix A) bytes of SKEYID_e. The IV is the first 8 bytes of the IV material derived above. Does this mean that if bytes 1-8 are weak, we look at bytes 2-9 or bytes 9-16? If we have more weak keys than SKEYID_e has bytes, what do we look at next? This whole section on key generation needs to be cleaned up. It makes certain assumptions about prf or hash output sizes which might not necessarily correct. Please pick the correct text from my previous email and match it with the following type of change in the section describing key derivation: The key for DES-CBC is derived from the first eight (8) non-weak and non-semi-weak (see Appendix A) bytes of SKEYID_e. (Using bytes n+8 through n+16 in the event that bytes n through n+7 are weak). If SKEYID_e does not contain enough keying material for this operation, the first eight non-weak bytes of the extended key material described above are used. The IV is the first 8 bytes of the IV material derived above. or The key for DES-CBC is derived from the first eight (8) non-weak and non-semi-weak (see Appendix A) bytes of the keying material mentioned above. (Using bytes n+8 through n+16 in the event that bytes n through n+7 are weak). The IV is the first 8 bytes of the IV material derived above. ben From owner-ipsec Wed Feb 18 19:31:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA02503 for ipsec-outgoing; Wed, 18 Feb 1998 19:31:34 -0500 (EST) Message-Id: <199802190043.QAA19582@weenie.redbacknetworks.com> To: ben@Ascend.COM (Ben Rogers) cc: "Theodore Y. Ts'o" , ipsec@tis.com Subject: Re: IPSEC WORKING GROUP LAST CALL In-reply-to: Your message of "Wed, 18 Feb 1998 19:20:16 EST." <199802190020.TAA17054@carp.morningstar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19579.887849013.1@RedBackNetworks.com> Date: Wed, 18 Feb 1998 16:43:33 -0800 From: David Carrel Sender: owner-ipsec@ex.tis.com Precedence: bulk > Encryption keys used to protect the ISAKMP SA are derived from > SKEYID_e in an algorithm-specific manner. When SKEYID_e is not long > enough to supply all the necessary keying material an algorithm > requires, the key is derived from feeding the results of a pseudo- > random function into itself, concatenating the results, and taking > the highest necessary bits. > > For example, if (ficticious) algorithm AKULA requires 320-bits of key > (and has no weak key check) and the prf used to generate SKEYID_e > only generates 120 bits of material, the key for AKULA, would be the > first 320-bits of Ka, where: > > Ka = K1 | K2 | K3 > and > K1 = prf(SKEYID_e, 0) > K2 = prf(SKEYID_e, K1) > K3 = prf(SKEYID_e, K2) > > I'm not really clear as to what we do if SKEYID_e has enough bits to > provide us with the encryption key we're looking for. Perhaps one of > the following clarifications is appropriate? (Without the > clarification, there exists a definite ambiuity). What's unclear!!?? It says quite succinctly "When SKEYID_e is not long enough to supply all the necessary keying material ...". So do this when it's not long enough. DO NOT do this when it is. > Encryption keys used to protect the ISAKMP SA are derived from > SKEYID_e in an algorithm-specific manner. If SKEYID_e is long enough > to supply the necessary keying material the algorithm requires, then > it is used without modification. If it is not long enough, the key > is derived from feeding the results of a pseudo-random function into > itself, concatenating the results, and taking the highest necessary > bits. > > For example,... > > or > > Encryption keys used to protect the ISAKMP SA are derived from > SKEYID_e in an algorithm-specific manner. The key material is > generated by taking the high order bits of the following string K: > > K = K1 | K2 | K3 | ... > where > K1 = prf(SKEYID_e, 0) > KN+1 = prf(SKEYID_e, KN) > > and 0 is represented by a single octet. > > For example, if (ficticious) algorithm AKULA requires 320-bits of key > (and has no weak key check) and the prf used to generate SKEYID_e > only generates 120 bits of material, the key for AKULA, would be the > first 320-bits of Ka, where: > > Ka = K1 | K2 | K3 > and > K1 = prf(SKEYID_e, 0) > K2 = prf(SKEYID_e, K1) > K3 = prf(SKEYID_e, K2) > > where prf is the negotiated prf or the HMAC version of the negotiated > hash function. Each result of the prf provides 120 bits of material > for a total of 360 bits. AKULA would use the first 320 bits of that > 360 bit string. > > I'm also not certain to do in the case where the first 8 bytes of this > keystring are weak. Do we instead take bytes 1-9, or bytes 9-16? Does > anyone see the need to include the weak key check in 3DES-CBC? If so, > do we not allow keys for which any of the DES keys is weak, or only keys > where all three are weak? If the first is the case, shold we allow > non-contiguous keys? (ie, if bytes 9-16 are a weak key, do I build my > 3DES key from bytes 1-8, 17-24 and 25-32, or take the contiguous block > of bytes 17-40 or 25-48?) That is an algorithm specific issue. What's weak??? That is not something that IKE can determine without knowing every encryption algorithm. What is an acceptable fallback when it is weak??? That is also something that IKE should not know. The question of 3DES has been beaten to death. Please see the archives. For algorithm specific weak key checks, please refer to the appropriate document. Dave From owner-ipsec Wed Feb 18 19:35:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA02541 for ipsec-outgoing; Wed, 18 Feb 1998 19:35:34 -0500 (EST) Message-Id: <199802190048.QAA00286@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: ben@Ascend.COM (Ben Rogers) Cc: "Theodore Y. Ts'o" , ipsec@tis.com Subject: Re: IPSEC WORKING GROUP LAST CALL In-Reply-To: Your message of "Wed, 18 Feb 1998 19:20:16 EST." <199802190020.TAA17054@carp.morningstar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 18 Feb 1998 16:48:34 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Ben, If you read a bit further down in Appendix B of IKE it will tell you how to obtain the key out of the blob of bits. For instance: The key for IDEA-CBC is derived from the first sixteen (16) bytes of SKEYID_e. The IV is the first eight (8) bytes of the IV material derived above. The key for Blowfish-CBC is either the negotiated key size, or the first fifty-six (56) bytes of a key (if no key size is negotiated) derived in the aforementioned pseudo-random function feedback method. The IV is the first eight (8) bytes of the IV material derived above. if you're doing IDEA or Blowfish. The blob of bits is either SKEYID_e directly or the result of the feedback mechanism. It's all there in Appendix B. I included a weak key check for the mandatory-to-implement encryption algorithm but not the others. Since it is mandatory to implement I felt it was necessary to note the weak keys. Based on the lack of responses to your 3 postings of this message I guess no one else wants to add discussions on weak keys for other optional encryption algorithms. There are quite a few independent implementations of IKE (yes, with multiple encryption algorithm support too!) around so the text in Appendix B is probably clear enough. It could always be made better, but a decent enough clarity test is whether more that, say five, people can read it and all interpret it the same way. They did and they have. Dan. > >From IKE Appendix B: > > Encryption keys used to protect the ISAKMP SA are derived from > SKEYID_e in an algorithm-specific manner. When SKEYID_e is not long > enough to supply all the necessary keying material an algorithm > requires, the key is derived from feeding the results of a pseudo- > random function into itself, concatenating the results, and taking > the highest necessary bits. > > For example, if (ficticious) algorithm AKULA requires 320-bits of key > (and has no weak key check) and the prf used to generate SKEYID_e > only generates 120 bits of material, the key for AKULA, would be the > first 320-bits of Ka, where: > > Ka = K1 | K2 | K3 > and > K1 = prf(SKEYID_e, 0) > K2 = prf(SKEYID_e, K1) > K3 = prf(SKEYID_e, K2) > > I'm not really clear as to what we do if SKEYID_e has enough bits to > provide us with the encryption key we're looking for. Perhaps one of > the following clarifications is appropriate? (Without the > clarification, there exists a definite ambiuity). > > Encryption keys used to protect the ISAKMP SA are derived from > SKEYID_e in an algorithm-specific manner. If SKEYID_e is long enough > to supply the necessary keying material the algorithm requires, then > it is used without modification. If it is not long enough, the key > is derived from feeding the results of a pseudo-random function into > itself, concatenating the results, and taking the highest necessary > bits. > > For example,... > > or > > Encryption keys used to protect the ISAKMP SA are derived from > SKEYID_e in an algorithm-specific manner. The key material is > generated by taking the high order bits of the following string K: > > K = K1 | K2 | K3 | ... > where > K1 = prf(SKEYID_e, 0) > KN+1 = prf(SKEYID_e, KN) > > and 0 is represented by a single octet. > > For example, if (ficticious) algorithm AKULA requires 320-bits of key > (and has no weak key check) and the prf used to generate SKEYID_e > only generates 120 bits of material, the key for AKULA, would be the > first 320-bits of Ka, where: > > Ka = K1 | K2 | K3 > and > K1 = prf(SKEYID_e, 0) > K2 = prf(SKEYID_e, K1) > K3 = prf(SKEYID_e, K2) > > where prf is the negotiated prf or the HMAC version of the negotiated > hash function. Each result of the prf provides 120 bits of material > for a total of 360 bits. AKULA would use the first 320 bits of that > 360 bit string. > > I'm also not certain to do in the case where the first 8 bytes of this > keystring are weak. Do we instead take bytes 1-9, or bytes 9-16? Does > anyone see the need to include the weak key check in 3DES-CBC? If so, > do we not allow keys for which any of the DES keys is weak, or only keys > where all three are weak? If the first is the case, shold we allow > non-contiguous keys? (ie, if bytes 9-16 are a weak key, do I build my > 3DES key from bytes 1-8, 17-24 and 25-32, or take the contiguous block > of bytes 17-40 or 25-48?) > > > ben From owner-ipsec Wed Feb 18 21:42:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA03530 for ipsec-outgoing; Wed, 18 Feb 1998 21:37:37 -0500 (EST) Date: Thu, 19 Feb 1998 04:50:11 +0200 (EET) Message-Id: <199802190250.EAA15900@pilari.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Daniel Harkins Cc: "Theodore Y. Ts'o" , ipsec@tis.com Subject: Re: IPSEC WORKING GROUP LAST CALL In-Reply-To: <199802190030.QAA00233@dharkins-ss20.cisco.com> References: <199802182350.SAA14498@dcl.MIT.EDU> <199802190030.QAA00233@dharkins-ss20.cisco.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 5 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Daniel Harkins writes: > > Jul 28 1997 draft-ietf-ipsec-isakmp-08.txt > So this means that the base ISAKMP draft wasn't rev'd? That means that > one of the issues from the document reading party wasn't addressed. How about the certificate request payload? There was some talk about simplifying it so that it would only contain one type / CA and in case of multiple types / CA's the negotiation would just have multiple certitificate request payloads. > Also, various vendors have in the past requested a Vendor ID payload > which would carry some opaque blob. This also hasn't been added. I think that vendor ID payload is very important because otherwise there really isn't any use for private attributes in SA etc, because there is no way to know who's private extensions they unless you use some out of band configuration data to tell the other end's isakmp vendor. -- kivinen@iki.fi Work : +358-9-4354 3207 Magnus Enckellin kuja 9 K 19, 02610, Espoo Home : +358-9-502 1573 From owner-ipsec Thu Feb 19 03:57:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA05758 for ipsec-outgoing; Thu, 19 Feb 1998 03:54:36 -0500 (EST) Message-Id: X-Sender: ljopop@ranier.altavista-software.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 18 Feb 1998 20:29:29 -0500 To: Naganand Doraswamy From: Matt Thomas Subject: Re: ISAKMP alignment question Cc: ipsec@tis.com In-Reply-To: <3.0.32.19980127180907.00adc2a4@bl-mail1.corpeast.baynetwor ks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 06:09 PM 1/27/98 , Naganand Doraswamy wrote: >Shawn, >As the document clearly says messages, I would assume that individual >payloads do not need aligment and I would assume that the transform payload >would immediatly start after the CPI. However, in the Notify payload the SPI is padded to a 32-bit boundary. Not doing so in the Proposal payload may be a oversight (I think it is). Changing this now only affects IPPCP proposals and so it's not painful to make the change. Not that I understand how a message must be aligned to a 4 byte boundary. Since a message starts at 0, it's always _aligned_ by definition. I have an issue with alignment of ISAKMP attributes. Instead of the somewhat strange description, I'd rather see that the Attibute Tag must start on a 32 bit boundary (pad with 0s if not). It achieves the same result (the value starting a 4 byte boundary). If in compact format (no length), the value doesn't need to be on a 4 byte boundary since it's a 2 byte quantity. [i hate making this proposal now but I haven't seen an updated draft in a long time.] Just my 2 cents... -- Matt Thomas Internet: matt.thomas@altavista-software.com Internet Locksmith WWW URL: AltaVista Internet Software Disclaimer: This message reflects my own Littleton, MA warped views, etc. From owner-ipsec Thu Feb 19 03:57:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA05757 for ipsec-outgoing; Thu, 19 Feb 1998 03:54:36 -0500 (EST) Message-Id: X-Sender: altapop@ranier.altavista-software.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 18 Feb 1998 20:57:44 -0500 To: ipsec@tis.com From: Matt Thomas Subject: Any timeframe for a new draft-ietf-ipsec-isakmp? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk The last draft was submitted before Munich in July. Considering the discussions on this list and the isakmp-oakley list, I would like to see a new draft before seeing it complete last call. Any idea when we can read a isakmp draft? -- Matt Thomas Internet: matt@ljo.dec.com AltaVista Internet Software WWW URL: Digital Equipment Corporation Disclaimer: This message reflects my own Littleton, MA warped views, etc. From owner-ipsec Thu Feb 19 04:16:11 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA05885 for ipsec-outgoing; Thu, 19 Feb 1998 04:13:34 -0500 (EST) Message-Id: <3.0.1.32.19980219103304.008699b0@pop3.intranet.ts.es> X-Sender: fvega@pop3.intranet.ts.es X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Thu, 19 Feb 1998 10:33:04 -0100 To: ipsec@tis.com From: "Fernando Vega Viejo" Subject: Interoperability between IPv6 and IPv4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello everyone: I have one doubt about the interoperability between IPv6 and IPv4 when using IPSEc. Is it possible to communicate two machines, one using IPSEC and IPv6 and the other using IPSEC and IPv4? The machine running IPv6 would translate the address format into a IPv4 format. An example of this scenario could be a machine running IBM AIX 4.3 (it incorporates IPSec within its IPv6) and any IPSec IPv4 compliant device. Thanks in advance, Fernando Vega From owner-ipsec Thu Feb 19 04:17:46 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA05907 for ipsec-outgoing; Thu, 19 Feb 1998 04:17:36 -0500 (EST) Message-Id: <199802190928.EAA21842@tecumseh.altavista-software.com> X-Sender: ljopop@ranier.altavista-software.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 19 Feb 1998 04:26:18 -0500 To: "Theodore Y. Ts'o" From: Matt Thomas Subject: Re: IPSEC WORKING GROUP LAST CALL Cc: ipsec@tis.com In-Reply-To: <199802182350.SAA14498@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 06:50 PM 2/18/98 , Theodore Y. Ts'o wrote: > >Hi all, > >Bob and I am initiating working group last call on the following >documents: > > > Last Modified Draft Name > > Jul 25 1997 draft-ietf-ipsec-oakley-02.txt > Jul 28 1997 draft-ietf-ipsec-isakmp-08.txt A new revision of this draft is definitely called for. There are a number of outstanding issues which need to be addressed in a revised draft. -- Matt Thomas Internet: matt.thomas@altavista-software.com Internet Locksmith WWW URL: AltaVista Internet Software Disclaimer: This message reflects my own Littleton, MA warped views, etc. From owner-ipsec Thu Feb 19 12:28:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA09596 for ipsec-outgoing; Thu, 19 Feb 1998 12:25:44 -0500 (EST) Date: Thu, 19 Feb 98 12:36:17 EST From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9802191736.AA01808@dolphin.ncsc.mil> To: ipsec@tis.com Subject: Re: new draft-ietf-ipsec-isakmp? Cc: wdm@epoch.ncsc.mil Sender: owner-ipsec@ex.tis.com Precedence: bulk IPSEC'ers, > Any idea when we can read a isakmp draft? My apologies for not getting out another ISAKMP draft. This little thing called a dissertation keeps getting in the way. I had hoped to have it done by tomorrow, but it won't be ready. At the latest, I'll have it by next Friday, Feb. 27. > The last draft was submitted before Munich in July. Considering > the discussions on this list and the isakmp-oakley list, I would > like to see a new draft before seeing it complete last call. Bob/Ted: I suggest you consider waiting and sending this out with the architecture and roadmap documents. Your call. > Daniel Harkins writes: > > > Jul 28 1997 draft-ietf-ipsec-isakmp-08.txt > > So this means that the base ISAKMP draft wasn't rev'd? That means that > > one of the issues from the document reading party wasn't addressed. These are addressed in the next version. > Tero Kivinen writes: > How about the certificate request payload? There was some talk about > simplifying it so that it would only contain one type / CA and in case > of multiple types / CA's the negotiation would just have multiple > certitificate request payloads. This is also in the next version. > > Also, various vendors have in the past requested a Vendor ID payload > > which would carry some opaque blob. This also hasn't been added. > > I think that vendor ID payload is very important because otherwise > there really isn't any use for private attributes in SA etc, because > there is no way to know who's private extensions they unless you use > some out of band configuration data to tell the other end's isakmp > vendor. There was considerable discussion about the vendor ID payload. Is there consensus that it should be included in the next ISAKMP draft? If so, I'll use the text sent to IPSEC list by Michael Richardson on 13 Oct 1997. There were other payloads requested, i.e. Pass Kerberos tickets, Pass VRRP info, Pass Configuration information, and an Extension (blob) payload. Which of these, if any, should be included in the next draft? If there are any issues that are "hot" buttons that "MUST' be included in the next ISAKMP draft, please send them to me (and the list) so I can double check to make sure they've been addressed. Thanks, Doug Maughan From owner-ipsec Thu Feb 19 14:00:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA10283 for ipsec-outgoing; Thu, 19 Feb 1998 13:58:40 -0500 (EST) Message-ID: <002c01bd3d6a$4127d880$238a9ccc@ramesh.redcreek> From: "Ramesh Kamath" To: "Ben Rogers" , "Daniel Harkins" Cc: "Theodore Y. Ts'o" , Subject: Re: IPSEC WORKING GROUP LAST CALL Date: Thu, 19 Feb 1998 11:11:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi all The latest Feb 16 1998 draft-ietf-ipsec-ipsec-doi-07.txt, does not have definitions for 40 Bit DES and 3DES 112 bit, in IPSEC ESP transform identifiers. Also the document Feb 13 1998 draft-ietf-ipsec-isakmp-oakley-06.txt does not have class values for 40 Bit DES and 3DES 112 bit for Encryption algorithms. Ramesh -----Original Message----- From: Daniel Harkins To: Ben Rogers Cc: Theodore Y. Ts'o ; ipsec@tis.com Date: Wednesday, February 18, 1998 5:59 PM Subject: Re: IPSEC WORKING GROUP LAST CALL > Ben, > > If you read a bit further down in Appendix B of IKE it will >tell you how to obtain the key out of the blob of bits. For instance: > > The key for IDEA-CBC is derived from the first sixteen (16) bytes of > SKEYID_e. The IV is the first eight (8) bytes of the IV material > derived above. > > The key for Blowfish-CBC is either the negotiated key size, or the > first fifty-six (56) bytes of a key (if no key size is negotiated) > derived in the aforementioned pseudo-random function feedback method. > The IV is the first eight (8) bytes of the IV material derived above. > >if you're doing IDEA or Blowfish. The blob of bits is either SKEYID_e >directly or the result of the feedback mechanism. It's all there in >Appendix B. > > I included a weak key check for the mandatory-to-implement encryption >algorithm but not the others. Since it is mandatory to implement I felt it >was necessary to note the weak keys. Based on the lack of responses to your >3 postings of this message I guess no one else wants to add discussions >on weak keys for other optional encryption algorithms. > > There are quite a few independent implementations of IKE (yes, with >multiple encryption algorithm support too!) around so the text in Appendix >B is probably clear enough. It could always be made better, but a decent >enough clarity test is whether more that, say five, people can read it and >all interpret it the same way. They did and they have. > > Dan. > >> >From IKE Appendix B: >> >> Encryption keys used to protect the ISAKMP SA are derived from >> SKEYID_e in an algorithm-specific manner. When SKEYID_e is not long >> enough to supply all the necessary keying material an algorithm >> requires, the key is derived from feeding the results of a pseudo- >> random function into itself, concatenating the results, and taking >> the highest necessary bits. >> >> For example, if (ficticious) algorithm AKULA requires 320-bits of key >> (and has no weak key check) and the prf used to generate SKEYID_e >> only generates 120 bits of material, the key for AKULA, would be the >> first 320-bits of Ka, where: >> >> Ka = K1 | K2 | K3 >> and >> K1 = prf(SKEYID_e, 0) >> K2 = prf(SKEYID_e, K1) >> K3 = prf(SKEYID_e, K2) >> >> I'm not really clear as to what we do if SKEYID_e has enough bits to >> provide us with the encryption key we're looking for. Perhaps one of >> the following clarifications is appropriate? (Without the >> clarification, there exists a definite ambiuity). >> >> Encryption keys used to protect the ISAKMP SA are derived from >> SKEYID_e in an algorithm-specific manner. If SKEYID_e is long enough >> to supply the necessary keying material the algorithm requires, then >> it is used without modification. If it is not long enough, the key >> is derived from feeding the results of a pseudo-random function into >> itself, concatenating the results, and taking the highest necessary >> bits. >> >> For example,... >> >> or >> >> Encryption keys used to protect the ISAKMP SA are derived from >> SKEYID_e in an algorithm-specific manner. The key material is >> generated by taking the high order bits of the following string K: >> >> K = K1 | K2 | K3 | ... >> where >> K1 = prf(SKEYID_e, 0) >> KN+1 = prf(SKEYID_e, KN) >> >> and 0 is represented by a single octet. >> >> For example, if (ficticious) algorithm AKULA requires 320-bits of key >> (and has no weak key check) and the prf used to generate SKEYID_e >> only generates 120 bits of material, the key for AKULA, would be the >> first 320-bits of Ka, where: >> >> Ka = K1 | K2 | K3 >> and >> K1 = prf(SKEYID_e, 0) >> K2 = prf(SKEYID_e, K1) >> K3 = prf(SKEYID_e, K2) >> >> where prf is the negotiated prf or the HMAC version of the negotiated >> hash function. Each result of the prf provides 120 bits of material >> for a total of 360 bits. AKULA would use the first 320 bits of that >> 360 bit string. >> >> I'm also not certain to do in the case where the first 8 bytes of this >> keystring are weak. Do we instead take bytes 1-9, or bytes 9-16? Does >> anyone see the need to include the weak key check in 3DES-CBC? If so, >> do we not allow keys for which any of the DES keys is weak, or only keys >> where all three are weak? If the first is the case, shold we allow >> non-contiguous keys? (ie, if bytes 9-16 are a weak key, do I build my >> 3DES key from bytes 1-8, 17-24 and 25-32, or take the contiguous block >> of bytes 17-40 or 25-48?) >> >> >> ben > > From owner-ipsec Thu Feb 19 16:39:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA11391 for ipsec-outgoing; Thu, 19 Feb 1998 16:35:47 -0500 (EST) Message-Id: <3.0.32.19980219134802.009d9790@192.43.161.2> X-Sender: jburke@192.43.161.2 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 19 Feb 1998 13:48:03 -0800 To: wdm@epoch.ncsc.mil From: John Burke Subject: ISAKMP Draft: NotifyCodes, alignment Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Doug, two suggestions for ISAKMP v-09 to bring it into line with the IP DOI and what I believe to be implementors' current understanding and working code: Notification Codes The IP DOI (v-06 and earlier) actually violated the ISAKMP draft by using codes in the Private range as Status codes (the DOI is a standard, not Private, right?). Since people are presumably implementing these codes already, perhaps it would be better for the ISAKMP draft to change to make the present DOI valid. Also the draft should spec the full range of the 16-bit number. How about this: Status codes in v-08: CONNECTED 16384 RESERVED (Future Use) 16385- 24575 Private Use 24576 - 32767 Change to: CONNECTED 16384 RESERVED (Future Use) 16385- 24575 DOI-specific codes 24576 - 32767 Private Use 32768 - 40959 RESERVED (Future Use) 40960 - 65535 Notification affecting phase I The text has these contradictory assertions: Notification which occurs during, or is concerned with, a Phase 1 nego- tiation is identified by the Initiator and Responder cookie pair in the ISAKMP Header. The Protocol Identifier, in this case, is ISAKMP and the SPI value is 0 because the cookie pair in the ISAKMP Header identifies the ISAKMP SA. If the notification takes place prior to the completed exchange of keying information, then the notification will be unprotected. o SPI Size (1 octet) - Length in octets of the SPI as defined by the Protocol-Id. In the case of ISAKMP, the Initiator and Responder cookie pair is the ISAKMP SPI, therefore, the SPI Size would be 16 octets for the SPI. I believe implementations generally are using SPI size zero. Most people would probably accept any SPI size and not care what's in the SPI. Probably the draft should say, [ ... ] In the case of ISAKMP, the Initiator and Responder cookie pair from the ISAKMP header is the ISAKMP SPI, therefore, the SPI Size is irrelevant and may be from zero to 16 [? require alignment? See below]. If the SPI size is nonzero the content of the SPI field MUST be ignored[? zero?]. The Phase II description asserts that Message ID identifies the session. Notification which occurs during, or is concerned with, a Phase 2 nego- tiation is identified by the Initiator and Responder cookie pair in the ISAKMP Header and the Message ID and SPI associated with the current nego- tiation. This would require that the notification be sent as part of the Quick Mode exchange; but between ISAKMP v-08 and IKE (was "Resolution"), I understand that all Notifications are supposed to be sent as an Informational Exchange; it is asserted that an exchange prescribes exactly what messages and payloads are permissible, and no exchanges have a place for Notifications, particularly, a Notification returned in reply to the final message sent. An exception is that the IP DOI prescribes additional Status Notifications and prescribes they get combined into the standard exchange messages. My understanding, which I am not at all sure reflects current practice: Notification which occurs during, or is concerned with, a Phase 2 nego- tiation is identified by a current Initiator and Responder cookie pair in the ISAKMP Header, and the protocol and SPI associated with the affected negotiation. The Message ID of the ISAKMP header DOES NOT identify the negotiation targetted by the Notification. Other people may have different understandings of the above. If so, I hope they'll speak now; we may all have to resolve differences where we are not be interoperable. Alignment Remove the assertion that the Message is aligned. It is not possible for ISAKMP to demand alignment of a message; it is where IP prescribes that the UDP body is, period, and this must be left open for IP/UDP. State explicitly that any payload can be of arbitrary alignment, depending on the content of previous payloads (e.g. a certificate). Matt Thomas said the SPI in a Notification is to be padded to 4-bytes; I don't see that anywhere. If it is anywhere it needs to be more prominent; if not, then never mind. From owner-ipsec Thu Feb 19 18:13:24 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA12058 for ipsec-outgoing; Thu, 19 Feb 1998 18:05:47 -0500 (EST) Message-Id: <199802192318.PAA01996@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: John Burke Cc: wdm@epoch.ncsc.mil, ipsec@tis.com Subject: Re: ISAKMP Draft: NotifyCodes, alignment In-Reply-To: Your message of "Thu, 19 Feb 1998 13:48:03 PST." <3.0.32.19980219134802.009d9790@192.43.161.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Feb 1998 15:18:51 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk John, > Notification Codes > > The IP DOI (v-06 and earlier) actually violated the ISAKMP draft by using > codes in the Private range as Status codes (the DOI is a standard, not > Private, right?). Since people are presumably implementing these codes > already, perhaps it would be better for the ISAKMP draft to change to make > the present DOI valid. Also the draft should spec the full range of the > 16-bit number. Section 3.14.1 of the ISAKMP draft specifically says: Values in the Private Use range are expected to be DOI-specific values. so there is no violation of the draft. Dan. From owner-ipsec Thu Feb 19 18:42:48 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA12264 for ipsec-outgoing; Thu, 19 Feb 1998 18:39:49 -0500 (EST) Message-Id: <199802192353.SAA12215@relay.rv.tis.com> To: John Burke cc: wdm@epoch.ncsc.mil, ipsec@tis.com Subject: Re: ISAKMP Draft: NotifyCodes, alignment In-reply-to: Your message of "Thu, 19 Feb 1998 13:48:03 PST." <3.0.32.19980219134802.009d9790@192.43.161.2> Date: Thu, 19 Feb 1998 15:52:29 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk John, >The IP DOI (v-06 and earlier) actually violated the ISAKMP draft by using >codes in the Private range as Status codes (the DOI is a standard, not >Private, right?). Since people are presumably implementing these codes >already, perhaps it would be better for the ISAKMP draft to change to make >the present DOI valid. Also the draft should spec the full range of the >16-bit number. How about this: >From the current ISAKMP draft (note last sentence): 3.14.1 Notify Message Types Notification information can be error messages specifying why an SA could not be established. It can also be status data that a process managing an SA database wishes to communicate with a peer process. For example, a secure front end or security gateway may use the Notify message to syn- chronize SA communication. The table below lists the Nofitication mes- sages and their corresponding values. Values in the Private Use range are expected to be DOI-specific values. Derrell From owner-ipsec Thu Feb 19 19:11:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA12408 for ipsec-outgoing; Thu, 19 Feb 1998 19:09:48 -0500 (EST) From: plambert@certicom.com X-Lotus-FromDomain: CERTICOM To: ipsec@tis.com cc: jgoyo@certicom.com, ajmeneze@math.uwaterloo.ca Message-ID: <852565B0.00727314.00@domino_c02.certicom.com> Date: Thu, 19 Feb 1998 16:24:16 -0400 Subject: Regrouping for IPSEC WORKING GROUP LAST CALL Sender: owner-ipsec@ex.tis.com Precedence: bulk The "Internet Key Exchange" specification includes definitions for well known groups for Elliptic Curve cryptographic implementations. Implementations using these techniques should have considerable performance improvements. One problem, the groups defined are composite :-( Third Oakley Group is on Galois Field GF[2^^155] Fourth Oakley Group is on Galois Field GF[2^^185] These groups should be prime! In his talks at Eurocrypt '97 and at the ECDLP Workshop in Waterloo >(Nov '97), Gerhard Frey suggested that elliptic curves over GF(2^^m), >where m is composite, *may* have serious security flaws. This >opinion was also stated by Clauss Schnorr at Crypto '97 (in >response to the breaking of the Chor-Rivest knapsack scheme which >exploited such composite finite fields), and by Volker Mueller >and Sachar Paulus in their paper "On the generation of >cryptographically strong elliptic curves" (available from >http://www.informatik.th-darmstadt.de/TI/Mitarbeiter/vmueller.html). >> Mueller and Paulus state: >> If the Galois group G(F_{p^^k}/F_p) has small factors >> (as for composite fields, where k>1 is not a prime number), >> or if the curve is already defined over F_p, as is the case >> for anomalous curves, then there might be better methods than >> those cited above. Thus the exponent k should be a prime or >> equal to 1. There are a wide variety of excellent curves defined ... mostly in ANSI. I'll try to find someone to help submit some other predefined curves before the end of the last call. Paul A. Lambert From owner-ipsec Thu Feb 19 20:12:11 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA12817 for ipsec-outgoing; Thu, 19 Feb 1998 20:10:52 -0500 (EST) Date: Thu, 19 Feb 1998 20:22:49 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199802200122.UAA07235@earth.hpc.org> To: plambert@certicom.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199802200035.RAA23206@baskerville.CS.Arizona.EDU> Subject: Re: Regrouping for IPSEC WORKING GROUP LAST CALL Sender: owner-ipsec@ex.tis.com Precedence: bulk The Oakley groups were chosen to optimize computation time; the techniques don't work with prime exponents for the Galois field. It's a big performance hit to take in response to a "*may* have flaws". Hilarie Hilarie From owner-ipsec Thu Feb 19 20:14:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA12867 for ipsec-outgoing; Thu, 19 Feb 1998 20:12:47 -0500 (EST) Date: Thu, 19 Feb 1998 20:24:39 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199802200124.UAA07292@earth.hpc.org> To: plambert@certicom.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199802200035.RAA23206@baskerville.CS.Arizona.EDU> Subject: Re: Regrouping for IPSEC WORKING GROUP LAST CALL Sender: owner-ipsec@ex.tis.com Precedence: bulk By the way, I recommend omitting the Y coordinate. Hilarie From owner-ipsec Thu Feb 19 23:19:31 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA13896 for ipsec-outgoing; Thu, 19 Feb 1998 23:06:49 -0500 (EST) Date: Thu, 19 Feb 1998 23:19:10 -0500 Message-Id: <199802200419.XAA14803@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: wdm@epoch.ncsc.mil Cc: ipsec@tis.com, wdm@epoch.ncsc.mil In-Reply-To: W. Douglas Maughan's message of Thu, 19 Feb 98 12:36:17 EST, <9802191736.AA01808@dolphin.ncsc.mil> Subject: Re: new draft-ietf-ipsec-isakmp? Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Thu, 19 Feb 98 12:36:17 EST From: wdm@epoch.ncsc.mil (W. Douglas Maughan) My apologies for not getting out another ISAKMP draft. This little thing called a dissertation keeps getting in the way. I had hoped to have it done by tomorrow, but it won't be ready. At the latest, I'll have it by next Friday, Feb. 27. OK. Both Bob and I had been under the impression that another draft would not be forthcoming, and that the current one was adequate. Clearly, there is consensus to the contrary. We'll consider the last call on the ISAKMP draft withdrawn until you can get your revision done by Feb. 27 at the latest. (Hopefully sooner, please, if you can.) I'd like to give the IESG opportunity to make these RFC status *before* the LA IETF meeting, so I don't have to have a blue dot on my name tag. :-) - Ted From owner-ipsec Thu Feb 19 23:32:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA13990 for ipsec-outgoing; Thu, 19 Feb 1998 23:29:48 -0500 (EST) Date: Thu, 19 Feb 1998 23:42:47 -0500 Message-Id: <199802200442.XAA14827@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: In-Reply-To: Ramesh Kamath's message of Thu, 19 Feb 1998 11:11:58 -0800, <002c01bd3d6a$4127d880$238a9ccc@ramesh.redcreek> Subject: Re: IPSEC WORKING GROUP LAST CALL Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk From: "Ramesh Kamath" Date: Thu, 19 Feb 1998 11:11:58 -0800 The latest Feb 16 1998 draft-ietf-ipsec-ipsec-doi-07.txt, does not have definitions for 40 Bit DES and 3DES 112 bit, in IPSEC ESP transform identifiers. 40 Bit DES isn't currently defined in a cipher suite algorithm anywhere, so I'm not particularly saddened or disturbed by its omission. ESP_3DES is defined (it has the value of 3) and that is a 112 bit (3key) triple DES. See draft-ietf-ipsec-ciph-3des-00.txt. So, I don't believe either of your concerns is a problem. Your question about triple DES does another one, though, which I will put to the working group: The triple DES document wasn't one of the documents that I put into IETF last call, as one of the "core group" of documents. Do people believe that should get pushed out to the IESG at the same time? There is a related question to the other cipher suites for which DOI document contains references: ARCFOUR, Blowfish, and RC5. Since RFC's are not allowed to refer to internet-drafts, what do we want to do with them in the DOI spec? There is also a reference in the DOI draft to draft-mcdonald-pf-key-v2-03.txt (and the latest version of that I-D is -04). Our choices for each referenced I-D include (a) deleting the reference from the draft, or (b) advancing the I-D along with the main set of documents. Note that if we choose (a), it's no big deal; we would simply move the DOI assignment to the (delayed) cipher draft, and when the cipher draft advanced, it would get added to the IANA's registry list. The advantage of (a) is that it might speed up the time that it takes the IESG to the IPSEC drafts, since it won't have to deal with the extra drafts. It also means we don't have to take time now vetting these "non-core" drafts (which I suspect most people haven't paid much attention to at this point). The advantage of (b) is that for people who really want to use these other algorithms, they will be available sooner, and the DOI would contain a slightly more comprehensive list. My tendency is to lean towards (a) for all of the non-core cipher documents (except possibly triple DES), but I'm certainly willing to hear arguments to the contrary, or for other alternatives. As for the reference to the PFKEY API, we can either (a) remove the reference, or (b) suggest that this be advanced to informational, assuming that the PFKEY folks believe that the document is stable. The reference doesn't appear to be in a critical part of the text, so it probably isn't a big deal to remove the reference if the PFKEY spec is still undergoing revisions. Comments? - Ted From owner-ipsec Fri Feb 20 00:02:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA14137 for ipsec-outgoing; Fri, 20 Feb 1998 00:00:48 -0500 (EST) Message-Id: <199802200514.VAA02177@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: "Theodore Y. Ts'o" Cc: ipsec@tis.com Subject: Re: IPSEC WORKING GROUP LAST CALL In-Reply-To: Your message of "Thu, 19 Feb 1998 23:42:47 EST." <199802200442.XAA14827@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Feb 1998 21:14:05 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Ted, A 2key 3DES is 112bit while a 3key 3DES is 168 (although I never did like those numbers since 3 DES keys are 192 bits not 168 bits). And draft-ietf-ipsec-ciph-3des-00.txt is definately a 3key 3DES. So I think Ramesh is talking about a 2key 3DES. But there is no draft which defines such a transform so the request to add a magic number for it is premature. Ditto for 40bit DES. As far as the other drafts are concerned, I'd like to see 3DES get added to the pile but given the size of the pile already I wouldn't have a problem with waiting on the rest. Dan. > 40 Bit DES isn't currently defined in a cipher suite algorithm anywhere, > so I'm not particularly saddened or disturbed by its omission. ESP_3DES > is defined (it has the value of 3) and that is a 112 bit (3key) triple > DES. See draft-ietf-ipsec-ciph-3des-00.txt. So, I don't believe either > of your concerns is a problem. Your question about triple DES does > another one, though, which I will put to the working group: > > The triple DES document wasn't one of the documents that I put into IETF > last call, as one of the "core group" of documents. Do people believe > that should get pushed out to the IESG at the same time? > > There is a related question to the other cipher suites for which DOI > document contains references: ARCFOUR, Blowfish, and RC5. Since RFC's > are not allowed to refer to internet-drafts, what do we want to do with > them in the DOI spec? There is also a reference in the DOI draft to > draft-mcdonald-pf-key-v2-03.txt (and the latest version of that I-D is > -04). > > Our choices for each referenced I-D include (a) deleting the reference > from the draft, or (b) advancing the I-D along with the main set of > documents. Note that if we choose (a), it's no big deal; we would > simply move the DOI assignment to the (delayed) cipher draft, and when > the cipher draft advanced, it would get added to the IANA's registry > list. > > The advantage of (a) is that it might speed up the time that it takes > the IESG to the IPSEC drafts, since it won't have to deal with the extra > drafts. It also means we don't have to take time now vetting these > "non-core" drafts (which I suspect most people haven't paid much > attention to at this point). The advantage of (b) is that for people > who really want to use these other algorithms, they will be available > sooner, and the DOI would contain a slightly more comprehensive list. > > My tendency is to lean towards (a) for all of the non-core cipher > documents (except possibly triple DES), but I'm certainly willing to > hear arguments to the contrary, or for other alternatives. > > As for the reference to the PFKEY API, we can either (a) remove the > reference, or (b) suggest that this be advanced to informational, > assuming that the PFKEY folks believe that the document is stable. The > reference doesn't appear to be in a critical part of the text, so it > probably isn't a big deal to remove the reference if the PFKEY spec is > still undergoing revisions. > > Comments? > > - Ted From owner-ipsec Fri Feb 20 00:33:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA14323 for ipsec-outgoing; Fri, 20 Feb 1998 00:30:48 -0500 (EST) Date: Fri, 20 Feb 1998 00:43:24 -0500 Message-Id: <199802200543.AAA14931@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Daniel Harkins Cc: "Theodore Y. Ts'o" , ipsec@tis.com In-Reply-To: Daniel Harkins's message of Thu, 19 Feb 1998 21:14:05 -0800, <199802200514.VAA02177@dharkins-ss20.cisco.com> Subject: Re: IPSEC WORKING GROUP LAST CALL Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Thu, 19 Feb 1998 21:14:05 -0800 From: Daniel Harkins A 2key 3DES is 112bit while a 3key 3DES is 168 (although I never did like those numbers since 3 DES keys are 192 bits not 168 bits). Err, right. I should know better than to send e-mail out after midnight without first checking my multiplcation first. Sorry about that.... (The only lame excuse I can give is that my brain was fried after a full day of dealing with ipsec/ca-talk issues at Needham today...) And draft-ietf-ipsec-ciph-3des-00.txt is definately a 3key 3DES. So I think Ramesh is talking about a 2key 3DES. But there is no draft which defines such a transform so the request to add a magic number for it is premature. Agreed. As far as the other drafts are concerned, I'd like to see 3DES get added to the pile but given the size of the pile already I wouldn't have a problem with waiting on the rest. Noted. Anybody else who wants to express an opinion on this, now's the time to speak up. - Ted From owner-ipsec Fri Feb 20 01:14:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA14653 for ipsec-outgoing; Fri, 20 Feb 1998 01:13:50 -0500 (EST) Message-ID: <01BD3D85.6B31C350.adams@cisco.com> From: Rob Adams Reply-To: "adams@cisco.com" To: "'Theodore Y. Ts'o'" , Daniel Harkins Cc: "ipsec@tis.com" Subject: RE: IPSEC WORKING GROUP LAST CALL Date: Thu, 19 Feb 1998 22:26:17 -0800 Organization: Cisco Systems Global Alliances X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk We need a 40 bit DES description which defines how to weaken the key. And we need a transform number. On Thursday, February 19, 1998 9:43 PM, Theodore Y. Ts'o [SMTP:tytso@MIT.EDU] wrote: > Date: Thu, 19 Feb 1998 21:14:05 -0800 > From: Daniel Harkins > > A 2key 3DES is 112bit while a 3key 3DES is 168 (although I never did > like those numbers since 3 DES keys are 192 bits not 168 bits). > > Err, right. I should know better than to send e-mail out after midnight > without first checking my multiplcation first. Sorry about that.... > (The only lame excuse I can give is that my brain was fried after a full > day of dealing with ipsec/ca-talk issues at Needham today...) > > And draft-ietf-ipsec-ciph-3des-00.txt is definately a 3key 3DES. So I > think Ramesh is talking about a 2key 3DES. But there is no draft > which defines such a transform so the request to add a magic number > for it is premature. > > Agreed. > > As far as the other drafts are concerned, I'd like to see 3DES get > added to the pile but given the size of the pile already I wouldn't have > a problem with waiting on the rest. > > Noted. Anybody else who wants to express an opinion on this, now's the > time to speak up. > > - Ted > From owner-ipsec Fri Feb 20 05:33:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA16216 for ipsec-outgoing; Fri, 20 Feb 1998 05:30:49 -0500 (EST) Message-Id: <199802201044.TAA02097@baba-yaga.rinfo.sei.co.jp> X-Authentication-Warning: baba-yaga.rinfo.sei.co.jp: localhost.rinfo.sei.co.jp [127.0.0.1] didn't use HELO protocol To: ipsec@tis.com Subject: key derivation for ESP Authentication Algorithm X-Mailer: Mew version 1.70 on Emacs 19.28.1 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 20 Feb 1998 19:44:44 +0900 From: Norio Korekawa Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, I have a question about derivation of Phase 2 keying material and I would greatly appreciate receiving an answer from someone of this group. My question is: How is a key for ESP Authentication Algorithm derived from a keying material SKEYID_d? I think it is derived in the same way as a key for ESP Encryption Algorithm is derived, according to the following procedure. So the difference between the two(Encryption and Authentication) keys is only its length, I think. Am I right? ----------------------------------------------------------------- KEYMAT = prf(SKEYID_d, [g(qm)^xy] | protocol | SPI | Ni_b | Nr_b) KEYMAT = K1 | K2 | K3 | ... where K1 = prf(SKEYID_d, [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b) K2 = prf(SKEYID_d, K1 | [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b) K3 = prf(SKEYID_d, K2 | [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b) etc. ----------------------------------------------------------------- I'm afraid that I'm making a wrong guess, but I hope some will kindly answer to me. Thanks in advance, Norio Korekawa(korekawa@rinfo.sei.co.jp) SUMITOMO ELECTRIC INDUSTRIES, LTD. From owner-ipsec Fri Feb 20 07:25:06 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA16975 for ipsec-outgoing; Fri, 20 Feb 1998 07:23:51 -0500 (EST) Message-Id: <199802200718.CAA07189@relay.hq.tis.com> Date: Fri, 20 Feb 98 2:19:28 EST From: Karen Seo To: ipsec@tis.com cc: kseo@bbn.com Subject: Summary list -- IPsec Architecture Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, Here's a summary of IPsec architecture issues and what we believe to be their current resolution/status. This is based on the draft distributed in 11/97, subsequent email (up until 1/31) including the summaries of IETF discussions, and feedback received recently on SA lifetimes. It does not include some minor edits (typos), the addition of the new copyright text required by the RFC format instructions, etc. The issues have been divided into 2 groups: 1. NO ACTION -- the draft has been left as is; rationale or a pointer to the relevant email is included below. 2. CHANGES MADE -- the draft has been changed as described below. The Architecture draft has been submitted to the IETF secretariat for distribution. Per direction from the working group chairs, we also sent the draft to the mailing list to minimize the delay in getting it to the community. As with the AH/ESP specs, thank you for the feedback both on the list and privately. Karen NO ACTION =============================================================================== 1. Section 3.0 "System Overview" -- Should support for "discard" function be MUST (as in current doc)? * see email from S. Kent 12/7/97 (Subj: "responses to comments in the Architecture Document") for rationale -- no comments were received 2. Section 4.4.1 "Security Policy Database" -- Should entries in SPD be ordered (as currently specified)? * see email from S. Kent 12/7/97 (Subj: "responses to comments in the Architecture Document") for rationale -- no comments were received on this specific issue, but people did bring up closely related issues which are discussed below. 3. Section 4.4.1 "Security Policy Database" -- How to select which SAD and/or SPD entries to use if multiple entries match? The architecture document requires use of the first matching entry encountered and correspondingly requires use of ordered entries to achieve the desired security goals. Some email has interpreted "ordered SPD" to imply the ordering that exists AFTER the user input has been processed by a vendor-specific algorithm. The intent of the draft is that "ordered SPD" means the user specified (e.g., ASCII) ordering of the SPD input. Email discussions centered on whether one could "use the most restrictive SA" (and presumably policy) if one followed this approach. Some folks said that they can specify "most restrictive" SAD entries but cannot also specify an ordering of the SPD input that results in the same mapping to SAD entries. To first order, it would appear to be possible to create a list of entries (SAs or policies) ordered to enable the first match to be the "most restrictive." This can be achieved by defining the rules for "restrictiveness" and then ordering the SPD/SAD entries from most to least restrictive. The participants in the discussion did not define "most restrictive" nor how they were "ordering" the SAD/SPD entries. The basic issue for SPD ordering is that SPD selectors define an n-space, for n => 5 (Source IP, Dest IP, Protocol, Source Port, Dest Port, Name). There does not appear to be a way to cannonically order SPD entries in this space, given that some may be "don't care," others may have specific values, and IP addresses can have ranges. (Mathematically, the set of SPD entries forms a lattice. One could use set inclusion to induce a partial order, but not a total order.) So, the editors believe that the SPD must be searched in a linearly ordered fashion, with the order determined by the system adminitrator. 4. Section 4.4.1 "Security Policy Database" -- Should support be provided for sharing of SAs or SA bundles? Currently, the spec calls for sharing of SAs. * see email from S. Kent 12/7/97 (Subj: "responses to comments in the Architecture Document") for rationale -- no comments were received 5. Section 4.4.1 "Security Policy Database" -- Per email from Gordon Oliver (12/12/97) -- Should guidance be provided "about what kinds of policies are allowed and the associations between policies and bundles." * The allowable policies are those expressable with the IPsec selectors and are determined by local administration and defined in the SPD. No comments were received. 6. Section 4.4.2 "Selectors" -- Should we add "negative" entries, i.e., the ability to specify that a selector value NOT be x. This would support creation of ranges with holes. Currently this is not supported by the spec. * see email from S. Kent 12/7/97 (Subj: "responses to comments in the Architecture Document") which notes that the ability to have negative entries is "implicit in the SPD, in that DISCARD is a processing option for traffic." At present, ISAKMP does not support negotiation of SAs with negative selectors, e.g., to create "holes" in address space ranges or exceptions to "any" matches. So, we can't support negative entries in this sense. However, using DISCARD as a processing option for an entry does allow local expression of negative entries. No comments were received. 7. Section 5.2.1 Selecting and Using an SA or SA bundle -- Need to verify that ISAKMP and DOI support specification of the ordering of application of IPsec headers. * This has become irrelevant since the document calls for only one case of "nested" IPsec headers, [IP1][AH][ESP][upper], --> no negotiation of ordering is needed. 8. Section "6. ICMP Processing (relevant to IPsec)" -- Per email from Gordon Oliver (12/2/97) -- how should we handle "an ICMP packet that signifies an error that will not necessarily recover [sic] (i.e., not MTU)..." when "...there isn't enough information to forward the ICMP packet...? Dropping the ICMP on the floor will cause poor behavior on the network....(suppose it'd work though)" * No comments received -- deferred to IPsecond. 9. Section "6. ICMP Processing (relevant to IPsec)" -- Need to discuss how to avoid the unauthorized disclosure of information that could occur if decrypted IP packet contents were included in an ICMP error message. In other words, a packet could be decrypted and then an error could occur which triggers the transmission of an ICMP error message containing the decrypted data. The ICMP error message with its decrypted contents is then not identified as requiring confidentiality in transiting back to the source. This could happen for many reasons, e.g., the ICMP error message could take a different path (with a different security policy) on the return route. * This is deferred to IPsecond. 10. Section "6.1.2.1 Propagation of PMTU" -- Should propagation of PMTU by security gateway be a MUST or a SHOULD? The current draft says MUST to ensure that the host learns, as quickly as possible, that there is an MTU problem downstream. 11. Section "6.1.2.4 PMTU Aging" -- From Cheryl Madson's email of 11/21 on "IPSEC SA doc comments" -- "16. Page 35, first full paragraph. What's the general opinion been of using the behavior described in RFC1191 as opposed to what's been described in RFC2003? [I'm talking about the issue of whether or not to forward the packet through the tunnel anyhow if it's too big.]. * Unclear on the [comment] in this context, but the paragraph in question is the last paragraph of 6.1.2.4 PMTU Aging. It says: "Systems SHOULD use the approach described in the Path MTU Discovery document (RFC 1191, Section 6.3), which suggests periodically resetting the PMTU to the first-hop data-link MTU and then letting the normal PMTU Discovery processes update the PMTU as necessary. The period SHOULD be configurable." No comments were received. RFC 1191 talks about how a host or gateway should do PMTU discovery in general and includes a discussion of how to age the PMTU, etc. RFC 2003 doesn't talk about aging the soft state. So it makes sense to use RFC1191 for the model for this section. CHANGES MADE (* indicates the change made) =============================================================================== 1. Section 4.1 -- Per discussion of "some issues about IPsec" re: tunnel and transport modes (1/11-28) -- Two topics were raised. 1. Why have both tunnel and transport mode? 2. Which modes are used when (host to host, SG to SG, host to SG (for gateway management), host to SG (for road warrior)? * Added the following text at "Section 4.1 "Definition and Scope" [of SAs]: In summary: a) A host MUST support both transport and tunnel mode (per your message of 1/25)? b) A security gateway is required to support only tunnel mode. If it supports transport mode, that should be used only when the security gateway is acting as a host, e.g., for network management. 2. Section 4.2 "Security Association Functionality" -- For tunnel-mode SAs, is clarification needed about SA granularity and vulnerability to traffic analysis? * Added the sentence at the end of the last paragraph of this section, which now reads: An ESP (tunnel mode) SA between two security gateways can offer partial traffic flow confidentiality. The use of tunnel mode allows the inner IP headers to be encrypted, concealing the identities of the (ultimate) traffic source and destination. Moreover, ESP payload padding also can be invoked to hide the size of the packets, further concealing the external characteristics of the traffic. Similar traffic flow confidentiality services may be offered when a mobile user is assigned a dynamic IP address in a dialup context, and establishes a (tunnel mode) ESP SA to a corporate firewall (acting as a security gateway). Note that fine granularity SAs generally are more vulnerable to traffic analysis than coarse granularity ones that are carrying traffic from many subscribers. 3. Section 4.3 "Combining Security Associations -- Is clarification needed on how to handle ISAKMP traffic in the context of iterated tunneling? * Section 4.5 page 22 already discusses this, so a pointer to this section has been added along with some clarifications. The text for Section 4.3 now reads: "o Iterated tunneling refers to the application of multiple layers of security protocols effected through IP tunneling. This approach allows for multiple levels of nesting, since each tunnel can originate or terminate at a different IPsec site along the path. No special treatment is expected for ISAKMP traffic at intermediate security gateways other than what can be specified through appropriate SPD entries (See Case 3 in Section 4.5) "These two approaches also can be combined, i.e., an SA bundle could be constructed from one tunnel mode SA and one or two transport mode SAs, applied in sequence. (See Section 4.5 "Basic Combinations of Security Associations.") Note that nested tunnels can also occur where neither the source nor the destination endpoints of any of the tunnels are the same. In that case, there would be no host or security gateway with a bundle corresponding to the nested tunnels. 4. Section "4.3 Combining Security Associations" -- Need clarification of "iterated tunneling". Need clarification of "These two approaches can also be combined". * Added the following diagram after the paragraph on "Transport adjacency" Host 1 --- Security ---- Internet -- Security --- Host 2 | | Gwy 1 Gwy 2 | | | | | | | -----Security Association 1 (ESP transport)------- | | | -------Security Association 2 (AH transport)---------- * Added the following text and diagrams after the paragraph on "Iterated tunneling": There are 3 basic cases of iterated tunneling -- support is required only for cases 2 and 3. 1. both endpoints for the SAs are the same -- The inner and outer tunnels could each be either AH or ESP, though it is unlikely that Host 1 would specify both to be the same, i.e., AH inside of AH or ESP inside of ESP. Host 1 --- Security ---- Internet -- Security --- Host 2 | | Gwy 1 Gwy 2 | | | | | | | -------Security Association 1 (tunnel)---------- | | | | ---------Security Association 2 (tunnel)-------------- 2. one endpoint of the SAs is the same -- The inner and outer tunnels could each be either AH or ESP. Host 1 --- Security ---- Internet -- Security --- Host 2 | | Gwy 1 Gwy 2 | | | | | | ----Security Association 1 (tunnel)---- | | | ---------Security Association 2 (tunnel)------------- 3. neither endpoint is the same -- The inner and outer tunnels could each be either AH or ESP. Host 1 --- Security ---- Internet -- Security --- Host 2 | Gwy 1 Gwy 2 | | | | | | --Security Assoc 1 (tunnel)- | | | -----------Security Association 2 (tunnel)----------- 5. Section 4.4.1 "Security Policy Database" (paragraph 5)-- Needs clarification of the 3 cases of allowable values for each selector * Changed text from: The SPD contains an ordered list of policy entries. Each policy entry is keyed by one or more selectors that define the set of IP traffic encompassed by this policy entry.... For each selector, the policy entry specifies which of the following values should used in the SA: (a) the value in the packet, (b) the value associated with the policy, or (c) a wildcard. to: The SPD contains an ordered list of policy entries. Each policy entry is keyed by one or more selectors that define the set of IP traffic encompassed by this policy entry.... For each selector, the policy entry specifies how to derive the corresponding values for a new SAD entry from those in the SPD and the packet (Note that at present, ranges are only supported for IP addresses; but wildcarding can be expressed for all selectors): a. use the value in the packet itself -- This will limit use of the SA to those packets which have this packet's value for the selector even if the selector for the policy entry has a range of allowed values or a wildcard for this selector. b. use the value associated with the policy entry -- if this were to be just a single value, then there would be no difference between (b) and (a). However, if the allowed values for the selector were a range, then (b) would enable use of the SA by any packet with a selector value within the range not just by packets with the selector value of the packet that triggered the creation of the SA. c. use a wildcard value -- this can be used to create an SA that can be shared by a broader set of SPD entries (vs (b)). For example, suppose there is an SPD entry where the allowed value for source address is any of a range of hosts (192.168.2.1 to 192.168.2.10). And suppose that a packet is to be sent that has a source address of 192.168.2.3. The value to be used for the SA could be any of the sample values below depending on what the policy entry for this selector says is the source of the selector value: source for the example of value to be new SAD used in the SA selector value --------------- ------------ a. packet 192.168.2.3 (one host) b. SPD entry 192.168.2.1 to 192.168.2.10 (range of hosts) c. wildcard * (any host) 6. Section 4.4.1 "Security Policy Database" What should be done re: ISAKMP (encrypted) traffic traversing a security gateway that does not normally allow transit traffic to be encrypted? May need to mention proxy key exchange as a possible mechanism for enabling encrypted packet traversal. * Changed last paragraph from: The SPD also will be consulted when any IPsec implementation is the target of an SA establishment request from another IPsec implementation, e.g., using ISAKMP/Oakley. to: The SPD is used to control the flow of ALL traffic through an IPsec system, including security and key management traffic (e.g., ISAKMP/Oakley) from/to entities behind a security gateway. This means that ISAKMP traffic must be explicitly accounted for in the SPD, else it will be discarded. Note that a security gateway could prohibit traversal of encrypted packets in various ways, e.g., having a DISCARD entry in the SPD for ESP packets or providing proxy key exchange. In the latter case, the traffic would be internally routed to the key management module in the security gateway. 7. Section 4.4.2 "Selectors" -- There are discrepancies between the draft's SPD/SAD values and ISAKMP/Oakley's ability to negotiate these values for an SA. The DOI does not support value "ranges" for any selector besides IP addresses. It also does not support enumerated lists, TOS, IPv6 Flow Label, IPv6 Class. * Removed enumerated lists from Destination IP Address, Source IP Address, Transport Layer Protocol, Source and Destination Ports (and a few other places in the text) * Removed range from Transport Layer Protocol * Removed TOS, IPv6 Flow Label, and IPv6 Class * Updated table on page 19 to reflect above changes * Added the following text at the end of section 4.4.2 NOTE: In principle, one could have selectors and/or selector values in the SPD which cannot be negotiated for an SA or SA bundle. Examples might include selector values used to select traffic for discarding or enumerated lists which cause a separate SA to be created for each item on the list. For now, this is left for future versions of this document and the list of required selectors and selector values is the same for the SPD and the SAD. However, it is acceptable to have an administrative interface that supports use of selector values which cannot be negotiated provided that it does not mislead the user into believing it is creating an SA with these selector values. For example, the interface may allow the user to specify an enumerated list of values but would result in the creation of a separate policy and SA for each item on the list. A vendor might support such an interface to make it easier for its customers to specify clear and concise policy specifications. 8. Section 4.4.2 "Selectors" -- Why do we have the Transport Protocol selector separate from the IPsec protocol selector? * It had been suggested that administrators might want this for the SPD. However, it appears that it is not possible to negotiate IPsec protocol separately from Transport Protocol. At the last IETF meeting, we agreed to drop this, at least for now. It can be argued that supporting both provides greater filtering functionality, but whenever we have such filter functionality and we cannot negotiate an SA to correspond to it, we cause potential problems/confusion. (DISCARD and BYPASS filters are something of an exception in that they don't result in SAs, but even there we have possible confusion.) The paragraphs on IPsec protocol have been removed. This specific issue and the more general one of having selectors for the SPD that are not negotiable for the SAD is deferred to IPsecond. 9. Section 4.4.2 "Selectors" -- Should there be support for the selector "names"? * Rationale behind use of "name" as a selector is discussed in email from S. Kent 12/7/97 (Subj: "responses to comments in the Architecture Document"). While this will add complexity to SPD management (as discussed in the 12/7 email), folks said they wanted this. So, the choice was either to defer this for now and not support dialup users with dynamically assigned IP addresses, or to support it and buy into the added complexity. It was proposed in the 12/7 email that names be added as a selector -- no comments were received. Therefore the following text has replaced the section for UserID. "- Name: There are 2 cases (Note that these name forms are supported in ISAKMP.) 1. User ID a. a fully qualified user name string (DNS), e.g., mozart@foo.bar.com b. X.500 distinguished name, e.g., C = US, SP = MA, O = GTE Internetworking, CN = Stephen T. Kent. 2. System name (host, security gateway, etc.) a. a fully qualified DNS name, e.g., foo.bar.com b. X.500 distinguished name c. X.500 general name Note that one of the possible values of this selector is "OPAQUE". [REQUIRED for o User ID - native host implementations - BITW and BITS implementations acting as HOSTS with only one user - security gateway implementations for INBOUND processing. o System names -- all implementations] 10. Section 4.4.2 "Selectors" -- Need to clarify "Destination IP Address" sentence -- the one in the outer IP header is not necessarily the one in the IP header/packet being protected. * Changed the text for Destination IP Address from: - Destination IP Address (IPv4 or IPv6): .... Note that this selector is conceptually different from the "Destination IP Address" field in the used to uniquely identify an SA. It could have the same value. to: - Destination IP Address (IPv4 or IPv6): .... Note that this selector is conceptually different from the "Destination IP Address" field in the tuple used to uniquely identify an SA. When a tunnelled packet arrives at the tunnel endpoint, its SPI/Destination address/Protocol are used to look up the SA for this packet in the SAD. This destination address comes from the encapsulating IP header. Once the packet has been processed according to the tunnel SA and has come out of the tunnel, its selectors are "looked up" in the Inbound SPD. The Inbound SPD has a selector called destination address. This IP destination address is the one in the inner (encapsulated) IP header. In the case of a transport'd packet, there will be only one IP header and this ambiguity does not exist. 11. Section 4.4.2 "Selectors" -- Need to correct required support for Transport Layer Protocol (MAY --> MUST for IPv4) and Ports (REQUIRED --> MAY). Need to clarify how fragmentation impacts availability of Port information. * Changed the paragraph on "Transport Layer Protocol" from: [REQUIRED for IPv6 implementations, MAY be supported in IPv4 implementations] to: [REQUIRED for all implementations] * Changed the paragraph on "Source and Destination (e.g., TCP/UDP) Ports" from: [REQUIRED for all implementations] to: [MAY be supported] * Added text at the end of the paragraph on "Source and Destination (e.g., TCP/UDP) Ports" The following table summarizes the relationship between the "Next Header" value in the packet and SPD and the derived Port Selector value for the SPD and SAD. Next Hdr Next Hdr Derived Port Selector Field in Packet in SPD Value in SPD and SAD -------- -------- --------------------------- ESP ESP or ANY ANY (i.e., don't look at it) -don't care- ANY ANY (i.e., don't look at it) specific value specific value NOT ANY (i.e., drop packet) fragment specific value specific value actual port selector field not fragment If the packet has been fragmented, then the port information may not be available in the current fragment. If so, discard the fragment. An ICMP PMTU should be sent for the first fragment, which will have the port information. 12. Section 4.4.3 "Security Association Database" -- Per discussion on the list (email 1/22 to 1/23, Subject: "Security Association Lifetimes in kbytes") -- Need to add a note about how one might handle refreshing of keys when SAs expire. The following approach was described by Dan McDonald (email 1/23). * Changed the relevant bulleted item in Section 4.4.3 from: o Lifetime of this Security Association: a time interval after which an SA must be replaced with a new SA (and new SPI) or terminated, plus an indication of which of these actions should occur. This may be expressed as a time or byte count. to: o Lifetime of this Security Association: a time interval after which an SA must be replaced with a new SA (and new SPI) or terminated, plus an indication of which of these actions should occur. This may be expressed as a time or byte count. If time is employed, and if IKE employs X.509 certificates for SA establishent, the SA lifetime must be constrained by the validity intervals of the certificates, and the NextIssueDate of the CRLs used in the IKE exchange for the SA. Both initiator and responder are responsible for constraining SA lifetime in this fashion. [REQUIRED for all implementations] NOTE: The details of how to handle the refreshing of keys when SAs expire is a local matter. However, one reasonable approach is: (a) If byte count is used, then the implementation SHOULD count the number of bytes to which the IPsec algorithm is applied. (b) There SHOULD be two kinds of lifetime -- a soft lifetime which warns the implementation to initiate action such as setting up a replacement SA and a hard lifetime when the current SA ends. (c) If the entire packet does not get delivered during the SAs lifetime, the packet SHOULD be discarded. 13. Section 4.5 "Basic Combinations of Security Associations" -- The working group has agreed that ONLY the 4 cases outlined here are mandatory. Problems only arise if both the source and destination endpoints of an SA are the same. In that case, the only "nesting" case for which support is required is AH followed by ESP in transport mode i.e., [IP1][AH][ESP][upper]. * Changed 2nd paragraph in Case 4 from: Only tunnel mode is required between H1 and SG2. So the headers in a packet between H1 and SG2 would look like one of the ones in case 2. to: Only tunnel mode is required between H1 and SG2. So the headers for the SA between H1 and SG2 would look like one of the ones in case 2. The headers for the SA between H1 and H2 would like one of the ones in case 1, * Removed the text below that was at the end of the section: "The following combinations of AH and ESP MUST be supported in the indicated contexts: - Cases 1, 3, 4 (between H1 and H2): a. AH in transport mode b. ESP in transport mode b. AH followed by ESP in transport mode d. any one of a, b, or c above AH or ESP in tunnel mode - Cases 1, 2, 3, and 4 (all SAs shown): e. AH in tunnel mode f. ESP in tunnel mode" 14. Section 4.5 "Basic Combinations of Security Associations" -- Do we need to specify support for linking together the multiple ISAKMP negotiations associated with nested SAs? * Given the agreed upon set of SA combinations that MUST be supported, this situation mostly does not arise. There is no requirement to support general nesting which is therefore deferred to IPsecond. However, in cases 1 and 4, Outbound Processing must apply multiple IPsec headers in the "correct" order. Therefore the following notes have been added. In Section 4.5 Case 1, the text has been changed from: Note that either transport or tunnel mode can be selected by the hosts. Also, in transport mode at the sender, first ESP, then AH can be applied to the packet. So the headers in a packet between H1 and H2 could look like any of the following: Transport Tunnel ----------------- --------------------- 1. [IP1][AH][upper] 4. [IP2][AH][IP1][upper] 2. [IP1][ESP][upper] 5. [IP2][ESP][IP1][upper] 3. [IP1][AH][ESP][upper] to: Note that either transport or tunnel mode can be selected by the hosts. So the headers in a packet between H1 and H2 could look like any of the following: Transport Tunnel ----------------- --------------------- 1. [IP1][AH][upper] 4. [IP2][AH][IP1][upper] 2. [IP1][ESP][upper] 5. [IP2][ESP][IP1][upper] 3. [IP1][AH][ESP][upper] Note that there is no requirement to support general nesting, but in transport mode, both AH and ESP can be applied to the packet. In this event, the SA establishment procedure MUST ensure that first ESP, then AH are applied to the packet. In section 4.5 Case 4, the following note has been added after the last paragraph: Note that in this case, the sender MUST apply the transport header before the tunnel header. Therefore the management interface to the IPsec implementation MUST support configuration of the SPD and SAD to ensure this ordering of IPsec header application. 15. Section 5. "IPsec Traffic Processing" -- Need to clarify that Inbound and Outbound processing apply to ALL traffic not just IPsec traffic. * Changed section titles from "IPsec Traffic" to "IP Traffic"? * Added text at the beginning of Section 5 that says: "The SPD MUST be consulted during the processing of all traffic (INBOUND and OUTBOUND), including non-IPsec traffic. Note that the SPD requires distinct entries for inbound and outbound traffic. One can think of this as separate SPDs (inbound vs. outbound). Note also that a nominally separate SPD must be provided for each IPsec-enabled interface." 16. Section 5 -- Per email from SrinivasRao (1/13) re:"Do we need host-to-network conversion for ESP header" -- We interpreted this to refer to the fact that different IPsec platforms will use different native byte ordering and that therefore we need to point out that all of the cryptographic algorithms expect their input in canonical network byte order and generate their output in canonical network byte order. * Added the following text at the beginning of "Section 5. IPsec Traffic Processing" (now changed to "IP Traffic Processing" as described above) before the Output and Input sections. NOTE: All of the cryptographic algorithms used in IPsec expect their input in canonical network byte order (see Appendix in RFC 791) and generate their output in canonical network byte order. IP packets are also transmitted in network byte order. 17. Section 5 -- Need to clarify the default if no match is found in SPD. This applies to inbound and outbound traffic processing. * Added text at the beginning of Section 5 that says: "If no policy is found in the SPD that matches the packet (for either inbound or outbound traffic), the packet MUST be discarded." 18. Section "5.1.1. Selecting and Using an SA or SA Bundle" [outbound processing] -- Several issues have come up. a) How much searching of the SPD and SAD should be done before creating a new SA? * Several approaches to this have been brought up on the list, e.g., see email from S. Kent 12/7/97 in reply to Ly Loi (Subj: "Re: IPSEC arch comments"). There is a tradeoff between spending more time to search the SAD to avoid creating unnecessary SAs and using more space by creating potentially redundant SAs by using the first SPD hit (if it does not point to a matching SA). One possible enhancement would be to note which policies create overlapping SAs when the SPD is created. There weren't many comments, but the general feeling seemed to be in favor of creating an SA for the first policy hit rather than searching the whole SAD. b) How does one make sure that an existing SA (initiated by another system) is used for outgoing traffic that otherwise would be passed through without IPsec processing because local policy requires no IPsec processing at all. * Changed the text to explicitly state that the SPD be linked to the SAD when an SA is created. c) How should one handle failure to find local keying entity? * Add text to address this situation. To address these 3 issues, the text for step 2 has been changed from: 2. Match the packet's selector fields against those in the SA bundles found in (1) to locate the first SA bundle that matches. If no SAs were found or none match, search the SAD for an SA (created by other SPD entries) that matches. If none exist, create an appropriate SA bundle. to: 2. Match the packet's selector fields against those in the SA bundles found in (1) to locate the first SA bundle that matches. If no SAs were found or none match, create an appropriate SA bundle and link the SPD entry to the SAD entry. If no key management entity is found, drop the packet. 19. Sections "5.1.2 Header Construction for Tunnel Mode" and "5.1.2.1 IPv4 -- Header Construction for Tunnel Mode" -- Can the source address of the encapsulating IP header be *any* address of the originating security gateway, i.e., an IP address of the security gateway other than the one through which the packet would be forwarded. * Changed 5.1.2 "Header Construction for Tunnel Mode" from: o The outer IP header Source Address and Destination Address identify the "endpoints" of the tunnel (the encapsulator and decapsulator). The inner IP header Source Address and Destination Addresses identify the original sender and recipient of the datagram, respectively. to: o The outer IP header Source Address and Destination Address identify the "endpoints" of the tunnel (the encapsulator and decapsulator). The inner IP header Source Address and Destination Addresses identify the original sender and recipient of the datagram, respectively. (see footnote 3 after the table in 5.1.2.1 for more details on the encapsulating source IP address.) * Added the following text to footnote 3 of section 5.1.2.1 "IPv4 -- Header Construction for Tunnel Mode". NOTE: In principle, the encapsulating IP source address can be any of the encapsulator's interface addresses or even an address different from any of the encapsulator's IP addresses, (e.g., if it's acting as a NAT box) so long as the address is reachable through the encapsulator from the environment into which the packet is sent. This does not cause a problem because IPsec does not currently have any INBOUND processing requirement that involves the Source Address of the encapsulating IP header. So while the receiving tunnel endpoint looks at the Destination Address in the encapsulating IP header, it only looks at the Source Address in the inner (encapsulated) IP header. 20. Sections "5.1.2.1 IPv4 -- Header Construction for Tunnel Mode" and "5.1.2.2 IPv6 -- Header Construction for Tunnel Mode" -- What should be the "Next Header" field: * Modified footnote 5 in 5.1.2.1 from 5. If Inner Hdr is IPv4, copy the TOS. If Inner Hdr is IPv6, map the Class to TOS. to: 5. If Inner Hdr is IPv4 (Protocol = 4), copy the TOS. If Inner Hdr is IPv6 (Protocol = 41), map the Class to TOS. * Modified footnote 6 in 5.1.2.2 from 6. If Inner Hdr is IPv6, copy the Class. If Inner Hdr IPv4, map the TOS to Class. to: 6. If Inner Hdr is IPv6 (Next Header = 41), copy the Class. If Inner Hdr is IPv4 (Next Header = 4), map the TOS to Class. 21. Section 5.2.1 Selecting and Using an SA or SA bundle (part of 5.2 Processing Inbound IPsec Traffic) -- The question has been raised as to whether there should be OPTIONAL support for "post IPsec processing to include forwarding and additional IPsec processing". * Added the following text at the end of the section: Note that in the case of a security gateway, if forwarding causes a packet to exit via an IPsec-enabled interface, then additional IPsec processing may be applied. 22. Section 5.2.1 Selecting and Using an SA or SA bundle (part of 5.2 Processing Inbound IPsec Traffic) -- Need to add error handling if a matching SA is not found. * Added the following text at the end of step 1. If the SA lookup fails, drop the packet and log/report the error. 23. Section "6. ICMP Processing (relevant to IPsec)" -- Need to clarify that this section applies to ICMP error messages not other ICMP traffic, e.g., Echo/Reply. * At the beginning of the section, added: "The focus of this section is on the handling of ICMP error messages. Other ICMP traffic, e.g., Echo/Reply, should be treated like other traffic and can be protected on an end-to-end basis using SAs in the usual fashion." 24. Section "6. ICMP Processing (relevant to IPsec)" -- Should a security gateway that receives a PMTU message not directed to it, forward that message in an IPsec tunnel? (In the current spec, router-generated IPsec-protected ICMP (error) messages are not subjected to source address checks.) * Modified the first sentence of the section from: "An ICMP message protected by AH or ESP and generated by a router SHOULD be processed and forwarded in a tunnel mode SA, and MUST NOT be subjected to source address checks." to: "An ICMP error message protected by AH or ESP and generated by a router SHOULD be processed and forwarded in a tunnel mode SA. Local policy determines whether or not it is subjected to source address checks by the router at the destination end of the tunnel. Note that if the router at the originating end of the tunnel is forwarding an ICMP error message from another router, the source address check would fail." 25. Section "6. ICMP Processing (relevant to IPsec)" -- Need to note that the authenticity of the returned IP header in an ICMP error message could be invalid even if the source address is OK. * Added the following text at the end of the first paragraph of the section: "Note that even if the source of an ICMP error message is authenticated, the returned IP header could be invalid. Accordingly, the selector values in the IP header SHOULD also be checked to be sure that they are consistent with the selectors for the SA over which the ICMP message was received." 26. Section "6.1.2.2 Calculation of PMTU" -- What should happen if "the PMTU drops below the acceptable limit (e.g., below zero)"? * Per suggestion from Gordon Oliver (12/2/97), added the following note at the end of this section. "Note: In some situations the addition of IPsec headers could result in an effective PMTU (as seen by the host or application) that is unacceptably small. To avoid this problem, the implementation may establish a threshold below which it will not report a reduced PMTU. In such cases, the implementation would apply IPsec and then fragment the resulting packet according to the PMTU. This would result in a more efficient use of the available bandwidth." 27. Section "6.1.2.2 Calculation of PMTU" -- How should a socket-based, host IPsec implementation handle a PMTU message, given that the socket interface would already be aware of the space devoted to local use of IPsec (on the socket in question) * This section has a pointer to the appendix "B.3.2 Calculation of PMTU", which covers this topic but has an example which involves nesting beyond what is currently allowed. B.3.2 has been revised to reflect the simplifications that have been made to nesting support requirements. The original text has been changed from: The calculation of PMTU from an ICMP PMTU has to take into account the addition of any IPsec header by H1 -- AH and/or ESP transport, or ESP or AH tunnel. Within a single host, multiple applications may share an SPI and nesting of security associations may occur. The diagram below illustrates several possible combinations of security associations between a pair of hosts (as viewed from the perspective of one of the hosts.) (ESPt or AHt = tunnel mode; ESPx or AHx = transport mode) Socket 1 ----------------------------------------------- I | n Socket 2 (ESPt/SPI-A) ------------------------------- | t | | e Socket 3 (AHx/SPI-B, ESPt/SPI-C) --- AHx (SPI-D) --- ESPt (SPI-E)--r | n Socket 4 (ESPx/SPI-F, ESPt/SPI-G) -- ESPx (SPI-H) --- e t In order to figure out the PMTU for each socket that maps to SPI-E, it will be necessary to have backpointers from SPI-E to each of the four paths that lead to it -- Socket 1, SPI-A, SPI-D, and SPI-H to: The calculation of PMTU from an ICMP PMTU has to take into account the addition of any IPsec header by H1 -- AH and/or ESP transport, or ESP or AH tunnel. Within a single host, multiple applications may share an SPI and nesting of security associations may occur. (See Section 4.5 Basic Combinations of Security Associations for description of the combinations that MUST be supported). The diagram below illustrates an example of security associations between a pair of hosts (as viewed from the perspective of one of the hosts.) (ESPx or AHx = transport mode) Socket 1 -------------------------| | Socket 2 (ESPx/SPI-A) ---------- AHx (SPI-B) -- Internet In order to figure out the PMTU for each socket that maps to SPI-B, it will be necessary to have backpointers from SPI-B to each of the 2 paths that lead to it -- Socket 1 and Socket 2/SPI-A. 28. Section 8 "Use in Systems Supporting Information Flow Security" -- Need changes to Intro to make it clear that these requirements apply to a wider range of systems than just "MLS". * The text in the Intro (the paragraphs before 8.1) has been slightly re-worded to be more general and cover information flow security rather than just multi-level security. 29. Section "References" -- Need to update references * Verified all references are used in the spec * Put in latest revs of IPsec documents 30. Some minor edits: * Defined SAD when it's first used * Indent 5.2.1 and 5.2.2 in table of contents From owner-ipsec Fri Feb 20 07:25:12 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA16992 for ipsec-outgoing; Fri, 20 Feb 1998 07:24:51 -0500 (EST) Message-Id: <199802200718.CAA07190@relay.hq.tis.com> Date: Fri, 20 Feb 98 2:15:19 EST From: Karen Seo To: internet-drafts@ietf.org cc: ipsec@tis.com, kseo@bbn.com Subject: Internet Draft -- IPsec Architecture Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, Please find attached the Internet Draft for the IPsec Architecture document. Thank you, Karen Network Working Group Stephen Kent, BBN Corp draft-ietf-ipsec-arch-sec-03.txt Randall Atkinson, @Home Network Obsoletes RFC 1825 February 1998 Security Architecture for the Internet Protocol Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and 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". 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 IP Security (IPsec) working group. It is intended that a future version of this draft be submitted to the IESG for publication as a Draft Standard RFC. Comments about this draft may be sent to the authors or to the IPsec WG mailing list . Distribution of this document is unlimited. Copyright (C) The Internet Society (February 1998). All Rights Reserved. Kent, Atkinson [Page 1] Internet Draft Security Architecture for IP February 1998 Table of Contents 1. Introduction............................................................4 1.1 Summary of Contents of Document.....................................4 1.2 Audience............................................................4 1.3 Related Documents...................................................5 2. Design Objectives.......................................................5 2.1 Goals/Objectives/Requirements/Problem Description...................5 2.2 Caveats and Assumptions.............................................6 3. System Overview ........................................................6 3.1 What IPsec Does.....................................................7 3.2 How IPsec Works.....................................................7 3.3 Where IPsec May Be Implemented......................................8 4. Security Associations...................................................9 4.1 Definition and Scope................................................9 4.2 Security Association Functionality.................................11 4.3 Combining Security Associations....................................12 4.4 Security Association Databases.....................................14 4.4.1 The Security Policy Database (SPD)............................14 4.4.2 Selectors.....................................................18 4.4.3 Security Association Database (SAD)...........................21 4.5 Basic Combinations of Security Associations........................23 4.6 SA and Key Management..............................................26 4.6.1 Manual Techniques.............................................27 4.6.2 Automated SA and Key Management...............................27 4.6.3 Locating a Security Gateway...................................28 4.7 Security Associations and Multicast................................29 5. IP Traffic Processing..................................................30 5.1 Outbound IP Traffic Processing.....................................30 5.1.1 Selecting and Using an SA or SA Bundle........................30 5.1.2 Header Construction for Tunnel Mode...........................31 5.1.2.1 IPv4 -- Header Construction for Tunnel Mode..............32 5.1.2.2 IPv6 -- Header Construction for Tunnel Mode..............33 5.2 Processing Inbound IP Traffic......................................33 5.2.1 Selecting and Using an SA or SA Bundle........................33 5.2.2 Handling of AH and ESP tunnels................................34 6. ICMP Processing (relevant to IPsec)....................................35 6.1 PMTU/DF Processing.................................................36 6.1.1 DF Bit........................................................36 6.1.2 Path MTU Discovery (PMTU).....................................36 6.1.2.1 Propagation of PMTU......................................36 6.1.2.2 Calculation of PMTU......................................37 6.1.2.3 Granularity of PMTU Processing...........................37 6.1.2.4 PMTU Aging...............................................38 7. Auditing...............................................................39 8. Use in Systems Supporting Information Flow Security....................39 8.1 Relationship Between Security Associations and Data Sensitivity....40 8.2 Sensitivity Consistency Checking...................................40 Kent, Atkinson [Page 2] Internet Draft Security Architecture for IP February 1998 8.3 Additional MLS Attributes for Security Association Databases.......41 8.4 Additional Inbound Processing Steps for MLS Networking.............41 8.5 Additional Outbound Processing Steps for MLS Networking............41 8.6 Additional MLS Processing for Security Gateways....................42 9. Performance Issues.....................................................42 10. Conformance Requirements..............................................43 11. Security Considerations...............................................43 12. Differences from RFC 1825.............................................43 Acknowledgements..........................................................43 Appendix A -- Glossary....................................................45 Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues.........48 B.1 DF bit.............................................................48 B.2 Fragmentation......................................................48 B.3 Path MTU Discovery.................................................52 B.3.1 Identifying the Originating Host(s)...........................53 B.3.2 Calculation of PMTU...........................................55 B.3.3 Granularity of Maintaining PMTU Data..........................55 B.3.4 Per Socket Maintenance of PMTU Data...........................57 B.3.5 Delivery of PMTU Data to the Transport Layer..................57 B.3.6 Aging of PMTU Data............................................57 Appendix C -- Sequence Space Window Code Example..........................58 Appendix D -- Categorization of ICMP messages.............................60 References................................................................63 Disclaimer................................................................64 Author Information........................................................65 Kent, Atkinson [Page 3] Internet Draft Security Architecture for IP February 1998 1. Introduction 1.1 Summary of Contents of Document This memo specifies the base architecture for IPsec compliant systems. The goal of the architecture is to provide various security services for traffic at the IP layer, in both the IPv4 and IPv6 environments. This document describes the goals of such systems, their components and how they fit together with each other and into the IP environment. It also describes the security services offered by the IPsec protocols, and how these services can be employed in the IP environment. This document does not address all aspects of IPsec architecture. Subsequent documents will address additional architectural details of a more advanced nature, e.g., use of IPsec in NAT environments and more complete support for IP multicast. The following fundamental components of the IPsec security architecture are discussed in terms of their underlying, required functionality. Additional RFCs (see Section 1.3 for pointers to other documents) define the protocols in (a), (c), and (d). a. Security Protocols -- Authentication Header (AH) and Encapsulating Security Payload (ESP) b. Security Associations -- what they are and how they work, how they are managed, associated processing c. Key Management -- manual and automatic (The Internet Key Exchange (IKE)) d. Algorithms for authentication and encryption This document is not an overall Security Architecture for the Internet; it addresses security only at the IP layer, provided through the use of a combination of cryptographic and protocol security mechanisms. The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [Bra97]. 1.2 Audience The target audience for this document includes implementers of this IP security technology and others interested in gaining a general background understanding of this system. In particular, prospective users of this technology (end users or system administrators) are part of the target audience. A glossary is provided as an appendix to help fill in gaps in background/vocabulary. This document assumes that the reader is familiar with the Internet Protocol, related networking technology, and general security terms and concepts. Kent, Atkinson [Page 4] Internet Draft Security Architecture for IP February 1998 1.3 Related Documents As mentioned above, other documents provide detailed definitions of some of the components of IPsec and of their inter-relationship. They include RFCs on the following topics: a. "IP Security Document Roadmap" [TDG97] -- a document providing guidelines for specifications describing encryption and authentication algorithms used in this system. b. security protocols -- RFCs describing the Authentication Header (AH) [KA98a] and Encapsulating Security Payload (ESP) [KA98b] protocols. c. algorithms for authentication and encryption -- a separate RFC for each algorithm. d. automatic key management -- RFCs on "The Internet Key Exchange (IKE)" [HC98], "Internet Security Association and Key Management Protocol (ISAKMP)" [MSST97],"The OAKLEY Key Determination Protocol" [Orm97], and "The Internet IP Security Domain of Interpretation for ISAKMP" [Pip98]. 2. Design Objectives 2.1 Goals/Objectives/Requirements/Problem Description IPsec is designed to provide interoperable, high quality, cryptographically-based security for IPv4 and IPv6. The set of security services offered includes access control, connectionless integrity, data origin authentication, protection against replays (a form of partial sequence integrity), confidentiality (encryption), and limited traffic flow confidentiality. These services are provided at the IP layer, offering protection for IP and/or upper layer protocols. These objectives are met through the use of two traffic security protocols, the Authentication Header (AH) and the Encapsulating Security Payload (ESP), and through the use of cryptographic key management procedures and protocols. The set of IPsec protocols employed in any context, and the ways in which they are employed, will be determined by the security and system requirements of users, applications, and/or sites/organizations. When these mechanisms are correctly implemented and deployed, they ought not to adversely affect users, hosts, and other Internet components that do not employ these security mechanisms for protection of their traffic. These mechanisms also are designed to be algorithm-independent. This modularity permits selection of different sets of algorithms without affecting the other parts of the implementation. For example, different user communities may select Kent, Atkinson [Page 5] Internet Draft Security Architecture for IP February 1998 different sets of algorithms (creating cliques) if required. A standard set of default algorithms is specified to facilitate interoperability in the global Internet. The use of these algorithms, in conjunction with IPsec traffic protection and key management protocols, is intended to permit system and application developers to deploy high quality, Internet layer, cryptographic security technology. 2.2 Caveats and Assumptions The suite of IPsec protocols and associated default algorithms are designed to provide high quality security for Internet traffic. However, the security offered by use of these protocols ultimately depends on the quality of the their implementation, which is outside the scope of this set of standards. Moreover, the security of a computer system or network is a function of many factors, including personnel, physical, procedural, compromising emanations, and computer security practices. Thus IPsec is only one part of an overall system security architecture. Finally, the security afforded by the use of IPsec is critically dependent on many aspects of the operating environment in which the IPsec implementation executes. For example, defects in OS security, poor quality of random number sources, sloppy system management protocols and practices, etc. can all degrade the security provided by IPsec. As above, none of these environmental attributes are within the scope of this or other IPsec standards. 3. System Overview This section provides a high level description of how IPsec works, the components of the system, and how they fit together to provide the security services noted above. The goal of this description is to enable the reader to "picture" the overall process/system, see how it fits into the IP environment, and to provide context for later sections of this document, which describe each of the components in more detail. An IPsec implementation operates in a host or a security gateway environment, affording protection to IP traffic. The protection offered is based on requirements defined by a Security Policy Database (SPD) established and maintained by a user or system administrator, or by an application operating within constraints established by either of the above. In general, packets are selected for one of three processing modes based on IP and transport layer Kent, Atkinson [Page 6] Internet Draft Security Architecture for IP February 1998 header information (Selectors, Section 4.4.2) matched against entries in the database (SPD). Each packet is either afforded IPsec security services, discarded, or allowed to bypass IPsec, based on the applicable database policies identified by the Selectors. 3.1 What IPsec Does IPsec provides security services at the IP layer by enabling a system to select required security protocols, determine the algorithm(s) to use for the service(s), and put in place any cryptographic keys required to provide the requested services. IPsec can be used to protect one or more "paths" between a pair of hosts, between a pair of security gateways, or between a security gateway and a host. (The term "security gateway" is used throughout the IPsec documents to refer to an intermediate system that implements IPsec protocols. For example, a router or a firewall implementing IPsec is a security gateway.) The set of security services that IPsec can provide includes access control, connectionless integrity, data origin authentication, rejection of replayed packets (a form of partial sequence integrity), confidentiality (encryption), and limited traffic flow confidentiality. Because these services are provided at the IP layer, they can be used by any higher layer protocol, e.g., TCP, UDP, ICMP, BGP, etc. NOTE: When encryption is employed within IPsec, it prevents effective compression by lower protocol layers. However, IPsec does not provide its own compression services. Such services may be provided by existing higher layer protocols, or, in the future, in IP itself. The IETF working group, "IP Payload Compression Protocol (ippcp)" has the charter to "develop protocol specifications that make it possible to perform lossless compression on individual payloads before the payload is processed by a protocol that encrypts it. These specifications will allow for compression operations to be performed prior to the encryption of a payload by such protocols as IPsec." 3.2 How IPsec Works IPsec uses two protocols to provide traffic security -- Authentication Header (AH) and Encapsulating Security Payload (ESP). Both protocols are described in more detail in their respective RFCs [KA98a, KA98b]. o The IP Authentication Header (AH) [KA98a] provides connectionless integrity, data origin authentication, and an optional anti-replay service. o The Encapsulating Security Payload (ESP) protocol [KA98b] Kent, Atkinson [Page 7] Internet Draft Security Architecture for IP February 1998 provides confidentiality (encryption), and limited traffic flow confidentiality. It also may provide connectionless integrity, data origin authentication, and an anti-replay service. o Both AH and ESP are vehicles for access control, based on the distribution of cryptographic keys and the management of traffic flows relative to these security protocols. These protocols may be applied alone or in combination with each other to provide a desired set of security services in IPv4 and IPv6. Each protocol supports two modes of use: transport mode and tunnel mode. In transport mode the protocols provide protection primarily for upper layer protocols; in tunnel mode, the protocols are applied to tunneled IP packets. The differences between the two modes are discussed in Section 4. IPsec allows the user (or system administrator) to control the granularity at which a security service is offered. For example, one can create a single encrypted tunnel to carry all the traffic between two security gateways or a separate encrypted tunnel can be created for each TCP connection between each pair of hosts communicating across these gateways. IPsec management must incorporate facilities for specifying: o which security services to use and in what combinations o the granularity at which a given security protection should be applied o the algorithms used to effect cryptographic-based security Because these security services use shared secret values (cryptographic keys), IPsec relies on a separate set of mechanisms for putting these keys in place. (The keys are used for authentication/integrity and encryption services.) This document requires support for both manual and automatic distribution of keys. It specifies a specific public-key based approach (IKE -- [MSST97, Orm97, HC98]) for automatic key management, but other automated key distribution techniques MAY be used. For example, KDC-based systems such as Kerberos and other public-key systems such as SKIP could be employed. 3.3 Where IPsec May Be Implemented There are several ways in which IPsec may be implemented in a host or in conjunction with a router or firewall (to create a security gateway). Several common examples are provided below: a. Integration of IPsec into the native IP implementation. This Kent, Atkinson [Page 8] Internet Draft Security Architecture for IP February 1998 requires access to the IP source code and is applicable to both hosts and security gateways. b. "Bump-in-the-stack" (BITS) implementations, where IPsec is implemented "underneath" an existing implementation of an IP protocol stack, between the native IP and the local network drivers. Source code access for the IP stack is not required in this context, making this implementation approach appropriate for use with legacy systems. This approach, when it is adopted, is usually employed in hosts. c. The use of an outboard crypto processor is a common design feature of network security systems used by the military, and of some commercial systems as well. It is sometimes referred to as a "Bump-in-the-wire" (BITW) implementation. Such implementations may be designed to serve either a host or a gateway (or both). Usually the BITW device is IP addressable. When supporting a single host, it may be quite analogous to a BITS implementation, but in supporting a router or firewall, it must operate like a security gateway. 4. Security Associations This section defines Security Association management requirements for all IPv6 implementations and for those IPv4 implementations that implement AH, ESP, or both. The concept of a "Security Association" (SA) is fundamental to IPsec. Both AH and ESP make use of SAs and a major function of IKE is the establishment and maintenance of Security Associations. All implementations of AH or ESP MUST support the concept of a Security Association as described below. The remainder of this section describes various aspects of Security Association management, defining required characteristics for SA policy management, traffic processing, and SA management techniques. 4.1 Definition and Scope A Security Association (SA) is a simplex "connection" that affords security services to the traffic carried by it. Security services are afforded to an SA by the use of AH, or ESP, but not both. If both AH and ESP protection is applied to a traffic stream, then two (or more) SAs are created to afford protection to the traffic stream. To secure typical, bi-directional communication between two hosts, or between two security gateways, two Security Associations (one in each direction) are required. A security association is uniquely identified by a triple consisting of a Security Parameter Index (SPI), an IP Destination Address, and a security protocol (AH or ESP) identifier. In principle, the Kent, Atkinson [Page 9] Internet Draft Security Architecture for IP February 1998 Destination Address may be a unicast address, an IP broadcast address, or a multicast group address. However, IPsec SA management mechanisms currently are defined only for unicast SAs. Hence, in the discussions that follow, SAs will be described in the context of point-to-point communication, even though the concept is applicable in the point-to-multipoint case as well. As noted above, two types of SAs are defined: transport mode and tunnel mode. A transport mode SA is a security association between two hosts. In IPv4, a transport mode security protocol header appears immediately after the IP header and any options, and before any higher layer protocols (e.g., TCP or UDP). In IPv6, the security protocol header appears after the base IP header and extensions, but may appear before or after destination options, and before higher layer protocols. In the case of ESP, a transport mode SA provides security services only for these higher layer protocols, not for the IP header or any extension headers preceding the ESP header. In the case of AH, the protection is also extended to selected portions of the IP header (and options). For more details on the coverage afforded by AH, see the AH specification [KA98a]. A tunnel mode SA is essentially an SA applied to an IP tunnel. Whenever either end of a security association is a security gateway, the SA MUST be tunnel mode. Thus an SA between two security gateways is always a tunnel mode SA, as is an SA between a host and a security gateway. Note that for the case where traffic is destined for a security gateway, e.g., SNMP commands, the security gateway is acting as a host and transport mode is allowed. But in that case, the security gateway is not acting as a gateway, i.e., not transiting traffic. Two hosts MAY establish a tunnel mode SA between themselves. The requirement for any (transit traffic) SA involving a security gateway to be a tunnel SA arises due to the need to avoid potential problems with regard to fragmentation and reassembly of IPsec packets, and in circumstances where multiple paths (e.g., via different security gateways) exist to the same destination behind the security gateways. For a tunnel mode SA, there is an "outer" IP header that specifies the IPsec processing destination, plus an "inner" IP header that specifies the (apparently) ultimate destination for the packet. The security protocol header appears after the outer IP header, and before the inner IP header. If AH is employed in tunnel mode, portions of the outer IP header are afforded protection (as above), as well as all of the tunneled IP packet (i.e., all of the inner IP header is protected, as well as higher layer protocols). If ESP is employed, the protection is afforded only to the tunneled packet, not to the outer header. Kent, Atkinson [Page 10] Internet Draft Security Architecture for IP February 1998 In summary, a) A host MUST support both transport and tunnel mode. b) A security gateway is required to support only tunnel mode. If it supports transport mode, that should be used only when the security gateway is acting as a host, e.g., for network management. 4.2 Security Association Functionality The set of security services offered by an SA depends on the security protocol selected, the SA mode, the endpoints of the SA, and on the election of optional services within the protocol. For example, AH provides data origin authentication and connectionless integrity for IP datagrams (hereafter referred to as just "authentication"). The "precision" of the authentication service is a function of the granularity of the security association with which AH is employed, as discussed in Section 4.4.2, "Selectors". AH also offers an anti-replay (partial sequence integrity) service at the discretion of the receiver, to help counter denial of service attacks. AH is an appropriate protocol to employ when confidentiality is not required (or is not permitted, e.g , due to government restrictions on use of encryption). AH also provides authentication for selected portions of the IP header, which may be necessary in some contexts. For example, if the integrity of an IPv4 option or IPv6 extension header must be protected en route between sender and receiver, AH can provide this service (except for the non-predictable but mutable parts of the IP header.) ESP always provides confidentiality for traffic. (However, the strength of the confidentiality service will depend, in part, on the encryption algorithm employed.) ESP also may optionally provide authentication (as defined above). If authentication is negotiated for an ESP SA, the receiver also may elect to enforce an anti-replay service with the same features as the AH anti-replay service. The scope of the authentication offered by ESP is narrower than for AH, i.e., the IP header(s) "below" the ESP header is not protected. If only the upper layer protocols need to be authenticated, then ESP authentication is an appropriate choice and is more space efficient than use of AH encapsulating ESP. An ESP (tunnel mode) SA between two security gateways can offer partial traffic flow confidentiality. The use of tunnel mode allows the inner IP headers to be encrypted, concealing the identities of the (ultimate) traffic source and destination. Moreover, ESP payload padding also can be invoked to hide the size of the packets, further concealing the external characteristics of the traffic. Similar traffic flow confidentiality services may be offered when a mobile Kent, Atkinson [Page 11] Internet Draft Security Architecture for IP February 1998 user is assigned a dynamic IP address in a dialup context, and establishes a (tunnel mode) ESP SA to a corporate firewall (acting as a security gateway). Note that fine granularity SAs generally are more vulnerable to traffic analysis than coarse granularity ones which are carrying traffic from many subscribers. 4.3 Combining Security Associations The IP datagrams transmitted over an individual SA are afforded protection by exactly one security protocol, either AH or ESP, but not both. Sometimes a security policy may call for a combination of services for a particular traffic flow that is not achievable with a single SA. In such instances it will be necessary to employ multiple SAs to implement the required security policy. The term "security association bundle" or "SA bundle" is applied to a sequence of SAs through which traffic must be processed to satisfy a security policy. The order of the sequence is defined by the policy. (Note that the SAs that comprise a bundle may terminate at different endpoints. For example, one SA may extend between a mobile host and a security gateway and a second, nested SA may extend to a host behind the gateway.) Security associations may be combined into bundles in two ways: transport adjacency and iterated tunneling. o Transport adjacency refers to applying more than one security protocol to the same IP datagram, without invoking tunneling. This approach to combining AH and ESP allows for only one level of combination; further nesting yields no added benefit since the processing is performed at one IPsec instance at the (ultimate) destination. Host 1 --- Security ---- Internet -- Security --- Host 2 | | Gwy 1 Gwy 2 | | | | | | | -----Security Association 1 (ESP transport)------- | | | -------Security Association 2 (AH transport)---------- o Iterated tunneling refers to the application of multiple layers of security protocols effected through IP tunneling. This approach allows for multiple levels of nesting, since each tunnel can originate or terminate at a different IPsec site along the path. No special treatment is expected for ISAKMP traffic at intermediate security gateways other than what can be specified through appropriate SPD entries (See Case 3 in Section 4.5) Kent, Atkinson [Page 12] Internet Draft Security Architecture for IP February 1998 There are 3 basic cases of iterated tunneling -- support is required only for cases 2 and 3.: 1. both endpoints for the SAs are the same -- The inner and outer tunnels could each be either AH or ESP, though it is unlikely that Host 1 would specify both to be the same, i.e., AH inside of AH or ESP inside of ESP. Host 1 --- Security ---- Internet -- Security --- Host 2 | | Gwy 1 Gwy 2 | | | | | | | -------Security Association 1 (tunnel)---------- | | | | ---------Security Association 2 (tunnel)-------------- 2. one endpoint of the SAs is the same -- The inner and outer tunnels could each be either AH or ESP. Host 1 --- Security ---- Internet -- Security --- Host 2 | | Gwy 1 Gwy 2 | | | | | | ----Security Association 1 (tunnel)---- | | | ---------Security Association 2 (tunnel)------------- 3. neither endpoint is the same -- The inner and outer tunnels could each be either AH or ESP. Host 1 --- Security ---- Internet -- Security --- Host 2 | Gwy 1 Gwy 2 | | | | | | --Security Assoc 1 (tunnel)- | | | -----------Security Association 2 (tunnel)----------- These two approaches also can be combined, i.e., an SA bundle could be constructed from one tunnel mode SA and one or two transport mode SAs, applied in sequence. (See Section 4.5 "Basic Combinations of Security Associations.") Note that nested tunnels can also occur where neither the source nor the destination endpoints of any of the tunnels are the same. In that case, there would be no host or security gateway with a bundle corresponding to the nested tunnels. For transport mode SAs, only one ordering of security protocols seems appropriate. AH is applied to both the upper layer protocols and Kent, Atkinson [Page 13] Internet Draft Security Architecture for IP February 1998 (parts of) the IP header. Thus if AH is used in a transport mode, in conjunction with ESP, AH SHOULD appear as the first header after IP, prior to the appearance of ESP. In that context, AH is applied to the ciphertext output of ESP. In contrast, for tunnel mode SAs, one can imagine uses for various orderings of AH and ESP. The required set of SA bundle types that MUST be supported by a compliant IPsec implementation is described in Section 4.5. 4.4 Security Association Databases Many of the details associated with processing IP traffic in an IPsec implementation are largely a local matter, not subject to standardization. However, some external aspects of the processing must be standardized, to ensure interoperability and to provide a minimum management capability that is essential for productive use of IPsec. This section describes a general model for processing IP traffic relative to security associations, in support of these interoperability and functionality goals. The model described below is nominal; compliant implementations need not match details of this model as presented, but the external behavior of such implementations must be mappable to the externally observable characteristics of this model. There are two nominal databases in this model: the Security Policy Database and the Security Association Database. The former specifies the policies that determine the disposition of all IP traffic inbound or outbound from a host, security gateway, or BITS or BITW IPsec implementation. The latter database contains parameters that are associated with each (active) security association. This section also defines the concept of a Selector, a set of IP and upper layer protocol field values that is used by the Security Policy Database to map traffic to a policy, i.e., an SA (or SA bundle). 4.4.1 The Security Policy Database (SPD) Ultimately, a security association is a management construct used to enforce a security policy in the IPsec environment. Thus an essential element of SA processing is an underlying Security Policy Database (SPD) that specifies what services are to be offered to IP datagrams and in what fashion. The form of the database and its interface are outside the scope of this specification. However, this section does specify certain minimum management functionality that must be provided, to allow a user or system administrator to control how IPsec is applied to traffic transmitted or received by a host or transiting a security gateway. An SPD must discriminate among traffic that is afforded IPsec protection and traffic that is allowed to bypass IPsec. This applies Kent, Atkinson [Page 14] Internet Draft Security Architecture for IP February 1998 to the IPsec protection to be applied by a sender and to the IPsec protection that must be present at the receiver. For any outbound or inbound datagram, three processing choices are possible: discard, bypass IPsec, or apply IPsec. The first choice refers to traffic that is not allowed to exit the host, traverse the security gateway, or be delivered to an application at all. The second choice refers to traffic that is allowed to pass without additional IPsec protection. The third choice refers to traffic that is afforded IPsec protection, and for such traffic the SPD must specify the security services to be provided, protocols to be employed, algorithms to be used, etc. For every IPsec implementation, there MUST be an administrative interface that allows a user or system administrator to manage the SPD. This interface must allow the user (or system administrator) to specify the security processing to be applied to each packet entering or exiting the system, on a packet by packet basis. (In a host IPsec implementation making use of a socket interface, the SPD may not need to be consulted on a per packet basis, but the effect is still the same.) The management interface for the SPD MUST allow creation of entries consistent with the selectors defined in Section 4.4.2, and MUST support ordering of these entries. In host systems, applications MAY be allowed to select what security processing is to be applied to the traffic they generate and consume. (Means of signalling such requests to the IPsec implementation are outside the scope of this standard.) However, the system administrator MUST be able to specify whether or not a user or application can override (default) system policies. Note that application specified policies may satisfy system requirements, so that the system may not need to do additional IPsec processing beyond that needed to meet an application's requirements. The form of the management interface is not specified by this document and may differ for hosts vs. security gateways, and within hosts the interface may differ for socket-based vs. BITS implementations. However, this document does specify a standard set of SPD elements that all IPsec implementations MUST support. The SPD contains an ordered list of policy entries. Each policy entry is keyed by one or more selectors that define the set of IP traffic encompassed by this policy entry. (The required selector types are defined in Section 4.4.2.) These define the granularity of policies or SAs. Each entry includes an indication of whether traffic matching this policy will be bypassed, discarded, or subject to IPsec processing. If IPsec processing is to be applied, the entry includes an SA (or SA bundle) specification, listing the IPsec protocols, modes, and algorithms to be employed, including any nesting requirements. For example, an entry may call for all Kent, Atkinson [Page 15] Internet Draft Security Architecture for IP February 1998 matching traffic to be protected by ESP in transport mode using 3DES-CBC with an explicit IV, nested inside of AH in tunnel mode using HMAC/SHA-1. For each selector, the policy entry specifies how to derive the corresponding values for a new Security Association Database (SAD, see Section 4.4.3) entry from those in the SPD and the packet (Note that at present, ranges are only supported for IP addresses; but wildcarding can be expressed for all selectors): a. use the value in the packet itself -- This will limit use of the SA to those packets which have this packet's value for the selector even if the selector for the policy entry has a range of allowed values or a wildcard for this selector. b. use the value associated with the policy entry -- if this were to be just a single value, then there would be no difference between (b) and (a). However, if the allowed values for the selector were a range, then (b) would enable use of the SA by any packet with a selector value within the range not just by packets with the selector value of the packet that triggered the creation of the SA. c. use a wildcard value -- this can be used to create an SA that can be shared by a broader set of SPD entries (vs (b)). For example, suppose there is an SPD entry where the allowed value for source address is any of a range of hosts (192.168.2.1 to 192.168.2.10). And suppose that a packet is to be sent that has a source address of 192.168.2.3. The value to be used for the SA could be any of the sample values below depending on what the policy entry for this selector says is the source of the selector value: source for the example of value to be new SAD used in the SA selector value --------------- ------------ a. packet 192.168.2.3 (one host) b. SPD entry 192.168.2.1 to 192.168.2.10 (range of hosts) c. wildcard * (any host) Case (c) permits the sharing of an SA (or SA bundle) by multiple SPD entries. Case (a) can be used to prohibit sharing, even among packets that match the same SPD entry. As described below in Section 4.4.3, selectors may include "wildcard" entries and hence the selectors for two entries may overlap. (This is analogous to the overlap that arises with ACLs or filter entries in routers or packet filtering firewalls.) Thus, to ensure consistent, predictable processing, SPD entries MUST be ordered and the SPD MUST always be searched in the same order, so that the first matching entry is consistently selected. (This requirement is Kent, Atkinson [Page 16] Internet Draft Security Architecture for IP February 1998 necessary as the effect of processing traffic against SPD entries must be deterministic, but there is no way to canonicalize SPD entries given the use of wildcards for some selectors.) More detail on matching of packets against SPD entries is provided in Section 5. The SPD can be used to map traffic to specific SAs or SA bundles. Thus it can function both as the reference database for security policy and as the map to existing SAs (or SA bundles). (To accommodate the bypass and discard policies cited above, the SPD also MUST provide a means of mapping traffic to these functions, even though they are not, per se, IPsec processing.) The way in which the SPD operates is different for inbound vs. outbound traffic and it also may differ for host vs. security gateway, BITS, and BITW implementations. Sections 5.1 and 5.2 describe the use of the SPD for outbound and inbound processing, respectively. Because a security policy may require that more than one SA be applied to a specified set of traffic, in a specific order, the policy entry in the SPD must preserve these ordering requirements, when present. Thus, it must be possible for an IPsec implementation to determine that an outbound or inbound packet must be processed thorough a sequence of SAs. Conceptually, for outbound processing, one might imagine links (to the SAD) from an SPD entry for which there are active SAs, and each entry would consist of either a single SA or an ordered list of SAs that comprise an SA bundle. When a packet is matched against an SPD entry and there is an existing SA or SA bundle that can be used to carry the traffic, the processing of the packet is controlled by the SA or SA bundle entry on the list. For an inbound IPsec packet for which multiple IPsec SAs are to be applied, the lookup based on destination address, IPsec protocol, and SPI should identify a single SA. To allow minimization of the number of SAs, the linkage between the SPD and the SAD (at both the sender and the receiver) MUST allow an SA to be used in more than one bundle. The SPD is used to control the flow of ALL traffic through an IPsec system, including security and key management traffic (e.g., ISAKMP) from/to entities behind a security gateway. This means that ISAKMP traffic must be explicitly accounted for in the SPD, else it will be discarded. Note that a security gateway could prohibit traversal of encrypted packets in various ways, e.g., having a DISCARD entry in the SPD for ESP packets or providing proxy key exchange. In the latter case, the traffic would be internally routed to the key management module in the security gateway. Kent, Atkinson [Page 17] Internet Draft Security Architecture for IP February 1998 4.4.2 Selectors An SA (or SA bundle) may be fine-grained or coarse-grained, depending on the selectors used to define the set of traffic for the SA. For example, all traffic between two hosts may be carried via a single SA, and afforded a uniform set of security services. Alternatively, traffic between a pair of hosts might be spread over multiple SAs, depending on the applications being used (as defined by the Next Protocol and Port fields), with different security services offered by different SAs. Similarly, all traffic between a pair of security gateways could be carried on a single SA, or one SA could be assigned for each communicating host pair. The following selector parameters MUST be supported for SA management to facilitate control of SA granularity. Note that in the case of receipt of a packet with an ESP header, e.g., at an encapsulating security gateway or BITW implementation, the transport layer protocol, source/destination ports, and UserID (if present) may be opaque. - Destination IP Address (IPv4 or IPv6): this may be a single IP address (unicast, broadcast, or multicast group), a range of addresses, or a wildcard (mask) address. The latter two are required to support more than one destination system sharing the same SA (e.g., behind a security gateway). Note that this selector is conceptually different from the "Destination IP Address" field in the tuple used to uniquely identify an SA. When a tunnelled packet arrives at the tunnel endpoint, its SPI/Destination address/Protocol are used to look up the SA for this packet in the SAD. This destination address comes from the encapsulating IP header. Once the packet has been processed according to the tunnel SA and has come out of the tunnel, its selectors are "looked up" in the Inbound SPD. The Inbound SPD has a selector called destination address. This IP destination address is the one in the inner (encapsulated) IP header. In the case of a transport'd packet, there will be only one IP header and this ambiguity does not exist. [REQUIRED for all implementations] - Source IP Address(es) (IPv4 or IPv6): this may be a single IP address, range of addresses, or a wildcard (mask) address. The latter two are required to support more than one source system sharing the same SA (e.g., behind a security gateway or in a multihomed host). [REQUIRED for all implementations] Kent, Atkinson [Page 18] Internet Draft Security Architecture for IP February 1998 - Name: There are 2 cases (Note that these name forms are supported in ISAKMP.) 1. User ID a. a fully qualified user name string (DNS), e.g., mozart@foo.bar.com b. X.500 distinguished name, e.g., C = US, SP = MA, O = GTE Internetworking, CN = Stephen T. Kent. 2. System name (host, security gateway, etc.) a. a fully qualified DNS name, e.g., foo.bar.com b. X.500 distinguished name c. X.500 general name Note that one of the possible values of this selector is "OPAQUE". [REQUIRED for o User ID - native host implementations - BITW and BITS implementations acting as HOSTS with only one user - security gateway implementations for INBOUND processing. o System names -- all implementations] - Data sensitivity level: (IPSO/CIPSO labels) [REQUIRED for all systems providing information flow security as per Section 8, OPTIONAL for all other systems.] - Transport Layer Protocol: Obtained from the IPv4 "Protocol" or the IPv6 "Next Header" fields. This may be an individual protocol number. These packet fields may not contain the Transport Protocol due to the presence of IP extension headers, e.g., a Routing Header, AH, ESP, Fragmentation Header, Destination Options, Hop-by-hop options, etc. Note that the Transport Protocol may not be available in the case of receipt of a packet with an ESP header, thus a value of "OPAQUE" SHOULD be supported. [REQUIRED for all implementations] NOTE: To locate the transport protocol, a system has to chain through the packet headers checking the "Protocol" or "Next Header" field until it encounters either one it recognizes as a transport protocol, or until it reaches one that isn't on its list of extension headers, or until it encounters an ESP header that renders the transport protocol opaque. - Source and Destination (e.g., TCP/UDP) Ports: These may be individual UDP or TCP port values or a wildcard port. (The use of the Next Protocol field and the Source and/or Destination Port fields (in conjunction with the Source and/or Destination Kent, Atkinson [Page 19] Internet Draft Security Architecture for IP February 1998 Address fields), as an SA selector is sometimes referred to as "session-oriented keying."). Note that the source and destination ports may not be available in the case of receipt of a packet with an ESP header, thus a value of "OPAQUE" SHOULD be supported. The following table summarizes the relationship between the "Next Header" value in the packet and SPD and the derived Port Selector value for the SPD and SAD. Next Hdr Next Hdr Derived Port Selector Field in Packet in SPD Value in SPD and SAD -------- -------- --------------------------- ESP ESP or ANY ANY (i.e., don't look at it) -don't care- ANY ANY (i.e., don't look at it) specific value specific value NOT ANY (i.e., drop packet) fragment specific value specific value actual port selector field not fragment If the packet has been fragmented, then the port information may not be available in the current fragment. If so, discard the fragment. An ICMP PMTU should be sent for the first fragment, which will have the port information. [MAY be supported] The IPsec implementation context determines how selectors are used. For example, a host implementation integrated into the stack may make use of a socket interface. When a new connection is established the SPD can be consulted and an SA (or SA bundle) bound to the socket. Thus traffic sent via that socket need not result in additional lookups to the SPD/SAD. In contrast, a BITS, BITW, or security gateway implementation needs to look at each packet and perform an SPD/SAD lookup based on the selectors. The allowable values for the selector fields differ between the traffic flow, the security association, and the security policy. The following table summarizes the kinds of entries that one needs to be able to express in the SPD and SAD. It shows how they relate to the fields in data traffic being subjected to IPsec screening. (Note: the "wild" or "wildcard" entry for src and dst addresses includes a mask, range, etc.) Kent, Atkinson [Page 20] Internet Draft Security Architecture for IP February 1998 Field Traffic Value SAD Entry SPD Entry -------- ------------- ---------------- -------------------- src addr single IP addr single,range,wild single,range,wildcard dst addr single IP addr single IP addr single,range,wildcard xpt protocol* xpt protocol single,wildcard single,wildcard src port* single src port single,wildcard single,wildcard dst port* single dst port single,wildcard single,wildcard user id* single user id single,wildcard single,wildcard sec. labels single value single,wildcard single,wildcard * The SAD and SPD entries for these fields could be "OPAQUE" because the traffic value is encrypted. NOTE: In principle, one could have selectors and/or selector values in the SPD which cannot be negotiated for an SA or SA bundle. Examples might include selector values used to select traffic for discarding or enumerated lists which cause a separate SA to be created for each item on the list. For now, this is left for future versions of this document and the list of required selectors and selector values is the same for the SPD and the SAD. However, it is acceptable to have an administrative interface that supports use of selector values which cannot be negotiated provided that it does not mislead the user into believing it is creating an SA with these selector values. For example, the interface may allow the user to specify an enumerated list of values but would result in the creation of a separate policy and SA for each item on the list. A vendor might support such an interface to make it easier for its customers to specify clear and concise policy specifications. 4.4.3 Security Association Database (SAD) In each IPsec implementation there is a nominal Security Association Database, in which each entry defines the parameters associated with one SA. Each SA has an entry in the SAD. For outbound processing, entries are pointed to by entries in the SPD. Note that if an SPD entry does not currently point to an SA that is appropriate for the packet, before it creates an SA, the implementation should check to see if the SAD already has an appropriate SA (created by some other SPD entry). For inbound processing, each entry in the SAD is indexed by a destination IP address, IPsec protocol type, and SPI. The following parameters are associated with each entry in the SAD. This description does not purport to be a MIB, but only a specification of the minimal data items required to support an SA in an IPsec implementation. For inbound processing: The following packet fields are used to look up the SA in the SAD: Kent, Atkinson [Page 21] Internet Draft Security Architecture for IP February 1998 o Outer Header's Destination IP address: the IPv4 or IPv6 Destination address. [REQUIRED for all implementations] o IPsec Protocol: AH or ESP, used as an index for SA lookup in this database. Specifies the IPsec protocol to be applied to the traffic on this SA. [REQUIRED for all implementations] o SPI: the 32-bit value used to distinguish among different SAs terminating at the same destination and using the same IPsec protocol. [REQUIRED for all implementations] For each of the selectors defined in Section 4.4.2, the SA entry in the SAD MUST contain the value or values which were negotiated at the time the SA was created. For the sender, these values are used to decide whether a given SA is appropriate for use with an outbound packet. This is part of checking to see if there is an existing SA that can be used. For the receiver, these values are used to check that the selector values in an inbound packet match those for the SA (and thus indirectly those for the matching policy). For the receiver, this is part of verifying that the SA was appropriate for this packet. (See Section 6 for rules for ICMP messages.) These fields can have the form of specific values, ranges, wildcards, or "OPAQUE" as described in section 4.4.2, "Selectors". The following SAD fields are used in doing IPsec processing: o Sequence Number Counter: a 32-bit value used to generate the Sequence Number field in AH or ESP headers. [REQUIRED for all implementations, but used only for outbound traffic.] o Sequence Counter Overflow: a flag indicating whether overflow of the Sequence Number Counter should generate an auditable event and prevent transmission of additional packets on the SA. [REQUIRED for all implementations, but used only for outbound traffic.] o Anti-Replay Window: a 32-bit counter and a bit-map (or equivalent) used to determine whether an inbound AH or ESP packet is a replay. [REQUIRED for all implementations but used only for inbound traffic.] o AH Authentication algorithm, keys, etc. [REQUIRED for AH implementations] o ESP Encryption algorithm, keys, IV mode, IV, etc. [REQUIRED for ESP implementations] o ESP authentication algorithm, keys, etc. If the authentication service is not selected, this field will be null. Kent, Atkinson [Page 22] Internet Draft Security Architecture for IP February 1998 [REQUIRED for ESP implementations] o Lifetime of this Security Association: a time interval after which an SA must be replaced with a new SA (and new SPI) or terminated, plus an indication of which of these actions should occur. This may be expressed as a time or byte count. If time is employed, and if IKE employs X.509 certificates for SA establishment, the SA lifetime must be constrained by the validity intervals of the certificates, and the NextIssueDate of the CRLs used in the IKE exchange for the SA. Both initiator and responder are responsible for constraining SA lifetime in this fashion. [REQUIRED for all implementations] NOTE: The details of how to handle the refreshing of keys when SAs expire is a local matter. However, one reasonable approach is: (a) If byte count is used, then the implementation SHOULD count the number of bytes to which the IPsec algorithm is applied. (b) There SHOULD be two kinds of lifetime -- a soft lifetime which warns the implementation to initiate action such as setting up a replacement SA and a hard lifetime when the current SA ends. (c) If the entire packet does not get delivered during the SAs lifetime, the packet SHOULD be discarded. o IPsec protocol mode: tunnel, transport or wildcard. Indicates which mode of AH or ESP is applied to traffic on this SA. [REQUIRED for all implementations, unless implicitly defined by context] o Path MTU: any observed path MTU and aging variables. See Section 6.1.2.4 [REQUIRED for all implementations but used only for outbound traffic] 4.5 Basic Combinations of Security Associations This section describes four examples of combinations of security associations that MUST be supported by compliant IPsec hosts or security gateways. Additional combinations of AH and/or ESP in tunnel and/or transport modes MAY be supported at the discretion of the implementor. Compliant implementations MUST be capable of generating these four combinations and on receipt, of processing them, but SHOULD be able to receive and process any combination. The diagrams and text below describe the basic cases. The legend for the diagrams is: Kent, Atkinson [Page 23] Internet Draft Security Architecture for IP February 1998 ==== = one or more security associations (AH or ESP, transport or tunnel) ---- = connectivity (or if so labelled, administrative boundary) Hx = host x SGx = security gateway x X* = X supports IPsec NOTE: The security associations below can be either AH or ESP. The mode (tunnel vs transport) is determined by the nature of the endpoints. For host-to-host SAs, the mode can be either transport or tunnel. Case 1. The case of providing end-to-end security between 2 hosts across the Internet (or an Intranet). ==================================== | | H1* ------ (Inter/Intranet) ------ H2* Note that either transport or tunnel mode can be selected by the hosts. So the headers in a packet between H1 and H2 could look like any of the following: Transport Tunnel ----------------- --------------------- 1. [IP1][AH][upper] 4. [IP2][AH][IP1][upper] 2. [IP1][ESP][upper] 5. [IP2][ESP][IP1][upper] 3. [IP1][AH][ESP][upper] Note that there is no requirement to support general nesting, but in transport mode, both AH and ESP can be applied to the packet. In this event, the SA establishment procedure MUST ensure that first ESP, then AH are applied to the packet. Kent, Atkinson [Page 24] Internet Draft Security Architecture for IP February 1998 Case 2. This case illustrates simple virtual private networks support. =========================== | | ---------------------|---- ---|----------------------- | | | | | | | H1 -- (Local --- SG1* |--- (Internet) ---| SG2* --- (Local --- H2 | | Intranet) | | Intranet) | -------------------------- --------------------------- admin. boundary admin. boundary Only tunnel mode is required here. So the headers in a packet between SG1 and SG2 could look like either of the following: Tunnel --------------------- 4. [IP2][AH][IP1][upper] 5. [IP2][ESP][IP1][upper] Case 3. This case combines cases 1 and 2, adding end-to-end security between the sending and receiving hosts. It imposes no new requirements on the hosts or security gateways, other than a requirement for a security gateway to be configurable to pass IPsec traffic (including ISAKMP traffic) for hosts behind it. =============================================================== | | | ========================= | | | | | ---|-----------------|---- ---|-------------------|--- | | | | | | | | | H1* -- (Local --- SG1* |-- (Internet) --| SG2* --- (Local --- H2* | | Intranet) | | Intranet) | -------------------------- --------------------------- admin. boundary admin. boundary Kent, Atkinson [Page 25] Internet Draft Security Architecture for IP February 1998 Case 4. This covers the situation where a remote host (H1) uses the Internet to reach an organization's firewall (SG2) and to then gain access to some server or other machine (H2). The remote host could be a mobile host (H1) dialing up to a local PPP/ARA server (not shown) on the Internet and then crossing the Internet to the home organization's firewall (SG2), etc. The details of support for this case, (how H1 locates SG2, authenticates it, and verifies its authorization to represent H2) are discussed in Section 4.4.3, "Locating a Security Gateway". ====================================================== | | |============================== | || | | || ---|----------------------|--- || | | | | H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* | ^ | Intranet) | | ------------------------------ could be dialup admin. boundary (optional) to PPP/ARA server Only tunnel mode is required between H1 and SG2. So the choices for the SA between H1 and SG2 would be one of the ones in case 2. The choices for the SA between H1 and H2 would be one of the ones in case 1. Note that in this case, the sender MUST apply the transport header before the tunnel header. Therefore the management interface to the IPsec implementation MUST support configuration of the SPD and SAD to ensure this ordering of IPsec header application. As noted above, support for additional combinations of AH and ESP is optional. Use of other, optional combinations may adversely affect interoperability. 4.6 SA and Key Management IPsec mandates support for both manual and automated SA and cryptographic key management. The IPsec protocols, AH and ESP, are largely independent of the associated SA management techniques, although the techniques involved do affect some of the security services offered by the protocols. For example, the optional anti- replay services available for AH and ESP require automated SA management. Moreover, the granularity of key distribution employed with IPsec determines the granularity of authentication provided. Kent, Atkinson [Page 26] Internet Draft Security Architecture for IP February 1998 (See also a discussion of this issue in Section 4.7.) In general, data origin authentication in AH and ESP is limited by the extent to which secrets used with the authentication algorithm (or with a key management protocol that creates such secrets) are shared among multiple possible sources. The following text describes the minimum requirements for both types of SA management. 4.6.1 Manual Techniques The simplest form of management is manual management, in which a person manually configures each system with keying material and security association management data relevant to secure communication with other systems. Manual techniques are practical in small, static environments but they do not scale well. For example, a company could create a Virtual Private Network (VPN) using IPsec in security gateways at several sites. If the number of sites is small, and since all the sites come under the purview of a single administrative domain, this is likely to be a feasible context for manual management techniques. In this case, the security gateway might selectively protect traffic to and from other sites within the organization using a manually configured key, while not protecting traffic for other destinations. It also might be appropriate when only selected communications need to be secured. A similar argument might apply to use of IPsec entirely within an organization for a small number of hosts and/or gateways. Manual management techniques often employ statically configured, symmetric keys, though other options also exist. 4.6.2 Automated SA and Key Management Widespread deployment and use of IPsec requires an Internet-standard, scalable, automated, SA management protocol. Such support is required to facilitate use of the anti-replay features of AH and ESP, and to accommodate on-demand creation of SAs, e.g., for user- and session-oriented keying. (Note that the notion of "rekeying" an SA actually implies creation of a new SA with a new SPI, a process that generally implies use of an automated SA/key management protocol.) The default automated key management protocol selected for use with IPsec is IKE [MSST97, Orm97, HC98] under the IPsec domain of interpretation [Pip98]. Other automated SA management protocols MAY be employed. When an automated SA/key management protocol is employed, the output from this protocol may be used to generate multiple keys, e.g., for a single ESP SA. This may arise because: Kent, Atkinson [Page 27] Internet Draft Security Architecture for IP February 1998 o the encryption algorithm uses multiple keys (e.g., triple DES) o the authentication algorithm uses multiple keys o both encryption and authentication algorithms are employed The Key Management System may provide a separate string of bits for each key or it may generate one string of bits from which all of them are extracted. If a single string of bits is provided, care needs to be taken to ensure that the parts of the system that map the string of bits to the required keys do so in the same fashion at both ends of the SA. To ensure that the IPsec implementations at each end of the SA use the same bits for the same keys, and irrespective of which part of the system divides the string of bits into individual keys, the encryption key(s) MUST be taken from the first (left-most, high- order) bits and the authentication key(s) MUST be taken from the remaining bits. The number of bits for each key is defined in the relevant algorithm specification RFC. In the case of multiple encryption keys or multiple authentication keys, the specification for the algorithm must specify the order in which they are to be selected from a single string of bits provided to the algorithm. 4.6.3 Locating a Security Gateway This section discusses issues relating to how a host learns about the existence of relevant security gateways and once a host has contacted these security gateways, how it knows that these are the correct security gateways. The details of where the required information is stored is a local matter. Consider a situation in which a remote host (H1) is using the Internet to gain access to a server or other machine (H2) and there is a security gateway (SG2), e.g., a firewall, through which H1's traffic must pass. An example of this situation would be a mobile host (Road Warrior) crossing the Internet to the home organization's firewall (SG2). (See Case 4 in the section 4.5 Basic Combinations of Security Associations.) This situation raises several issues: 1. How does H1 know/learn about the existence of the security gateway SG2? 2. How does it authenticate SG2, and once it has authenticated SG2, how does it confirm that SG2 has been authorized to represent H2? 3. How does SG2 authenticate H1 and verify that H1 is authorized to contact H2? 4. How does H1 know/learn about backup gateways which provide alternate paths to H2? To address these problems, a host or security gateway MUST have an administrative interface that allows the user/administrator to Kent, Atkinson [Page 28] Internet Draft Security Architecture for IP February 1998 configure the address of a security gateway for any sets of destination addresses that require its use. This includes the ability to configure: o the requisite information for locating and authenticating the security gateway and verifying its authorization to represent the destination host. o the requisite information for locating and authenticating any backup gateways and verifying their authorization to represent the destination host. It is assumed that the SPD is also configured with policy information that covers any other IPsec requirements for the path to the security gateway and the destination hos. This document does not address the issue of how to automate the discovery/verification of security gateways. 4.7 Security Associations and Multicast The receiver-orientation of the Security Association implies that, in the case of unicast traffic, the destination system will normally select the SPI value. By having the destination select the SPI value, there is no potential for manually configured Security Associations to conflict with automatically configured (e.g., via a key management protocol) Security Associations or for Security Associations from multiple sources to conflict with each other. For multicast traffic, there are multiple destination systems per multicast group. So some system or person will need to coordinate among all multicast groups to select an SPI or SPIs on behalf of each multicast group and then communicate the group's IPsec information to all of the legitimate members of that multicast group via mechanisms not defined here. Multiple senders to a multicast group SHOULD use a single Security Association (and hence Security Parameter Index) for all traffic to that group when a symmetric key encryption or authentication algorithm is employed. In such circumstances, the receiver knows only that the message came from a system possessing the key for that multicast group. In such circumstances, a receiver generally will not be able to authenticate which system sent the multicast traffic. Specifications for other, more general multicast cases are deferred to later IPsec documents. At the time this specification was published, automated protocols for multicast key distribution were not considered adequately mature for standardization. For multicast groups having relatively few members, manual key distribution or multiple use of existing unicast key Kent, Atkinson [Page 29] Internet Draft Security Architecture for IP February 1998 distribution algorithms such as modified Diffie-Hellman appears feasible. For very large groups, new scalable techniques will be needed. An example of current work in this area is the Group Key Management Protocol (GKMP) [HM97]. 5. IP Traffic Processing The SPD must be consulted during the processing of all traffic (INBOUND and OUTBOUND), including non-IPsec traffic. Note that the SPD requires distinct entries for inbound and outbound traffic. One can think of this as separate SPDs (inbound vs. outbound). Note also that a nominally separate SPD must be provided for each IPsec-enabled interface. If no policy is found in the SPD that matches the packet (for either inbound or outbound traffic), the packet MUST be discarded. NOTE: All of the cryptographic algorithms used in IPsec expect their input in canonical network byte order (see Appendix in RFC 791) and generate their output in canonical network byte order. IP packets are also transmitted in network byte order. 5.1 Outbound IP Traffic Processing 5.1.1 Selecting and Using an SA or SA Bundle In a security gateway or BITW implementation (and in many BITS implementations), each outbound packet is compared against the SPD to determine what processing is required for the packet. If the packet is to be discarded, this is an auditable event. If the traffic is allowed to bypass IPsec processing, the packet continues through "normal" processing for the environment in which the IPsec processing is taking place. If IPsec processing is required, the packet is either mapped to an existing SA (or SA bundle), or a new SA (or SA bundle) is created for the packet. Since a packet's selectors might match multiple policies or multiple extant SAs and since the SPD is ordered, but the SAD is not, IPsec MUST: 1. Match the packet's selector fields against the outbound policies in the SPD to locate the first appropriate policy, which will point to zero or more SA bundles in the SAD. 2. Match the packet's selector fields against those in the SA bundles found in (1) to locate the first SA bundle that matches. If no SAs were found or none match, create an appropriate SA bundle and link the SPD entry to the SAD entry. If no key management entity is found, drop the packet. Kent, Atkinson [Page 30] Internet Draft Security Architecture for IP February 1998 3. Use the SA bundle found/created in (2) to do the required IPsec processing, e.g., authenticate and encrypt. In a host IPsec implementation based on sockets, the SPD will be consulted whenever a new socket is created, to determine what, if any, IPsec processing will be applied to the traffic that will flow on that socket. 5.1.2 Header Construction for Tunnel Mode This section describes the handling of the inner and outer IP headers, extension headers, and options for AH and ESP tunnels. This includes how to construct the encapsulating (outer) IP header, how to handle fields in the inner IP header, and what other actions should be taken. The general idea is modeled after the one used in RFC 2003, "IP Encapsulation with IP": o The outer IP header Source Address and Destination Address identify the "endpoints" of the tunnel (the encapsulator and decapsulator). The inner IP header Source Address and Destination Addresses identify the original sender and recipient of the datagram, respectively. (see footnote 3 after the table in 5.1.2.1 for more details on the encapsulating source IP address.) o The inner IP header is not changed except to decrement the TTL as noted below, and remains unchanged during its delivery to the tunnel exit point. o No change to IP options or extension headers in the inner header occurs during delivery of the encapsulated datagram through the tunnel. o If need be, other protocol headers such as the IP Authentication header may be inserted between the outer IP header and the inner IP header. The tables in the following sub-sections show the handling for the different header/option fields (constructed = the value in the outer field is constructed independently of the value in the inner). Kent, Atkinson [Page 31] Internet Draft Security Architecture for IP February 1998 5.1.2.1 IPv4 -- Header Construction for Tunnel Mode <-- How Outer Hdr Relates Inner Hdr --> Outer Hdr at Inner Hdr at IPv4 Encapsulator Decapsulator Header fields: -------------------- ------------ version 4 (1) no change header length constructed no change TOS copied from inner hdr (5) no change total length constructed no change ID constructed no change flags (DF,MF) constructed, DF (4) no change fragmt offset constructed no change TTL constructed (2) decrement (2) protocol AH, ESP, routing hdr no change checksum constructed no change src address constructed (3) no change dest address constructed (3) no change Options never copied no change 1. The IP version in the encapsulating header can be different from the value in the inner header. 2. The TTL in the inner header is decremented by the encapsulator prior to forwarding and by the decapsulator if it forwards the packet. 3. src and dest addresses depend on the SA, which is used to determine the dest address which in turn determines which src address (net interface) is used to forward the packet. NOTE: In principle, the encapsulating IP source address can be any of the encapsulator's interface addresses or even an address different from any of the encapsulator's IP addresses, (e.g., if it's acting as a NAT box) so long as the address is reachable through the encapsulator from the environment into which the packet is sent. This does not cause a problem because IPsec does not currently have any INBOUND processing requirement that involves the Source Address of the encapsulating IP header. So while the receiving tunnel endpoint looks at the Destination Address in the encapsulating IP header, it only looks at the Source Address in the inner (encapsulated) IP header. 4. configuration determines whether to copy from the inner header (IPv4 only), clear or set the DF. 5. If Inner Hdr is IPv4 (Protocol = 4), copy the TOS. If Inner Hdr is IPv6 (Protocol = 41), map the Class to TOS. Kent, Atkinson [Page 32] Internet Draft Security Architecture for IP February 1998 5.1.2.2 IPv6 -- Header Construction for Tunnel Mode See previous section 5.1.2 for notes 1-5 indicated by (footnote number). <-- How Outer Hdr Relates Inner Hdr ---> Outer Hdr at Inner Hdr at IPv6 Encapsulator Decapsulator Header fields: -------------------- ------------ version 6 (1) no change class copied or configured (6) no change flow id copied or configured no change len constructed no change next header AH,ESP,routing hdr no change hop count constructed (2) decrement (2) src address constructed (3) no change dest address constructed (3) no change Extension headers never copied no change 6. If Inner Hdr is IPv6 (Next Header = 41), copy the Class. If Inner Hdr is IPv4 (Next Header = 4), map the TOS to Class. 5.2 Processing Inbound IP Traffic Prior to performing AH or ESP processing, any IP fragments are reassembled. Each inbound IP datagram to which IPsec processing will be applied is identified by the appearance of the AH or ESP values in the IP Next Protocol field (or of AH or ESP as an extension header in the IPv6 context). Note: Appendix C contains sample code for a bitmask check for a 32 packet window that can be used for implementing anti-replay service. 5.2.1 Selecting and Using an SA or SA Bundle Mapping the IP datagram to the appropriate SA is simplified because of the presence of the SPI in the AH or ESP header. Note that the selector checks are made on the inner headers not the outer (tunnel) headers. The steps followed are: 1. Use the packet's destination address (outer IP header), IPsec protocol, and SPI to look up the SA in the SAD. If the SA lookup fails, drop the packet and log/report the error. 2. Use the SA found in (1) to do the IPsec processing, e.g., authenticate and decrypt. This step includes matching the packet's (Inner Header if tunneled) selectors to the selectors in the SA. Local policy determines the specificity Kent, Atkinson [Page 33] Internet Draft Security Architecture for IP February 1998 of the SA selectors (single value, list, range, wildcard). In general, a packet's source address SHOULD match the SA selector value. (However, an AH or ESP-protected ICMP packet from a gateway may legitimately appear in a tunnel mode SA with a source IP address other than that bound to the SA, and thus such packets should be permitted as exceptions to this check. See Section 6.) Other packet fields MAY match the SA selector values as required by local policy. Do (1) and (2) for every IPsec header until a Transport Protocol Header or an IP header that is NOT for this system is encountered. Keep track of what SAs have been used and their order of application. 3. Find an incoming policy in the SPD that matches the packet. This could be done, for example, by use of backpointers from the SAs to the SPD or by matching the packet's selectors (Inner Header if tunneled) against those of the policy entries in the SPD. 4. Check whether the required IPsec processing has been applied, i.e., verify that the SA's found in (1) and (2) match the kind and order of SAs required by the policy found in (3). NOTE: The correct "matching" policy will not necessarily be the first inbound policy found. If the check in (4) fails, steps (3) and (4) are repeated until all policy entries have been checked or until the check succeeds. At the end of these steps, pass the resulting packet to the Transport Layer or forward the packet. Note that any IPsec headers processed in these steps may have been removed, but that this information, i.e., what SAs were used and the order of their application, may be needed for subsequent IPsec or firewall processing. Note that in the case of a security gateway, if forwarding causes a packet to exit via an IPsec-enabled interface, then additional IPsec processing may be applied. 5.2.2 Handling of AH and ESP tunnels The handling of the inner and outer IP headers, extension headers, and options for AH and ESP tunnels should be performed as described in the tables in Section 5.1. Kent, Atkinson [Page 34] Internet Draft Security Architecture for IP February 1998 6. ICMP Processing (relevant to IPsec) The focus of this section is on the handling of ICMP error messages. Other ICMP traffic, e.g., Echo/Reply, should be treated like other traffic and can be protected on an end-to-end basis using SAs in the usual fashion. An ICMP error message protected by AH or ESP and generated by a router SHOULD be processed and forwarded in a tunnel mode SA. Local policy determines whether or not it is subjected to source address checks by the router at the destination end of the tunnel. Note that if the router at the originating end of the tunnel is forwarding an ICMP error message from another router, the source address check would fail. An ICMP message protected by AH or ESP and generated by a router MUST NOT be forwarded on a transport mode SA (unless the SA has been established to the router acting as a host, e.g., a Telnet connection used to manage a router). An ICMP message generated by a host SHOULD be checked against the source IP address selectors bound to the SA in which the message arrives. Note that even if the source of an ICMP error message is authenticated, the returned IP header could be invalid. Accordingly, the selector values in the IP header SHOULD also be checked to be sure that they are consistent with the selectors for the SA over which the ICMP message was received. The table in Appendix D characterize ICMP messages as being either host generated, router generated, both, unknown/unassigned. ICMP messages falling into the last two categories should be handled as determined by the receiver's policy. An ICMP message not protected by AH or ESP is unauthenticated and its processing and/or forwarding may result in denial of service. This suggests that, in general, it would be desirable to ignore such messages. However, it is expected that many routers (vs. security gateways) will not implement IPsec for transit traffic and thus strict adherence to this rule would cause many ICMP messages to be discarded. The result is that some critical IP functions would be lost, e.g., redirection and PMTU processing. Thus it MUST be possible to configure an IPsec implementation to accept or reject (router) ICMP traffic as per local security policy. The remainder of this section addresses how PMTU processing MUST be performed at hosts and security gateways. It addresses processing of both authenticated and unauthenticated ICMP PMTU messages. However, as noted above, unauthenticated ICMP messages MAY be discarded based on local policy. Kent, Atkinson [Page 35] Internet Draft Security Architecture for IP February 1998 6.1 PMTU/DF Processing 6.1.1 DF Bit In cases where a system (host or gateway) adds an encapsulating header (ESP tunnel or AH tunnel), it MUST support the option of copying the DF bit from the original packet to the encapsulating header (and processing ICMP PMTU messages). This means that it MUST be possible to configure the system's treatment of the DF bit (set, clear, copy from encapsulated header) for each interface. (See Appendix B for rationale.) 6.1.2 Path MTU Discovery (PMTU) This section discusses IPsec handling for Path MTU Discovery messages. ICMP PMTU is used here to refer to an ICMP message for: IPv4 (RFC 792): - Type = 3 (Destination Unreachable) - Code = 4 (Fragmentation needed and DF set) - Next-Hop MTU in the low-order 16 bits of the second word of the ICMP header (labelled "unused" in RFC 792), with high-order 16 bits set to zero IPv6 (RFC 1885): - Type = 2 (Packet Too Big) - Code = 0 (Fragmentation needed and DF set) - Next-Hop MTU in the 32 bit MTU field of the ICMP6 message 6.1.2.1 Propagation of PMTU The amount of information returned with the ICMP PMTU message (IPv4 or IPv6) is limited and this affects what selectors are available for use in further propagating the PMTU information. (See Appendix B for more detailed discussion of this topic.) o PMTU message with 64 bits of IPsec header -- If the ICMP PMTU message contains only 64 bits of the IPsec header (minimum for IPv4), then a security gateway MUST support the following options on a per SPI/SA basis: a. if the originating host can be determined (or the possible sources narrowed down to a manageable number), send the PMTU information to all the possible originating hosts. b. if the originating host cannot be determined, store the PMTU with the SA and wait until the next packet(s) arrive from the Kent, Atkinson [Page 36] Internet Draft Security Architecture for IP February 1998 originating host for the relevant security association. If the packet(s) are bigger than the PMTU, drop the packet(s), and compose ICMP PMTU message(s) with the new packet(s) and the updated PMTU, and send the ICMP message(s) about the problem to the originating host. Retain the PMTU information for any message that might arrive subsequently (see Section 6.1.2.4, "PMTU Aging"). o PMTU message with >64 bits of IPsec header -- If the ICMP message contains more information from the original packet, e.g., the 576 byte minimum for IPv6, then there MAY be enough non-opaque information to immediately determine to which host to propagate the ICMP/PMTU message and to provide that system with the 5 fields (source address, destination address, source port, destination port, transport protocol) needed to determine where to store/update the PMTU. Under such circumstances, a security gateway MUST generate an ICMP PMTU message immediately upon receipt of an ICMP PMTU from further down the path. o Distributing the PMTU to the Transport Layer -- The host mechanism for getting the updated PMTU to the transport layer is unchanged, as specified in RFC 1191 (Path MTU Discovery). 6.1.2.2 Calculation of PMTU The calculation of PMTU from an ICMP PMTU MUST take into account the addition of any IPsec header -- AH transport, ESP transport, AH/ESP transport, ESP tunnel, AH tunnel. (See Appendix B for discussion of implementation issues.) Note: In some situations the addition of IPsec headers could result in an effective PMTU (as seen by the host or application) that is unacceptably small. To avoid this problem, the implementation may establish a threshold below which it will not report a reduced PMTU. In such cases, the implementation would apply IPsec and then fragment the resulting packet according to the PMTU. This would result in a more efficient use of the available bandwidth. 6.1.2.3 Granularity of PMTU Processing In hosts, the granularity with which ICMP PMTU processing can be done differs depending on the implementation situation. Looking at a host, there are 3 situations that are of interest with respect to PMTU issues (See Appendix B for additional details on this topic.): a. Integration of IPsec into the native IP implementation b. Bump-in-the-stack implementations, where IPsec is implemented "underneath" an existing implementation of a TCP/IP protocol Kent, Atkinson [Page 37] Internet Draft Security Architecture for IP February 1998 stack, between the native IP and the local network drivers c. No IPsec implementation -- This case is included because it is relevant in cases where a security gateway is sending PMTU information back to a host. Only in case (a) can the PMTU data be maintained at the same granularity as communication associations. In (b) and (c), the IP layer will only be able to maintain PMTU data at the granularity of source and destination IP addresses (and optionally ToS), as described in RFC 1191. This is an important difference, because more than one communication association may map to the same source and destination IP addresses, and each communication association may have a different amount of IPsec header overhead (e.g., due to use of different transforms or different algorithms). Implementation of the calculation of PMTU and support for PMTUs at the granularity of individual communication associations is a local matter. However, a socket-based implementation of IPsec in a host SHOULD maintain the information on a per socket basis. Bump in the stack systems MUST pass an ICMP PMTU to the host IP implementation, after adjusting it for any IPsec header overhead added by these systems. The calculation of the overhead SHOULD be determined by analysis of the SPI and any other selector information present in a returned ICMP PMTU message. 6.1.2.4 PMTU Aging In all systems (host or gateway) implementing IPsec and maintaining PMTU information, the PMTU associated with a security association (transport or tunnel) MUST be "aged" and some mechanism put in place for updating the PMTU in a timely manner, especially for discovering if the PMTU is smaller than it needs to be. A given PMTU has to remain in place long enough for a packet to get from the source end of the security association to the system at the other end of the security association and propagate back an ICMP error message if the current PMTU is too big. Note that if there are nested tunnels, multiple packets and round trip times might be required to get an ICMP message back to an encapsulator or originating host. Systems SHOULD use the approach described in the Path MTU Discovery document (RFC 1191, Section 6.3), which suggests periodically resetting the PMTU to the first-hop data-link MTU and then letting the normal PMTU Discovery processes update the PMTU as necessary. The period SHOULD be configurable. Kent, Atkinson [Page 38] Internet Draft Security Architecture for IP February 1998 7. Auditing Not all systems that implement IPsec will implement auditing. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in the AH and ESP specifications and for each of these events a minimum set of information that SHOULD be included in an audit log is defined. Additional information also MAY be included in the audit log for each of these events, and additional events, not explicitly called out in this specification, also MAY result in audit log entries. There is no requirement for the receiver to transmit any message to the purported transmitter in response to the detection of an auditable event, because of the potential to induce denial of service via such action. 8. Use in Systems Supporting Information Flow Security Information of various sensitivity levels may be carried over a single network. Information labels (e.g., Unclassified, Company Proprietary, Secret) [DoD85, DoD87] are often employed to distinguish such information. The use of labels facilitates segregation of information, in support of information flow security models, e.g., the Bell-LaPadula model [BL73]. Such models, and corresponding supporting techology, are designed to prevent the unauthorized flow of sensitive information, even in the face of Trojan Horse attacks. Conventional, discretionary access control (DAC) mechanisms, e.g., based on access control lists, generally are not sufficient to support such policies, and thus facilities such as the SPD do not suffice in such environments. In the military context, technology that supports such models is often referred to as multi-level security (MLS). Computers and networks often are designated "multi-level secure" if they support the separation of labelled data in conjunction with information flow security policies. Although such technology is more broadly applicable than just military applications, this document uses the acronym "MLS" to designate the technology, consistent with much extant literature. IPsec mechanisms can easily support MLS networking. MLS networking requires the use of strong Mandatory Access Controls (MAC), which unprivileged users or unprivileged processes are incapable of controlling or violating. This section pertains only to the use of these IP security mechanisms in MLS (information flow security policy) environments. Nothing in this section applies to systems not claiming to provide MLS. As used in this section, "sensitivity information" might include Kent, Atkinson [Page 39] Internet Draft Security Architecture for IP February 1998 implementation-defined hierarchic levels, categories, and/or releasability information. AH can be used to provide strong authentication in support of mandatory access control decisions in MLS environments. If explicit IP sensitivity information (e.g., IPSO [Ken91]) is used and confidentiality is not considered necessary within the particular operational environment, AH can be used to authenticate the binding between sensitivity labels in the IP header and the IP payload (including user data). This is a significant improvement over labeled IPv4 networks where the sensitivity information is trusted even though there is no authentication or cryptographic binding of the information to the IP header and user data. IPv4 networks might or might not use explicit labelling. IPv6 will normally use implicit sensitivity information that is part of the IPsec Security Association but not transmitted with each packet instead of using explicit sensitivity information. All explicit IP sensitivity information MUST be authenticated using either ESP, AH, or both. Encryption is useful and can be desirable even when all of the hosts are within a protected environment, for example, behind a firewall or disjoint from any external connectivity. ESP can be used, in conjunction with appropriate key management and encryption algorithms, in support of both DAC and MAC. (The choice of encryption and authentication algorithms, and the assurance level of an IPsec implementation will determine the environments in which an implementation may be deemed sufficient to satisfy MLS requirements.) Key management can make use of sensitivity information to provide MAC. IPsec implementations on systems claiming to provide MLS SHOULD be capable of using IPsec to provide MAC for IP-based communications. 8.1 Relationship Between Security Associations and Data Sensitivity Both the Encapsulating Security Payload and the Authentication Header can be combined with appropriate Security Association policies to provide multi-level secure networking. In this case each SA (or SA bundle) is normally used for only a single instance of sensitivity information. For example, "PROPRIETARY - Internet Engineering" must be associated with a different SA (or SA bundle) from "PROPRIETARY - Finance". 8.2 Sensitivity Consistency Checking An MLS implementation (both host and router) MAY associate sensitivity information, or a range of sensitivity information with an interface, or a configured IP address with its associated prefix (the latter is sometimes referred to as a logical interface, or an interface alias). If such properties exist, an implementation SHOULD Kent, Atkinson [Page 40] Internet Draft Security Architecture for IP February 1998 compare the sensitivity information associated with the packet against the sensitivity information associated with the interface or address/prefix from which the packet arrived, or through which the packet will depart. This check will either verify that the sensitivities match, or that the packet's sensitivity falls within the range of the interface or address/prefix. The checking SHOULD be done on both inbound and outbound processing. 8.3 Additional MLS Attributes for Security Association Databases Section 4.4 discussed two Security Association databases (the Security Policy Database (SPD) and the Security Association Database (SAD)) and the associated policy selectors and SA attributes. MLS networking introduces an additional selector/attribute: - Sensitivity information. The Sensitivity information aids in selecting the appropriate algorithms and key strength, so that the traffic gets a level of protection appropriate to its importance or sensitivity as described in section 8.1. The exact syntax of the sensitivity information is implementation defined. 8.4 Additional Inbound Processing Steps for MLS Networking After an inbound packet has passed through IPsec processing, an MLS implementation SHOULD first check the packet's sensitivity (as defined by the SA (or SA bundle) used for the packet) with the interface or address/prefix as described in section 8.2 before delivering the datagram to an upper-layer protocol or forwarding it. The MLS system MUST retain the binding between the data received in an IPsec protected packet and the sensitivity information in the SA or SAs used for processing, so appropriate policy decisions can be made when delivering the datagram to an application or forwarding engine. The means for maintaining this binding are implementation specific. 8.5 Additional Outbound Processing Steps for MLS Networking An MLS implementation of IPsec MUST perform two additional checks besides the normal steps detailed in section 5.1.1. When consulting the SPD or the SAD to find an outbound security association, the MLS implementation MUST use the sensitivity of the data to select an appropriate outbound SA or SA bundle. The second check comes before forwarding the packet out to its destination, and is the sensitivity Kent, Atkinson [Page 41] Internet Draft Security Architecture for IP February 1998 consistency checking described in section 8.2. 8.6 Additional MLS Processing for Security Gateways An MLS security gateway MUST follow the previously mentioned inbound and outbound processing rules as well as perform some additional processing specific to the intermediate protection of packets in an MLS environment. A security gateway MAY act as an outbound proxy, creating SAs for MLS systems that originate packets forwarded by the gateway. These MLS systems may explicitly label the packets to be forwarded, or the whole originating network may have sensitivity characteristics associated with it. The security gateway MUST create and use appropriate SAs for AH, ESP, or both, to protect such traffic it forwards. Similarly such a gateway SHOULD accept and process inbound AH and/or ESP packets and forward appropriately, using explicit packet labeling, or relying on the sensitivity characteristics of the destination network. 9. Performance Issues The use of IPsec imposes computational performance costs on the hosts or security gateways that implement these protocols. These costs are associated with the memory needed for IPsec code and data structures, and the computation of integrity check values, encryption and decryption, and added per-packet handling. The per-packet computational costs will be manifested by increased latency and, possibly, reduced throughout. Use of SA/key management protocols, especially ones that employ public key cryptography, also adds computational performance costs to use of IPsec. These per- association computational costs will be manifested in terms of increased latency in association establishment. For many hosts, it is anticipated that software-based cryptography will not appreciably reduce throughput, but hardware may be required for security gateways (since they represent aggregation points), and for some hosts. The use of IPsec also imposes bandwidth utilization costs on transmission, switching, and routing components of the Internet infrastructure, components not implementing IPsec. This is due to the increase in the packet size resulting from the addition of AH and/or ESP headers, AH and ESP tunneling (which adds a second IP header), and the increased packet traffic associated with key management protocols. It is anticipated that, in most instances, this increased bandwidth demand will not noticeably affect the Internet infrastructure. However, in some instances, the effects may Kent, Atkinson [Page 42] Internet Draft Security Architecture for IP February 1998 be significant, e.g., transmission of ESP encrypted traffic over a dialup link that otherwise would have compressed the traffic. Note: The initial SA establishment overhead will be felt in the first packet. This delay could impact the transport layer and application. For example, it could cause TCP to retransmit the SYN before the ISAKMP exchange is done. The effect of the delay would be different on UDP than TCP because TCP shouldn't transmit anything other than the SYN until the connection is set up whereas UDP will go ahead and transmit data beyond the first packet. Note: As discussed earlier, compression can still be employed at layers above IP. There is an IETF working group (IP Payload Compression Protocol (ippcp)) working on "protocol specifications that make it possible to perform lossless compression on individual payloads before the payload is processed by a protocol that encrypts it. These specifications will allow for compression operations to be performed prior to the encryption of a payload by IPsec protocols." 10. Conformance Requirements All IPv4 systems that claim to implement IPsec MUST comply with all requirements of the Security Architecture document. All IPv6 systems MUST comply with all requirements of the Security Architecture document. 11. Security Considerations The focus of this document is security; hence security considerations permeate this specification. 12. Differences from RFC 1825 This architecture document differs substantially from RFC 1825 in detail and in organization, but the fundamental notions are unchanged. This document provides considerable additional detail in terms of compliance specifications. It introduces the SPD and SAD, and the notion of SA selectors. It is aligned with the new versions of AH and ESP, which also differ from their predecessors. Specific requirements for supported combinations of AH and ESP are newly added, as are details of PMTU management. 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 Kent, Atkinson [Page 43] Internet Draft Security Architecture for IP February 1998 NLSP, the proposed swIPe security protocol [SDNS, ISO, IB93, IBK93], and the work done for SNMP Security and SNMPv2 Security. For over 2 years (although it sometimes seems *much* longer) , 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 Karen Seo for providing extensive help in the review, editing, background research, and coordination for this version of the specification. The authors would also 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, James Hughes, Phil Karn, Frank Kastenholz, Perry Metzger, David Mihelcic, Hilarie Orman, Norman Shulman, William Simpson, Harry Varnis, and Nina Yuan. Kent, Atkinson [Page 44] Internet Draft Security Architecture for IP February 1998 Appendix A -- Glossary This section provides definitions for several key terms that are employed in this document. Other documents provide additional definitions and background information relevant to this technology, e.g., [VK83, HA94]. Included in this glossary are generic security service and security mechanism terms, plus IPsec-specific terms. Access Control Access control is a security service that prevents unauthorized use of a resource, including the prevention of use of a resource in an unauthorized manner. In the IPsec context, the resource to which access is being controlled is often: o for a host, computing cycles or data o for a security gateway, a network behind the gateway or bandwidth on that network. Anti-replay [See "Integrity" below] Authentication This term is used informally to refer to the combination of two nominally distinct security services, data origin authentication and connectionless integrity. See the definitions below for each of these services. Availability Availability, when viewed as a security service, addresses the security concerns engendered by attacks against networks that deny or degrade service. For example, in the IPsec context, the use of anti-replay mechanisms in AH and ESP support availability. Confidentiality Confidentiality is the security service that protects data from unauthorized disclosure. The primary confidentiality concern in most instances is unauthorized disclosure of application level data, but disclosure of the external characteristics of communication also can be a concern in some circumstances. Traffic flow confidentiality is the service that addresses this latter concern by concealing source and destination addresses, message length, or frequency of communication. In the IPsec context, using ESP in tunnel mode, especially at a security gateway, can provide some level of traffic flow confidentiality. (See also traffic analysis, below.) Kent, Atkinson [Page 45] Internet Draft Security Architecture for IP February 1998 Encryption Encryption is a security mechanism used to transform data from an intelligible form (plaintext) into an unintelligible form (ciphertext), to provide confidentiality. The inverse transformation process is designated "decryption". Oftimes the term "encryption" is used to generically refer to both processes. Data Origin Authentication Data origin authentication is a security service that verifies the identity of the claimed source of data. This service is usually bundled with connectionless integrity service. Integrity Integrity is a security service that ensures that modifications to data are detectable. Integrity comes in various flavors to match application requirements. IPsec supports two forms of integrity: connectionless and a form of partial sequence integrity. Connectionless integrity is a service that detects modification of an individual IP datagram, without regard to the ordering of the datagram in a stream of traffic. The form of partial sequence integrity offered in IPsec is referred to as anti-replay integrity, and it detects arrival of duplicate IP datagrams (within a constrained window). This is in contrast to connection-oriented integrity, which imposes more stringent sequencing requirements on traffic, e.g., to be able to detect lost or re-ordered messages. Although authentication and integrity services often are cited separately, in practice they are intimately connected and almost always offered in tandem. Security Association (SA) A simplex (uni-directional) logical connection, created for security purposes. All traffic traversing an SA is provided the same security processing. In IPsec, an SA is an internet layer abstraction implemented through the use of AH or ESP. Security Gateway A security gateway is an intermediate system that acts as the communications interface between two networks. The set of hosts (and networks) on the external side of the security gateway is viewed as untrusted (or less trusted), while the networks and hosts and on the internal side are viewed as trusted (or more trusted). The internal subnets and hosts served by a security gateway are presumed to be trusted by virtue of sharing a common, local, security administration. (See "Trusted Subnetwork" below.) In the IPsec context, a security gateway is a point at which AH and/or ESP is implemented in order to serve a set of internal hosts, providing security services for these hosts when they communicate with external hosts also employing IPsec (either Kent, Atkinson [Page 46] Internet Draft Security Architecture for IP February 1998 directly or via another security gateway). SPI Acronym for "Security Parameters Index". The combination of a destination address, a security protocol, and an SPI uniquely identifies a security association (SA, see above). The SPI is carried in AH and ESP protocols to enable the receiving system to select the SA under which a received packet will be processed. An SPI has only local significance, as defined by the creator of the SA (usually the receiver of the packet carrying the SPI); thus an SPI is generally viewed as an opaque bit string. However, the creator of an SA may choose to interpret the bits in an SPI to facilitate local processing. Traffic Analysis The analysis of network traffic flow for the purpose of deducing information that is useful to an adversary. Examples of such information are frequency of transmission, the identities of the conversing parties, sizes of packets, flow identifiers, etc. [Sch94] Trusted Subnetwork A subnetwork containing hosts and routers that trust each other not to engage in active or passive attacks. There also is an assumption that the underlying communications channel (e.g., a LAN or CAN) isn't being attacked by other means. Kent, Atkinson [Page 47] Internet Draft Security Architecture for IP February 1998 Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues B.1 DF bit In cases where a system (host or gateway) adds an encapsulating header (e.g., ESP tunnel), should/must the DF bit in the original packet be copied to the encapsulating header? Fragmenting seems correct for some situations, e.g., it might be appropriate to fragment packets over a network with a very small MTU, e.g., a packet radio network, or a cellular phone hop to mobile node, rather than propagate back a very small PMTU for use over the rest of the path. In other situations, it might be appropriate to set the DF bit in order to get feedback from later routers about PMTU constraints which require fragmentation. The existence of both of these situations argues for enabling a system to decide whether or not to fragment over a particular network "link", i.e., for requiring an implementation to be able to copy the DF bit (and to process ICMP PMTU messages), but making it an option to be selected on a per interface basis. In other words, an administrator should be able to configure the router's treatment of the DF bit (set, clear, copy from encapsulated header) for each interface. Note: If a bump-in-the-stack implementation of IPsec attempts to apply different IPsec algorithms based on source/destination ports, it will be difficult to apply Path MTU adjustments. B.2 Fragmentation Fragmentation MUST be done after outbound IPsec processing. Reassembly MUST be done before inbound IPsec processing. The general reasoning is shown below (delimited by the ****'s). NOTE: IPsec always has to figure out what the encapsulating IP header fields are. This is independent of where you insert IPsec and is intrinsic to the definition of IPsec. Therefore any IPsec implementation that is not integrated into an IP implementation must include code to construct the necessary IP headers (e.g., IP2): o AH-tunnel --> IP2-AH-IP1-Transport-Data o ESP-tunnel --> IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer ********************************************************************** Overall, the fragmentation/reassembly approach described above works for all cases examined. Kent, Atkinson [Page 48] Internet Draft Security Architecture for IP February 1998 AH Xport AH Tunnel ESP Xport ESP Tunnel Implementation approach IPv4 IPv6 IPv4 IPv6 IPv4 IPv6 IPv4 IPv6 ----------------------- ---- ---- ---- ---- ---- ---- ---- ---- Hosts (integr w/ IP stack) Y Y Y Y Y Y Y Y Hosts (betw/ IP and drivers) Y Y Y Y Y Y Y Y S. Gwy (integr w/ IP stack) Y Y Y Y Outboard crypto processor * * If the crypto processor system has its own IP address, then it is covered by the security gateway case. This box receives the packet from the host and performs IPsec processing. It has to be able to handle the same AH, ESP, and related IPv4/IPv6 tunnel processing that a security gateway would have to handle. If it doesn't have it's own address, then it is similar to the bump-in-the stack implementation between IP and the network drivers. The following analysis assumes that: 1. There is only one IPsec module in a given system's stack. There isn't an IPsec module A (adding ESP/encryption and thus) hiding the transport protocol, SRC port, and DEST port from IPsec module B. 2. There are several places where IPsec could be implemented (as shown in the table above). a. Hosts with integration of IPsec into the native IP implementation. Implementer has access to the source for the stack. b. Hosts with bump-in-the-stack implementations, where IPsec is implemented between IP and the local network drivers. Source access for stack is not available; but there are well-defined interfaces that allows the IPsec code to be incorporated into the system. c. Security gateways and outboard crypto processors with integration of IPsec into the stack. 3. Not all of the above approaches are feasible in all hosts. But it was assumed that for each approach, there are some hosts for whom the approach is feasible. For each of the above 3 categories, there are IPv4 and IPv6, AH transport and tunnel modes, and ESP transport and tunnel modes -- for a total of 24 cases (3 x 2 x 4). Some header fields and interface fields are listed here for ease of reference -- they're not in the header order, but instead listed to allow comparison between the columns. (* = not covered by AH authentication. ESP authentication doesn't cover any headers that precede it.) Kent, Atkinson [Page 49] Internet Draft Security Architecture for IP February 1998 IP/Transport Interface IPv4 IPv6 (RFC 1122 -- Sec 3.4) ---- ---- ---------------------- Version = 4 Version = 6 Header Len *TOS Class,Flow Lbl TOS Packet Len Payload Len Len ID ID (optional) *Flags DF *Offset *TTL *Hop Limit TTL Protocol Next Header *Checksum Src Address Src Address Src Address Dst Address Dst Address Dst Address Options? Options? Opt ? = AH covers Option-Type and Option-Length, but might not cover Option-Data. The results for each of the 24 cases is shown below ("works" = will work if system fragments after outbound IPsec processing, reassembles before inbound IPsec processing). Notes indicate implementation issues. a. Hosts (integrated into IP stack) o AH-transport --> (IP1-AH-Transport-Data) - IPv4 -- works - IPv6 -- works o AH-tunnel --> (IP2-AH-IP1-Transport-Data) - IPv4 -- works - IPv6 -- works o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works b. Hosts (Bump-in-the-stack) -- put IPsec between IP layer and network drivers. In this case, the IPsec module would have to do something like one of the following for fragmentation and reassembly. - do the fragmentation/reassembly work itself and send/receive the packet directly to/from the network layer. In AH or ESP transport mode, this is fine. In AH or ESP tunnel mode where the tunnel is to the ultimate destination, this is fine. But in AH or ESP tunnel modes Kent, Atkinson [Page 50] Internet Draft Security Architecture for IP February 1998 where the tunnel end is different from the ultimate destination and where the source host is multi-homed, this approach could result in sub-optimal routing because the IPsec module may be unable to obtain the information needed (LAN interface and next-hop gateway) to direct the packet to the appropriate network interface. This is not a problem if the interface and next-hop gateway are the same for the ultimate destination and for the tunnel end. But if they are different, then IPsec would need to know the LAN interface and the next-hop gateway for the tunnel end. (Note: The tunnel end (security gateway) is highly likely to be on the regular path to the ultimate destination. But there could also be more than one path to the destination, e.g., the host could be at an organization with 2 firewalls. And the path being used could involve the less commonly chosen firewall.) OR - pass the IPsec'd packet back to the IP layer where an extra IP header would end up being pre-pended and the IPsec module would have to check and let IPsec'd fragments go by. OR - pass the packet contents to the IP layer in a form such that the IP layer recreates an appropriate IP header At the network layer, the IPsec module will have access to the following selectors from the packet -- SRC address, DST address, TOS, Next Protocol, and if there's a transport layer header --> SRC port and DST port. One cannot assume IPsec has access to the User ID. It is assumed that the available selector information is sufficient to figure out the relevant Security Association(s). o AH-transport --> (IP1-AH-Transport-Data) - IPv4 -- works - IPv6 -- works o AH-tunnel --> (IP2-AH-IP1-Transport-Data) - IPv4 -- works - IPv6 -- works o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works c. Security gateways -- integrate IPsec into the IP stack NOTE: The IPsec module will have access to the following Kent, Atkinson [Page 51] Internet Draft Security Architecture for IP February 1998 selectors from the packet -- SRC address, DST address, TOS/Class, Next Protocol, and if there's a transport layer header --> SRC port and DST port. It won't have access to the User ID (only Hosts have access to User ID information.) It also won't have access to the transport layer information if there is an ESP header, or if it's not the first fragment of a fragmented message. It is assumed that the available selector information is sufficient to figure out the relevant Security Association(s). o AH-tunnel --> (IP2-AH-IP1-Transport-Data) - IPv4 -- works - IPv6 -- works o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works ********************************************************************** B.3 Path MTU Discovery As mentioned earlier, "ICMP PMTU" refers to an ICMP message used for Path MTU Discovery. The legend for the diagrams below in B.3.1 and B.3.3 (but not B.3.2) is: ==== = security association (AH or ESP, transport or tunnel) ---- = connectivity (or if so labelled, administrative boundary) .... = ICMP message (hereafter referred to as ICMP PMTU) for IPv4: - Type = 3 (Destination Unreachable) - Code = 4 (Fragmentation needed and DF set) - Next-Hop MTU in the low-order 16 bits of the second word of the ICMP header (labelled unused in RFC 792), with high-order 16 bits set to zero IPv6 (RFC 1885): - Type = 2 (Packet Too Big) - Code = 0 (Fragmentation needed and DF set) - Next-Hop MTU in the 32 bit MTU field of the ICMP6 Hx = host x Rx = router x SGx = security gateway x X* = X supports IPsec Kent, Atkinson [Page 52] Internet Draft Security Architecture for IP February 1998 B.3.1 Identifying the Originating Host(s) The amount of information returned with the ICMP message is limited and this affects what selectors are available to identify security associations, originating hosts, etc. for use in further propagating the PMTU information. In brief... An ICMP message must contain the following information from the "offending" packet: - IPv4 (RFC 792) -- IP header plus a minimum of 64 bits - IPv6 (RFC 1885) -- IP header plus a minimum of 576 bytes Accordingly, in the IPv4 context, an ICMP PMTU may identify only the first (outermost) security association. This is because the ICMP PMTU may contain only 64 bits of the "offending" packet beyond the IP header, which would capture only the first SPI from AH or ESP. In the IPv6 context, an ICMP PMTU will probably provide all the SPIs and the selectors in the IP header, but maybe not the SRC/DST ports (in the transport header) or the encapsulated (TCP, UDP, etc.) protocol. Moreover, if ESP is used, the transport ports and protocol selectors may be encrypted. Looking at the diagram below of a security gateway tunnel (as mentioned elsewhere, security gateways do not use transport mode)... H1 =================== H3 \ | | / H0 -- SG1* ---- R1 ---- SG2* ---- R2 -- H5 / ^ | \ H2 |........| H4 Suppose that the security policy for SG1 is to use a single SA to SG2 for all the traffic between hosts H0, H1, and H2 and hosts H3, H4, and H5. And suppose H0 sends a data packet to H5 which causes R1 to send an ICMP PMTU message to SG1. If the PMTU message has only the SPI, SG1 will be able to look up the SA and find the list of possible hosts (H0, H1, H2, wildcard); but SG1 will have no way to figure out that H0 sent the traffic that triggered the ICMP PMTU message. Kent, Atkinson [Page 53] Internet Draft Security Architecture for IP February 1998 original after IPsec ICMP packet processing packet -------- ----------- ------ IP-3 header (S = R1, D = SG1) ICMP header (includes PMTU) IP-2 header IP-2 header (S = SG1, D = SG2) ESP header minimum of 64 bits of ESP hdr (*) IP-1 header IP-1 header TCP header TCP header TCP data TCP data ESP trailer (*) The 64 bits will include enough of the ESP (or AH) header to include the SPI. - ESP -- SPI (32 bits), Seq number (32 bits) - AH -- Next header (8 bits), Payload Len (8 bits), Reserved (16 bits), SPI (32 bits) This limitation on the amount of information returned with an ICMP message creates a problem in identifying the originating hosts for the packet (so as to know where to further propagate the ICMP PMTU information). If the ICMP message contains only 64 bits of the IPsec header (minimum for IPv4), then the IPsec selectors (e.g., Source and Destination addresses, Next Protocol, Source and Destination ports, etc.) will have been lost. But the ICMP error message will still provide SG1 with the SPI, the PMTU information and the source and destination gateways for the relevant security association. The destination security gateway and SPI uniquely define a security association which in turn defines a set of possible originating hosts. At this point, SG1 could: a. send the PMTU information to all the possible originating hosts. This would not work well if the host list is a wild card or if many/most of the hosts weren't sending to SG1; but it might work if the SPI/destination/etc mapped to just one or a small number of hosts. b. store the PMTU with the SPI/etc and wait until the next packet(s) arrive from the originating host(s) for the relevant security association. If it/they are bigger than the PMTU, drop the packet(s), and compose ICMP PMTU message(s) with the new packet(s) and the updated PMTU, and send the originating host(s) the ICMP message(s) about the problem. This involves a delay in notifying the originating host(s), but avoids the problems of (a). Since only the latter approach is feasible in all instances, a security gateway MUST provide such support, as an option. However, Kent, Atkinson [Page 54] Internet Draft Security Architecture for IP February 1998 if the ICMP message contains more information from the original packet, e.g., the 576 byte minimum for IPv6, then there MAY be enough information to immediately determine to which host to propagate the ICMP/PMTU message and to provide that system with the 5 fields (source address, destination address, source port, destination port, and transport protocol) needed to determine where to store/update the PMTU. Under such circumstances, a security gateway MUST generate an ICMP PMTU message immediately upon receipt of an ICMP PMTU from further down the path. NOTE: The Next Protocol field MAY not be contained in the 576 bytes and the use of ESP encryption MAY hide the selector fields that have been encrypted. B.3.2 Calculation of PMTU The calculation of PMTU from an ICMP PMTU has to take into account the addition of any IPsec header by H1 -- AH and/or ESP transport, or ESP or AH tunnel. Within a single host, multiple applications may share an SPI and nesting of security associations may occur. (See Section 4.5 Basic Combinations of Security Associations for description of the combinations that MUST be supported). The diagram below illustrates an example of security associations between a pair of hosts (as viewed from the perspective of one of the hosts.) (ESPx or AHx = transport mode) Socket 1 -------------------------| | Socket 2 (ESPx/SPI-A) ---------- AHx (SPI-B) -- Internet In order to figure out the PMTU for each socket that maps to SPI-B, it will be necessary to have backpointers from SPI-B to each of the 2 paths that lead to it -- Socket 1 and Socket 2/SPI-A. B.3.3 Granularity of Maintaining PMTU Data In hosts, the granularity with which PMTU ICMP processing can be done differs depending on the implementation situation. Looking at a host, there are three situations that are of interest with respect to PMTU issues: a. Integration of IPsec into the native IP implementation b. Bump-in-the-stack implementations, where IPsec is implemented "underneath" an existing implementation of a TCP/IP protocol stack, between the native IP and the local network drivers c. No IPsec implementation -- This case is included because it is relevant in cases where a security gateway is sending PMTU information back to a host. Only in case (a) can the PMTU data be maintained at the same Kent, Atkinson [Page 55] Internet Draft Security Architecture for IP February 1998 granularity as communication associations. In the other cases, the IP layer will maintain PMTU data at the granularity of Source and Destination IP addresses (and optionally TOS/Class), as described in RFC 1191. This is an important difference, because more than one communication association may map to the same source and destination IP addresses, and each communication association may have a different amount of IPsec header overhead (e.g., due to use of different transforms or different algorithms). The examples below illustrate this. In cases (a) and (b)... Suppose you have the following situation. H1 is sending to H2 and the packet to be sent from R1 to R2 exceeds the PMTU of the network hop between them. ================================== | | H1* --- R1 ----- R2 ---- R3 ---- H2* ^ | |.......| If R1 is configured to not fragment subscriber traffic, then R1 sends an ICMP PMTU message with the appropriate PMTU to H1. H1's processing would vary with the nature of the implementation. In case (a) (native IP), the security services are bound to sockets or the equivalent. Here the IP/IPsec implementation in H1 can store/update the PMTU for the associated socket. In case (b), the IP layer in H1 can store/update the PMTU but only at the granularity of Source and Destination addresses and possibly TOS/Class, as noted above. So the result may be sub-optimal, since the PMTU for a given SRC/DST/TOS/Class will be the subtraction of the largest amount of IPsec header used for any communication association between a given source and destination. In case (c), there has to be a security gateway to have any IPsec processing. So suppose you have the following situation. H1 is sending to H2 and the packet to be sent from SG1 to R exceeds the PMTU of the network hop between them. ================ | | H1 ---- SG1* --- R --- SG2* ---- H2 ^ | |.......| As described above for case (b), the IP layer in H1 can store/update the PMTU but only at the granularity of Source and Destination addresses, and possibly TOS/Class. So the result may be sub-optimal, since the PMTU for a given SRC/DST/TOS/Class will be the subtraction Kent, Atkinson [Page 56] Internet Draft Security Architecture for IP February 1998 of the largest amount of IPsec header used for any communication association between a given source and destination. B.3.4 Per Socket Maintenance of PMTU Data Implementation of the calculation of PMTU (Section B.2.2) and support for PMTUs at the granularity of individual "communication associations" (Section B.2.3) is a local matter. However, a socket- based implementation of IPsec in a host SHOULD maintain the information on a per socket basis. Bump in the stack systems MUST pass an ICMP PMTU to the host IP implementation, after adjusting it for any IPsec header overhead added by these systems. The determination of the overhead SHOULD be determined by analysis of the SPI and any other selector information present in a returned ICMP PMTU message. B.3.5 Delivery of PMTU Data to the Transport Layer The host mechanism for getting the updated PMTU to the transport layer is unchanged, as specified in RFC 1191 (Path MTU Discovery). B.3.6 Aging of PMTU Data This topic is covered in Section 6.1.2.4. Kent, Atkinson [Page 57] Internet Draft Security Architecture for IP February 1998 Appendix C -- Sequence Space Window Code Example This appendix contains a routine that implements a bitmask check for a 32 packet window. It was provided by James Hughes (jim_hughes@stortek.com) and Harry Varnis (hgv@anubis.network.com) and is intended as an implementation example. Note that this code both checks for a replay and updates the window. Thus the algorithm, as shown, should only be called AFTER the packet has been authenticated. Implementers might wish to consider splitting the code to do the check for replays before computing the ICV. If the packet is not a replay, the code would then compute the ICV, (discard any bad packets), and if the packet is OK, update the window. #include #include typedef unsigned long u_long; enum { ReplayWindowSize = 32 }; u_long bitmap = 0; /* session state - must be 32 bits */ u_long lastSeq = 0; /* session state */ /* Returns 0 if packet disallowed, 1 if packet permitted */ int ChkReplayWindow(u_long seq); int ChkReplayWindow(u_long seq) { u_long diff; if (seq == 0) return 0; /* first == 0 or wrapped */ if (seq > lastSeq) { /* new larger sequence number */ diff = seq - lastSeq; if (diff < ReplayWindowSize) { /* In window */ bitmap <<= diff; bitmap |= 1; /* set bit for this packet */ } else bitmap = 1; /* This packet has a "way larger" */ lastSeq = seq; return 1; /* larger is good */ } diff = lastSeq - seq; if (diff >= ReplayWindowSize) return 0; /* too old or wrapped */ if (bitmap & (1 << diff)) return 0; /* this packet already seen */ bitmap |= (1 << diff); /* mark as seen */ return 1; /* out of order but good */ } char string_buffer[512]; Kent, Atkinson [Page 58] Internet Draft Security Architecture for IP February 1998 #define STRING_BUFFER_SIZE sizeof(string_buffer) int main() { int result; u_long last, current, bits; printf("Input initial state (bits in hex, last msgnum):\n"); if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) exit(0); sscanf(string_buffer, "%lx %lu", &bits, &last); if (last != 0) bits |= 1; bitmap = bits; lastSeq = last; printf("bits:%08lx last:%lu\n", bitmap, lastSeq); printf("Input value to test (current):\n"); while (1) { if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) break; sscanf(string_buffer, "%lu", ¤t); result = ChkReplayWindow(current); printf("%-3s", result ? "OK" : "BAD"); printf(" bits:%08lx last:%lu\n", bitmap, lastSeq); } return 0; } Kent, Atkinson [Page 59] Internet Draft Security Architecture for IP February 1998 Appendix D -- Categorization of ICMP messages The tables below characterize ICMP messages as being either host generated, router generated, both, unassigned/unknown. The first set are IPv4. The second set are IPv6. IPv4 Type Name/Codes Reference ========================================================================= HOST GENERATED: 3 Destination Unreachable 2 Protocol Unreachable [RFC792] 3 Port Unreachable [RFC792] 8 Source Host Isolated [RFC792] 14 Host Precedence Violation [RFC1812] 10 Router Selection [RFC1256] Type Name/Codes Reference ========================================================================= ROUTER GENERATED: 3 Destination Unreachable 0 Net Unreachable [RFC792] 4 Fragmentation Needed, Don't Fragment was Set [RFC792] 5 Source Route Failed [RFC792] 6 Destination Network Unknown [RFC792] 7 Destination Host Unknown [RFC792] 9 Comm. w/Dest. Net. is Administratively Prohibited [RFC792] 11 Destination Network Unreachable for Type of Service [RFC792] 5 Redirect 0 Redirect Datagram for the Network (or subnet) [RFC792] 2 Redirect Datagram for the Type of Service & Network [RFC792] 9 Router Advertisement [RFC1256] 18 Address Mask Reply [RFC950] Kent, Atkinson [Page 60] Internet Draft Security Architecture for IP February 1998 IPv4 Type Name/Codes Reference ========================================================================= BOTH ROUTER AND HOST GENERATED: 0 Echo Reply [RFC792] 3 Destination Unreachable 1 Host Unreachable [RFC792] 10 Comm. w/Dest. Host is Administratively Prohibited [RFC792] 12 Destination Host Unreachable for Type of Service [RFC792] 13 Communication Administratively Prohibited [RFC1812] 15 Precedence cutoff in effect [RFC1812] 4 Source Quench [RFC792] 5 Redirect 1 Redirect Datagram for the Host [RFC792] 3 Redirect Datagram for the Type of Service and Host [RFC792] 6 Alternate Host Address [JBP] 8 Echo [RFC792] 11 Time Exceeded [RFC792] 12 Parameter Problem [RFC792,RFC1108] 13 Timestamp [RFC792] 14 Timestamp Reply [RFC792] 15 Information Request [RFC792] 16 Information Reply [RFC792] 17 Address Mask Request [RFC950] 30 Traceroute [RFC1393] 31 Datagram Conversion Error [RFC1475] 32 Mobile Host Redirect [Johnson] 39 SKIP [Markson] 40 Photuris [Simpson] Type Name/Codes Reference ========================================================================= UNASSIGNED TYPE OR UNKNOWN GENERATOR: 1 Unassigned [JBP] 2 Unassigned [JBP] 7 Unassigned [JBP] 19 Reserved (for Security) [Solo] 20-29 Reserved (for Robustness Experiment) [ZSu] 33 IPv6 Where-Are-You [Simpson] 34 IPv6 I-Am-Here [Simpson] 35 Mobile Registration Request [Simpson] 36 Mobile Registration Reply [Simpson] 37 Domain Name Request [Simpson] 38 Domain Name Reply [Simpson] 41-255 Reserved [JBP] Kent, Atkinson [Page 61] Internet Draft Security Architecture for IP February 1998 IPv6 Type Name/Codes Reference ========================================================================= HOST GENERATED: 1 Destination Unreachable [RFC 1885] 4 Port Unreachable Type Name/Codes Reference ========================================================================= ROUTER GENERATED: 1 Destination Unreachable [RFC1885] 0 No Route to Destination 1 Comm. w/Destination is Administratively Prohibited 2 Not a Neighbor 3 Address Unreachable 2 Packet Too Big [RFC1885] 0 3 Time Exceeded [RFC1885] 0 Hop Limit Exceeded in Transit 1 Fragment reassembly time exceeded Type Name/Codes Reference ========================================================================= BOTH ROUTER AND HOST GENERATED: 4 Parameter Problem [RFC1885] 0 Erroneous Header Field Encountered 1 Unrecognized Next Header Type Encountered 2 Unrecognized IPv6 Option Encountered Kent, Atkinson [Page 62] Internet Draft Security Architecture for IP February 1998 References [BL73] Bell, D.E. & LaPadula, L.J., "Secure Computer Systems: Mathematical Foundations and Model", Technical Report M74- 244, The MITRE Corporation, Bedford, MA, May 1973. [Bra97] S. Bradner, "Key words for use in RFCs to Indicate Requirement Level," RFC-2119, March 1997. [DoD85] US National Computer Security Center, "Department of Defense Trusted Computer System Evaluation Criteria", DoD 5200.28-STD, US Department of Defense, Ft. Meade, MD., December 1985. [DoD87] US National Computer Security Center, "Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria", NCSC-TG-005, Version 1, US Department of Defense, Ft. Meade, MD., 31 July 1987. [HA94] N. Haller & R. Atkinson, "On Internet Authentication", RFC-1704, DDN Network Information Center, October 1994. [HC98] D. Harkins & D. Carrel, "The Internet Key Exchange (IKE)", Internet Draft, February 1998. [HM97] H. Harney, C. Muckenhirn, "Group Key Management Protocol (GKMP) Architecture", RFC 2094, July 1997. [ISO] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, International Standards Organisation, Geneva, Switzerland, 29 November 1992. [IB93] John Ioannidis and Matt Blaze, "Architecture and Implementation of Network-layer Security Under Unix", Proceedings of USENIX Security Symposium, Santa Clara, CA, October 1993. [IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network- Layer Security for IP", presentation at the Spring 1993 IETF Meeting, Columbus, Ohio [KA98a] Steve Kent, Randall Atkinson, "IP Authentication Header", Internet Draft, February 1998. [KA98b] Steve Kent, Randall Atkinson, "IP Encapsulating Security Payload (ESP)", Internet Draft, February 1998. [Ken91] Steve Kent, "US DoD Security Options for the Internet Kent, Atkinson [Page 63] Internet Draft Security Architecture for IP February 1998 Protocol", RFC-1108, DDN Network Information Center, November 1991. [MSST97] D Maughan, M. Schertler, M. Schneider, & J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", Internet Draft, July 1997. [Orm97] H. K. Orman, "The OAKLEY Key Determination Protocol", Internet Draft, July 1997. [Pip98] D. Piper, "The Internet IP Security Domain of Interpretation for ISAKMP", Internet Draft, February 1998. [Sch94] Bruce Schneier, Applied Cryptography, Section 8.6, John Wiley & Sons, New York, NY, 1994. [SDNS] SDNS Secure Data Network System, Security Protocol 3, SP3, Document SDN.301, Revision 1.5, 15 May 1989, published in NIST Publication NIST-IR-90-4250, February 1990. [TDG97] R. Thayer, N. Doraswamy, R. Glenn, "IP Security Document Roadmap", Internet Draft, December 1997. [VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High- level Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983. Disclaimer The views and specification expressed in this document 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 design. Kent, Atkinson [Page 64] Internet Draft Security Architecture for IP February 1998 Author Information Stephen Kent BBN Corporation 70 Fawcett Street Cambridge, MA 02140 USA E-mail: kent@bbn.com Telephone: +1 (617) 873-3988 Randall Atkinson @Home Network 425 Broadway Redwood City, CA 94063 USA E-mail: rja@corp.home.net Telephone: +1 (415) 569-5000 Copyright (C) The Internet Society (February 1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Kent, Atkinson [Page 65] From owner-ipsec Fri Feb 20 08:38:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA17607 for ipsec-outgoing; Fri, 20 Feb 1998 08:35:56 -0500 (EST) Message-ID: <34ED8841.DC40CE0B@ire-ma.com> Date: Fri, 20 Feb 1998 08:42:25 -0500 From: Bronislav Kavsan X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: "ipsec@tis.com" Subject: Stale SAs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk I couldn't find anyhting of the "MUST" nature in the IKE protocol (and Dan Harkins confirmed), which could mandate remote IPsec host/SGW to assist my host to discover stale SA. This situation may arise when the remote host/SGW reboots and starts a new IPsec life, while my host has an SA from the previous engagement with this host/SGW. Another complicating factor in this scenario could be the fact that my host is a road warrier and the remote host/SGW has non-IP Address-based entry for me or my road warrier in his policy - therefore it cannot use the IP address to figure out from whom these AH/ESP packets are coming from. What are the alternatives for solving this situation? Should we push the problem to the IPsecond and keep our SAs stale till then :), or to have some kind of "gentlemen's" agreement to send an nformational message in this case (though their arrival is not guranteed), or initiate new IKE proposal to the guy hopelessly trying to send these IPsec packets, or.......... Any ideas on how to solve this problem locally, without assistance from the other side? (SA timeouts? Inactivity timeouts?) Thank you, Slava Kavsan IRE From owner-ipsec Fri Feb 20 09:23:24 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA17938 for ipsec-outgoing; Fri, 20 Feb 1998 09:23:05 -0500 (EST) Date: Fri, 20 Feb 1998 09:33:01 -0500 (EST) From: Dave Mason Message-Id: <199802201433.JAA21233@rubicon.rv.tis.com> To: tytso@MIT.EDU Cc: ipsec@tis.com Subject: Re: IPSEC WORKING GROUP LAST CALL Sender: owner-ipsec@ex.tis.com Precedence: bulk > As far as the other drafts are concerned, I'd like to see 3DES get > added to the pile but given the size of the pile already I wouldn't have > a problem with waiting on the rest. > >Noted. Anybody else who wants to express an opinion on this, now's the >time to speak up. I would also like to see the 3DES cipher document added to the last call list. -dmason From owner-ipsec Fri Feb 20 09:24:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA17951 for ipsec-outgoing; Fri, 20 Feb 1998 09:24:05 -0500 (EST) Message-ID: From: Greg Carter To: "'Theodore Y. Ts'o'" Cc: "'ipsec@tis.com'" Subject: Last call on Cipher Drafts... Date: Fri, 20 Feb 1998 09:27:18 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I thought that ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-cbc-01.txt was supposed to clear up the issue around the explosion of ESP Cipher drafts. In fact I thought most of the individual drafts were supposed to be nullified by this draft. Since this one document was prepared with the cooperation of most of those draft authors. All the info (inc 3DES) is in one draft. >From the document: This document obsoletes the following documents: draft-ietf-ipsec-ciph-cast-128cbc-00.txt, R. Pereira, G. Carter draft-ietf-ipsec-ciph-rc5-cbc-00.txt, R. Pereira, R. Baldwin draft-ietf-ipsec-ciph-3des-expiv-00.txt, R. Pereira, R. Thayer draft-ietf-ipsec-ciph-idea-cbc-00.txt, R. Adams draft-ietf-ipsec-ciph-blowfish-cbc-00.txt, R. Adams I would like to see this one go to last call with the DES. Bye. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com >---------- >From: Theodore Y. Ts'o[SMTP:tytso@MIT.EDU] >Sent: Friday, February 20, 1998 12:43 AM >To: Daniel Harkins >Cc: Theodore Y. Ts'o; ipsec@tis.com >Subject: Re: IPSEC WORKING GROUP LAST CALL > > Date: Thu, 19 Feb 1998 21:14:05 -0800 > From: Daniel Harkins > > A 2key 3DES is 112bit while a 3key 3DES is 168 (although I never did > like those numbers since 3 DES keys are 192 bits not 168 bits). > >Err, right. I should know better than to send e-mail out after midnight >without first checking my multiplcation first. Sorry about that.... >(The only lame excuse I can give is that my brain was fried after a full >day of dealing with ipsec/ca-talk issues at Needham today...) > > And draft-ietf-ipsec-ciph-3des-00.txt is definately a 3key 3DES. So I > think Ramesh is talking about a 2key 3DES. But there is no draft > which defines such a transform so the request to add a magic number > for it is premature. > >Agreed. > > As far as the other drafts are concerned, I'd like to see 3DES get > added to the pile but given the size of the pile already I wouldn't have > a problem with waiting on the rest. > >Noted. Anybody else who wants to express an opinion on this, now's the >time to speak up. > > - Ted > From owner-ipsec Fri Feb 20 09:40:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA18236 for ipsec-outgoing; Fri, 20 Feb 1998 09:38:09 -0500 (EST) Message-Id: <199802201450.JAA26463@jekyll.piermont.com> To: "Theodore Y. Ts'o" cc: ipsec@tis.com Subject: Re: IPSEC WORKING GROUP LAST CALL In-reply-to: Your message of "Thu, 19 Feb 1998 23:42:47 EST." <199802200442.XAA14827@dcl.MIT.EDU> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 20 Feb 1998 09:50:19 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk "Theodore Y. Ts'o" writes: > The triple DES document wasn't one of the documents that I put into IETF > last call, as one of the "core group" of documents. Do people believe > that should get pushed out to the IESG at the same time? Yes. In the years since the original IPSec work was done, DES has become far too weak for words. To my clients with financial applications, the few hundred K a DES cracker would cost is probably a reasonable expense for an attacker to undertake. Even if we are not going to mandate 3DES we should at least make sure that a solid standard for how to do it is available at the same time as the other specs. > There is a related question to the other cipher suites for which DOI > document contains references: ARCFOUR, Blowfish, and RC5. Since RFC's > are not allowed to refer to internet-drafts, what do we want to do with > them in the DOI spec? "ARCFOUR", a.k.a. RC4 (the name RC4 is trademarked), is described in detail in Schneier. We could always reference that. Ditto for Blowfish. Perry From owner-ipsec Fri Feb 20 09:41:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA18275 for ipsec-outgoing; Fri, 20 Feb 1998 09:41:03 -0500 (EST) Message-Id: <199802201411.JAA07399@ensun101.UD.Engr> Subject: CFP: Arch. Prot. & QoS for Future Internet To: ipsec@ans.net Date: Fri, 20 Feb 1998 09:11:13 -0500 (EST) Reply-To: atiq@engr.udayton.edu (Mohammed Atiquzzaman) From: atiq@engr.udayton.edu (Mohammed Atiquzzaman) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk CALL FOR PAPERS European Transactions on Telecommunications (ETT) Special Issue on ARCHITECTURES, PROTOCOLS AND QUALITY OF SERVICE FOR THE INTERNET OF THE FUTURE Guest Editors: Matteo D'Ambrosio and Mohammed Atiquzzaman Recent advances in switching and transmission technologies allow the implementation of very high speed networks that are changing the face of the Internet. In the next Telecommunication Age it will be possible to support new multimedia applications in a global environment and design new services on flexible platforms without upgrading the physical infrastrucure. In order to reach these goals many researchers are working on defining the new Network Architecture, which will be capable of offering transport and computation services to communication applications with stringent Quality of Service (QoS) requirements. New protocols and node implementations have to be envisioned with this objective in mind. The ETT Journal announces a forthcoming issue on "Architectures, Protocols and Quality of Service For The Internet Of The Future", that will be focused on (but not limited to) the following topics: - New node architectures for Switching and Routing at Gigabit Speeds - Multi-Protocol Label Switching (MPLS): design principles, network architecture and performance - Internetworking with ATM and High Speed Networks to offer QoS guarantees - Multimedia Services running on Heterogeneous Networks - Network and Transport Protocols in the Integrated Services Internet - QoS provision, multicast support and policy capabilities in Routing and Signalling Protocols - Differentiated Services Architectures - Open Control Architectures and Active Networks Prospective authors should email their manuscripts (PostScript format) or send five (5) hard copies to one of the Guest Editors listed below. The following deadlines will apply: - Submission of manuscripts June 30, 1998 - Notification of acceptance November 15, 1998 - Submission of final manuscript December 15, 1998 - Publication Date March-April, 1999 Guest Editors Matteo D'Ambrosio Mohammed Atiquzzaman Networking Department Department of Electrical & CSELT Computer Engineering v. Reiss Romoli 274 University of Dayton 10148 Torino Dayton, Ohio 45469-0226 Italy USA phone: +39 11 2285006 phone: +1 937 229-3183 fax: +39 11 2285069 fax: +1 937 229-4529 e-mail: matteo.dambrosio@cselt.it e-mail: atiq@engr.udayton.edu More information about the special issue can be obtained from http://www.engr.udayton.edu/faculty/matiquzz/ett-cfp.html Note: If a paper is not accepted for the special issue, it will be considered for publication in one of the regular issues of ETT. From owner-ipsec Fri Feb 20 09:57:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA18376 for ipsec-outgoing; Fri, 20 Feb 1998 09:57:02 -0500 (EST) Message-Id: <199802201509.KAA25900@jekyll.piermont.com> To: "adams@cisco.com" cc: "'Theodore Y. Ts'o'" , Daniel Harkins , "ipsec@tis.com" Subject: Re: IPSEC WORKING GROUP LAST CALL In-reply-to: Your message of "Thu, 19 Feb 1998 22:26:17 PST." <01BD3D85.6B31C350.adams@cisco.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 20 Feb 1998 10:09:10 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Rob Adams writes: > We need a 40 bit DES description which defines how to weaken the key. > And we need a transform number. If people want to define time-wasting latency-adding protocols that add no security, they shouldn't do it under IETF security area auspices. A 40 bit key is literally worthless. It provides no security even against anyone with any intelligence, it provides the illusion of security without adding any (which is often worse than no security at all), and it reduces your performance by eating CPU for no purpose. I strongly feel the IETF should do *nothing* to encourage the use of 40 bit keys. If the U.S. government wants to pull a horrible hoax on its citizens and pretend they have any legitimate purpose whatsoever, they should do it without us helping. Perry From owner-ipsec Fri Feb 20 11:24:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA19165 for ipsec-outgoing; Fri, 20 Feb 1998 11:23:10 -0500 (EST) Message-Id: <199802201633.LAA26681@relay.hq.tis.com> To: "adams@cisco.com" cc: "'Theodore Y. Ts'o'" , Daniel Harkins , "ipsec@tis.com" Subject: Re: IPSEC WORKING GROUP LAST CALL In-reply-to: Your message of "Thu, 19 Feb 1998 22:26:17 PST." <01BD3D85.6B31C350.adams@cisco.com> Date: Fri, 20 Feb 1998 08:35:33 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk RE: 40-bit DES There's an interesting update on the $1,000,000 DES machine, first described (in public) in 1993, in the latest issue of "CryptoBytes" (www.rsa.com/rsalabs/pubs/cryptobytes.html). It's written by the author of the original paper, Micheal J. Wiener. Cutting to the chase: Today's version of the $1 million machine could find a DES key in, on average, in 35 minutes (one-sixth of 3.5 hours). This time scales linearly with the amount of money spent as shown in the following table. Key Search Machine Cost Exepected Search Time ----------------------- --------------------- $10,000 2.5 days $100,000 6 hours $1,000,000 35 minutes $10,000,000 3.5 minutes For good reason, the IETF decided not to standardize weakened encryption technology. I personally wouldn't use 56-bit DES for anything I cared about. In my opinion, the IETF has done the right thing. 40-bit DES is right out. Derrell (Now, where's my Kevlar tie-dye?) From owner-ipsec Fri Feb 20 12:45:09 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA19906 for ipsec-outgoing; Fri, 20 Feb 1998 12:43:10 -0500 (EST) Message-Id: <199802201757.MAA13024@relay.rv.tis.com> To: Greg Carter cc: "'Theodore Y. Ts'o'" , "'ipsec@tis.com'" Subject: Re: Last call on Cipher Drafts... In-reply-to: Your message of "Fri, 20 Feb 1998 09:27:18 EST." Date: Fri, 20 Feb 1998 09:56:05 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk >ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-cbc-01.txt was Ah, the cob-webs clear temporarily. I attempted to clean up the document references in the recent DOI and must admit that I gave up. I figured someone would remember which cipher document was The One True ESP-CBC Referece (tm). Greg Carter appears to win the cookie. (That's an ISAKMP cookie, of course...) I'll fix this in an update to the DOI that I'll release after the ISAKMP draft come out. (Notice how he adroitly refocuses all attention on Doug Maughan.) The problem with the DOI pointing to ID's must be corrected anyway, per Ted's recent note. I'm for just pulling the references, as needed. In addition to the list that Ted had, the pointer to the Roadmap document will also have to be removed. (With The One True ESP-CBC Reference (tm), I don't think that's a big deal.) Derrell, off for yet more coffee From owner-ipsec Fri Feb 20 13:19:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA20225 for ipsec-outgoing; Fri, 20 Feb 1998 13:19:15 -0500 (EST) Message-Id: <3.0.5.32.19980220120116.00958220@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 20 Feb 1998 12:01:16 -0500 To: "Theodore Y. Ts'o" , wdm@epoch.ncsc.mil From: Robert Moskowitz Subject: Re: new draft-ietf-ipsec-isakmp? Cc: ipsec@tis.com, wdm@epoch.ncsc.mil In-Reply-To: <199802200419.XAA14803@dcl.MIT.EDU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 11:19 PM 2/19/98 -0500, Theodore Y. Ts'o wrote: > >OK. Both Bob and I had been under the impression that another draft >would not be forthcoming, and that the current one was adequate. >Clearly, there is consensus to the contrary. My notes from the reading dinner were broken in this respect. Also sorry. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Fri Feb 20 13:19:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA20224 for ipsec-outgoing; Fri, 20 Feb 1998 13:19:12 -0500 (EST) Message-Id: <3.0.5.32.19980220120445.009c5ba0@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 20 Feb 1998 12:04:45 -0500 To: "adams@cisco.com" , "'Theodore Y. Ts'o'" , Daniel Harkins From: Robert Moskowitz Subject: RE: IPSEC WORKING GROUP LAST CALL Cc: "ipsec@tis.com" In-Reply-To: <01BD3D85.6B31C350.adams@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:26 PM 2/19/98 -0800, Rob Adams wrote: >We need a 40 bit DES description which defines how to weaken the key. >And we need a transform number. > There was extensive talk on this, and I cannot find my notes on it :( Perhaps it is in the archives? There was one position that the IETF does not specify weakning DES to 40 bits (then why ARCFour?, sigh). But the way to do it is so well know. The issue was how to let the parties decide/know that the DES was really DES40. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Fri Feb 20 13:21:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA20270 for ipsec-outgoing; Fri, 20 Feb 1998 13:21:12 -0500 (EST) Message-ID: <34EDC95D.D8CFC677@nt.com> Date: Fri, 20 Feb 1998 13:20:13 -0500 From: "Marcus Leech" Organization: Nortel Technology, Messaging and Security Infrastructure X-Mailer: Mozilla 4.03 [en] (X11; I; HP-UX A.09.05 9000/712) MIME-Version: 1.0 To: perry@piermont.com, ipsec@tis.com Subject: Re: IPSEC WORKING GROUP LAST CALL References: <199802201450.JAA26463@jekyll.piermont.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Perry E. Metzger wrote: > Yes. In the years since the original IPSec work was done, DES has > become far too weak for words. To my clients with financial > applications, the few hundred K a DES cracker would cost is probably a > reasonable expense for an attacker to undertake. Even if we are not > going to mandate 3DES we should at least make sure that a solid > standard for how to do it is available at the same time as the other specs. I agree with Perry, while mandating 3DES may be, politically, a mistake, having a standards-track document describing the 3DES transform would be a good thing(tm). -- ---------------------------------------------------------------------- Marcus Leech Mail: Dept 8M86, MS 012, FITZ Systems Security Architect Phone: (ESN) 393-9145 +1 613 763 9145 Messaging and Security Infrastructure Fax: (ESN) 395-1407 +1 613 765 1407 Nortel Technology mleech@nortel.ca -----------------Expressed opinions are my own, not my employer's------ From owner-ipsec Fri Feb 20 13:52:02 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA20460 for ipsec-outgoing; Fri, 20 Feb 1998 13:50:11 -0500 (EST) Date: Fri, 20 Feb 1998 11:02:01 -0800 Message-Id: <199802201902.LAA06253@spire.inside.sealabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Chris Boscolo To: ipsec@tis.com Subject: IPSEC Arch, ports, and tunnel mode SAs X-Mailer: VM 6.22 under 19.15 XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk I have a question regarding the following change to the IPSEC Arch and a tunnel mode SA(s) set up between two SG's. Can I set up a tunnel mode SA between two SGs where one of the (outbound) selectors is a protocol port? If so, what do I do when I receive an IP fragment on my "non-IPSEC" side? I can't determine which tunnel to send through since I may not have the port info. Or, is the decision to forward fragments dependent on what I have in the ports field of the selector. That is if the port fields are set to "don't care", then I can send fragments. But, if they are set to specific values, then I must drop fragments. It seems like a bad idea to me to allow ports as a selector if it means that we can't send ip fragments through the tunnels. (you might extend this statement and say it is a bad idea to allow ports as a selector for tunnel mode SAs.) - chrisb This didn't clear it up for me: > * Changed the paragraph on "Source and Destination (e.g., > TCP/UDP) Ports" from: > [REQUIRED for all implementations] > to: > [MAY be supported] > > * Added text at the end of the paragraph on "Source and > Destination (e.g., TCP/UDP) Ports" > > The following table summarizes the relationship between the > "Next Header" value in the packet and SPD and the derived Port > Selector value for the SPD and SAD. > > Next Hdr Next Hdr Derived Port Selector Field > in Packet in SPD Value in SPD and SAD > -------- -------- --------------------------- > ESP ESP or ANY ANY (i.e., don't look at it) > -don't care- ANY ANY (i.e., don't look at it) > specific value specific value NOT ANY (i.e., drop packet) > fragment > specific value specific value actual port selector field > not fragment > > If the packet has been fragmented, then the port information > may not be available in the current fragment. If so, discard > the fragment. An ICMP PMTU should be sent for the first > fragment, which will have the port information. -- Chris Boscolo chris.boscolo@WatchGuard.com WatchGuard Technologies (206) 521-8348 From owner-ipsec Fri Feb 20 14:16:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA20702 for ipsec-outgoing; Fri, 20 Feb 1998 14:16:10 -0500 (EST) Message-Id: <199802201928.LAA02807@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: "Theodore Y. Ts'o" Cc: Robert Moskowitz , adams@cisco.com, perry@piermont.com, ipsec@tis.com Subject: Re: IPSEC WORKING GROUP LAST CALL Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 20 Feb 1998 11:28:43 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk As Bob said, how to weaken the key is well known but I figured a CBC-MAC was well known and that apparently is not the case. We need documents describing things and there is no document describing "40 bit DES" (maybe there's some weird gov't document that I'm not aware of). Since DES does not use a variable length key-- "40 bit DES" uses and 8 byte key the same as "56 bit DES"-- it is not appropriate to negotiate DES with the key length attribute set to 40. So I think "40 bit DES" is out. Perhaps a compromise between the two camps is to add another document to the pile that will allow people who happen to live in a country with export regulations to export an IPSec implementation. That would be some document that describes a variable length cipher, which means RC4 or Blowfish. Personally, I'd prefer Blowfish. How does this sound? We (the IPSec WG) are not tacitly endorsing this insane policy our gov't (and Israel's gov't and Russia's gov't and France's gov't and .... ) has, yet we're giving people whose livelihood depends on being able to sell product to continue to be gainfully employed and producing something useful and secure (in addition to the weak exportable product). Dan. From owner-ipsec Fri Feb 20 14:50:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA21080 for ipsec-outgoing; Fri, 20 Feb 1998 14:50:13 -0500 (EST) Message-Id: <3.0.3.32.19980220195714.008fcbc0@127.0.0.1> X-Sender: smb@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 20 Feb 1998 19:57:14 +0000 To: "adams@cisco.com" From: "Steven M. Bellovin" Subject: RE: IPSEC WORKING GROUP LAST CALL Cc: "'Theodore Y. Ts'o'" , Daniel Harkins , "ipsec@tis.com" In-Reply-To: <01BD3D85.6B31C350.adams@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:26 PM 2/19/98 -0800, Rob Adams wrote: >We need a 40 bit DES description which defines how to weaken the key. >And we need a transform number. Right. Bear in mind that one very good way to weaken the key -- IBM's Commercial Data Masking Facility (they were too honest to call it encryption) is patented, which means that we'd have to get an appropriate statement from IBM before we could bless it. Not that I really want to... From owner-ipsec Fri Feb 20 14:51:32 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA21081 for ipsec-outgoing; Fri, 20 Feb 1998 14:50:13 -0500 (EST) Message-Id: <3.0.3.32.19980220195812.0092d100@127.0.0.1> X-Sender: smb@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 20 Feb 1998 19:58:12 +0000 To: perry@piermont.com From: "Steven M. Bellovin" Subject: Re: IPSEC WORKING GROUP LAST CALL Cc: "Theodore Y. Ts'o" , ipsec@tis.com In-Reply-To: <199802201450.JAA26463@jekyll.piermont.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk > >"ARCFOUR", a.k.a. RC4 (the name RC4 is trademarked), is described in >detail in Schneier. We could always reference that. Ditto for Blowfish. Correct me if I'm wrong, but I don't think we have a framework document for stream ciphers for the new structure. We'd need that first. From owner-ipsec Fri Feb 20 15:14:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA21393 for ipsec-outgoing; Fri, 20 Feb 1998 15:14:13 -0500 (EST) Message-Id: <199802202027.PAA03149@jekyll.piermont.com> To: ipsec@tis.com Subject: Re: IPSEC WORKING GROUP LAST CALL In-reply-to: Your message of "Fri, 20 Feb 1998 11:28:43 PST." <199802201928.LAA02807@dharkins-ss20.cisco.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 20 Feb 1998 15:26:59 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Someone writes: > As Bob said, how to weaken the key is well known but I figured a CBC-MAC > was well known and that apparently is not the case. We need documents > describing things and there is no document describing "40 bit DES" I removed "someone"'s name because I don't want them to think the following targets them specifically. It is directed not at particular people but at the notion of ciphers with inadequate key lengths being standardized, even in the "sheep's clothing" of variable length ciphers that permit inadequate lengths. I don't understand why we wish to specify this at all. Even single DES isn't secure any more. IBM, to their credit, doesn't call their 40 bit DES based algorithm encryption -- they call it "commercial data masking". You argue "hey, some of us have to make a living". Well, do it in a less damaging way -- sell CD-ROM encyclopedias door to door or something. If you insist on selling your customers junk -- and 40 bit encryption is *junk* -- please do not ask the rest of us to endorse your mechanism with the imprimateur of the IETF. The last thing I want on earth is to see such a box sold with a brochure advertising its compliance with RFC YYYY. Find a better way of marketing the antifreeze you propose selling as booze to the third world natives. You don't need an RFC number to do that. Oh, and if any vendor does go through the exercise of selling such a thing, I suspect that software will be widely distributed on the net to help even unskilled teenage crackers break the "encryption"[sic] without having to know what they are doing. I suspect that because if no one else does I'll write it and distribute it myself. A false sense of security is worse than no security. The 40 bit "encryption" fraud must end. I've flamed on enough here already, and won't go any further with it right now. I believe people can tell how strongly I feel about this. Perry From owner-ipsec Fri Feb 20 15:21:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA21711 for ipsec-outgoing; Fri, 20 Feb 1998 15:21:16 -0500 (EST) Message-Id: <199802202033.PAA14586@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-auth-hmac-sha196-03.txt Date: Fri, 20 Feb 1998 15:33:51 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Use of HMAC-SHA-1-96 within ESP and AH Author(s) : C. Madson, R. Glenn Filename : draft-ietf-ipsec-auth-hmac-sha196-03.txt Pages : 6 Date : 18-Feb-98 This draft describes the use of the HMAC algorithm [RFC-2104] in conjunction with the SHA-1 algorithm [FIPS-180-1] as an authentication mechanism within the revised IPSEC Encapsulating Security Payload [ESP] and the revised IPSEC Authentication Header [AH]. HMAC with SHA-1 provides data origin authentication and integrity protection. Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a]. 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-auth-hmac-sha196-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-sha196-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-auth-hmac-sha196-03.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: <19980218151527.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-auth-hmac-sha196-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-auth-hmac-sha196-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980218151527.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Fri Feb 20 15:21:26 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA21710 for ipsec-outgoing; Fri, 20 Feb 1998 15:21:16 -0500 (EST) Message-Id: <199802202033.PAA14513@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-auth-hmac-md5-96-03.txt Date: Fri, 20 Feb 1998 15:33:38 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Use of HMAC-MD5-96 within ESP and AH Author(s) : C. Madson, R. Glenn Filename : draft-ietf-ipsec-auth-hmac-md5-96-03.txt Pages : 6 Date : 18-Feb-98 This draft describes the use of the HMAC algorithm [RFC-2104] in conjunction with the MD5 algorithm [RFC-1321] as an authentication mechanism within the revised IPSEC Encapsulating Security Payload [ESP] and the revised IPSEC Authentication Header [AH]. HMAC with MD5 provides data origin authentication and integrity protection. Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a]. 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-auth-hmac-md5-96-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-md5-96-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-auth-hmac-md5-96-03.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: <19980218151508.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-auth-hmac-md5-96-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-auth-hmac-md5-96-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980218151508.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Fri Feb 20 15:24:31 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA21888 for ipsec-outgoing; Fri, 20 Feb 1998 15:24:21 -0500 (EST) Date: Fri, 20 Feb 1998 13:56:18 -0500 From: Norman Shulman X-Sender: norm@rafael.tornd.securecomputing.com To: Robert Moskowitz cc: "adams@cisco.com" , "'Theodore Y. Ts'o'" , Daniel Harkins , "ipsec@tis.com" Subject: RE: IPSEC WORKING GROUP LAST CALL In-Reply-To: <3.0.5.32.19980220120445.009c5ba0@homebase.htt-consult.com> Message-Id: <98Feb20.135713est.11650@janus.tor.securecomputing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Fri, 20 Feb 1998, Robert Moskowitz wrote: > There was one position that the IETF does > not specify weakning DES to 40 bits (then why ARCFour?, sigh). RC4-128, as well as RC4-40 for export. Norm Norman Shulman Secure Computing Canada Systems Developer Tel 1 416 813 2075 norm@tor.securecomputing.com Fax 1 416 813 2001 From owner-ipsec Fri Feb 20 16:09:19 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA22259 for ipsec-outgoing; Fri, 20 Feb 1998 16:08:27 -0500 (EST) Message-ID: From: Roy Pereira To: "IPSEC Mailing List (E-mail)" , "Dan Harkins (E-mail)" Subject: Certificate Requesting Date: Fri, 20 Feb 1998 16:48:42 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk The issue of certificate requesting came up at thursday's IPSec/CA meeting. The issue is that the certificate payload is optional when the authentication method is RSA_SIG, but that the system doesn't know whether or not the other peer has their certificate. If the other peer already has it, then there is no point of sending a 1400 byte certificate payload in the ISAKMP message. So, this is where the certificate request payload comes into play. Unforetunately, there really hasn't been too much clear text of the usage of this payload. The specifications state that this payload MAY appear in any exchange, but it was determined at the IPSec/CA meeting that clearer wording would be required. I should also mention that this does not break any of the IPSec specifications, it only would make this situation clearer to an implementer. Only two situations come to mind where the CertReq payload would come in handy; (1) after the authentication exchange has been sent without a certificate and the other peer did not have or could not get the peer's certificate or (2) during the second exchange where we send over DH public keys and nonces. A CertReq here would denote that the peer has no way of retreiving a certificate so that the other peer must include their certificate in the next exchange. Since the CERT_REQ payload can be located in any exchange, it might be located on the last message; Initiator Responder ---------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, Ni --> <-- HDR, KE, Nr HDR*, IDii, [ CERT, ] SIG_I --> <-- HDR*, IDir, [ CERT, ] SIG_R [, CERTREQ [ HDR*, CERT [, CERTREQ] --> [<-- HDR*, CERT ] ] ] This would cause one or two extra messages to occur as in the above example. So, can we add wording to the IKE document to clearify this situation so that we can incorporate this feature for the March 2nd bakeoff? From owner-ipsec Fri Feb 20 16:09:38 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA22272 for ipsec-outgoing; Fri, 20 Feb 1998 16:09:27 -0500 (EST) Message-Id: <199802202122.NAA02955@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: perry@piermont.com Cc: ipsec@tis.com Subject: Re: IPSEC WORKING GROUP LAST CALL In-Reply-To: Your message of "Fri, 20 Feb 1998 15:26:59 EST." <199802202027.PAA03149@jekyll.piermont.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 20 Feb 1998 13:22:26 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk > I removed "someone"'s name because I don't want them to think the > following targets them specifically. It is directed not at particular > people but at the notion of ciphers with inadequate key lengths being > standardized, even in the "sheep's clothing" of variable length > ciphers that permit inadequate lengths. > > Ahh, yea, right. Add a "disclaimer" and gratuitous imbedded pseudo-html and it's ok to be a prick? I think not. > You argue "hey, some of us have to make a living". Well, do it in a > less damaging way -- sell CD-ROM encyclopedias door to door or > something. If you insist on selling your customers junk -- and 40 bit > encryption is *junk* -- please do not ask the rest of us to endorse > your mechanism with the imprimateur of the IETF. The last thing I want > on earth is to see such a box sold with a brochure advertising its > compliance with RFC YYYY. Find a better way of marketing the > antifreeze you propose selling as booze to the third world > natives. You don't need an RFC number to do that. Hey, screw you! What do you _produce_ anyway? We sell what we are permitted by law and so do you, it's just that you sell advice. If someone wants 3DES for their router we'll be happy to sell it. If they want crap we'll also be happy to sell that. We are just bound by the laws of this country. It's easy to be righteously indignant when it doesn't effect you and since your "product" is not affected by this you don't think twice before you rise to the occasion. Bully for you. For your information, we are permitted to export single DES so this whole 40bit nonsense does not affect me. I'm trying to forge a compromise and am sympathetic to people who may not have a job because their company can't make enough money in a domestic market alone. I don't have that worry; our domestic sales would be enough even if we didn't have export approval for single DES. Unfortunatly some people love to hear the sound of their own voice even if it's in email. Get off your soapbox asshole. Nobody's asking for The Imprimateur of the IETF. And who really cares what you want to see anyway? > Oh, and if any vendor does go through the exercise of selling such a > thing, I suspect that software will be widely distributed on the net > to help even unskilled teenage crackers break the "encryption"[sic] > without having to know what they are doing. I suspect that because if > no one else does I'll write it and distribute it myself. A false sense > of security is worse than no security. Vendors already sell such a thing (40bit DES obfuscation products). Put up or shut up. I hope this is more imaginative (and faster) than simple brute force. In any event, I'm waiting. Dan. From owner-ipsec Fri Feb 20 16:11:32 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA22307 for ipsec-outgoing; Fri, 20 Feb 1998 16:11:27 -0500 (EST) Message-ID: From: Roy Pereira To: "'Daniel Harkins'" , "'Theodore Y. Ts'o'" Cc: "'Robert Moskowitz'" , "'adams@cisco.com'" , "'perry@piermont.com'" , "'ipsec@tis.com'" Subject: RE: IPSEC WORKING GROUP LAST CALL Date: Fri, 20 Feb 1998 16:51:24 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk The document already defines blowfish as using a key length of between 40 and 448 bits. RC5 and CAST may also use 40 bits. The question is do we want to modify the DES cipher document to include variable key lengths (40 and 56 bits) ? >-----Original Message----- >From: Daniel Harkins [SMTP:dharkins@cisco.com] >Sent: Friday, February 20, 1998 2:29 PM >To: Theodore Y. Ts'o >Cc: Robert Moskowitz; adams@cisco.com; perry@piermont.com; ipsec@tis.com >Subject: Re: IPSEC WORKING GROUP LAST CALL > >As Bob said, how to weaken the key is well known but I figured a CBC-MAC >was well known and that apparently is not the case. We need documents >describing things and there is no document describing "40 bit DES" (maybe >there's some weird gov't document that I'm not aware of). Since DES does >not use a variable length key-- "40 bit DES" uses and 8 byte key the same >as "56 bit DES"-- it is not appropriate to negotiate DES with the key length >attribute set to 40. So I think "40 bit DES" is out. > >Perhaps a compromise between the two camps is to add another document to >the pile that will allow people who happen to live in a country with export >regulations to export an IPSec implementation. That would be some document >that describes a variable length cipher, which means RC4 or Blowfish. >Personally, I'd prefer Blowfish. > >How does this sound? We (the IPSec WG) are not tacitly endorsing this >insane policy our gov't (and Israel's gov't and Russia's gov't and France's >gov't and .... ) has, yet we're giving people whose livelihood depends on >being able to sell product to continue to be gainfully employed and producing >something useful and secure (in addition to the weak exportable product). > > Dan. > From owner-ipsec Fri Feb 20 16:13:31 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA22334 for ipsec-outgoing; Fri, 20 Feb 1998 16:13:27 -0500 (EST) Date: Fri, 20 Feb 1998 16:25:49 -0500 (EST) Message-Id: <199802202125.QAA22003@carp.morningstar.com> From: Ben Rogers To: perry@piermont.com Cc: ipsec@tis.com Subject: Re: IPSEC WORKING GROUP LAST CALL In-Reply-To: <199802202027.PAA03149@jekyll.piermont.com> References: <199802201928.LAA02807@dharkins-ss20.cisco.com> <199802202027.PAA03149@jekyll.piermont.com> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Perry E. Metzger writes: > I don't understand why we wish to specify this at all. Even single DES > isn't secure any more. IBM, to their credit, doesn't call their 40 bit > DES based algorithm encryption -- they call it "commercial data > masking". > > You argue "hey, some of us have to make a living". Well, do it in a > less damaging way -- sell CD-ROM encyclopedias door to door or > something. If you insist on selling your customers junk -- and 40 bit > encryption is *junk* -- please do not ask the rest of us to endorse > your mechanism with the imprimateur of the IETF. The last thing I want > on earth is to see such a box sold with a brochure advertising its > compliance with RFC YYYY. Find a better way of marketing the > antifreeze you propose selling as booze to the third world > natives. You don't need an RFC number to do that. Perhaps that's what we need to do then. Yes, 40-bit encryption is not secure. However, it is as secure as US companies are allowed to export. (I'm not up to date on the facist encryption laws of _other_ countries, so I'll refrain from making broader statements.) Moreover there are non-US companies which are quite willing to buy 40 bit "encryption" because that is all they can get. (It is certainly better than nothing, which is often the only alternative they consider -- arguments about a false sense of security aside.) Of course, this is not the wisest of decisions, and it is my responsibility as a vendor to make sure the customer knows that. However, it is neither my responsibility nor my place to tell the customer he _can't_ make that decision. The bottom line is that people will ask for 40 bit encryption and it will be provided for them. As a standards body it is our responsibility to help different implementations interoperate. > Oh, and if any vendor does go through the exercise of selling such a > thing, I suspect that software will be widely distributed on the net > to help even unskilled teenage crackers break the "encryption"[sic] > without having to know what they are doing. I suspect that because if > no one else does I'll write it and distribute it myself. A false sense > of security is worse than no security. Please do. Perhaps it will wake people up enough to campaign for exportable encryption. If nothing else, we (the corporate sector) can approach the government with the argument that we _tried_ to sell 40 bit encryption abroad and nobody would buy it. Heck, for that matter, save up your pennies for a 3 hour 56-bit DES breaker and sell time on it to anyone who might be interested. Maybe we could push ourselves past the 56 bit barrier as well. Your argument is similar to telling someone not to use their seat-belt on their aging car because it doesn't provide adequate security without being paired with an airbag. Yes, you will kill yourself at a 60MPH collision regardless of whether you have the belt on. But it does provide a little help. You just have to be aware enough to consider what little amount of protection you actually do have and to temper your driving accordingly. 40 bit encryption has certainly aged beyond its lifetime. But, cracking it does still require a non-trivial amount of compute power. You just have to make sure that the data passing over it doesn't exceed the value of the machine needed to crack it. ben From owner-ipsec Fri Feb 20 16:16:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA22347 for ipsec-outgoing; Fri, 20 Feb 1998 16:16:27 -0500 (EST) Message-ID: <01BD3E03.6F76E9D0.adams@cisco.com> From: Rob Adams Reply-To: "adams@cisco.com" To: "'perry@piermont.com'" , "ipsec@tis.com" Subject: RE: IPSEC WORKING GROUP LAST CALL Date: Fri, 20 Feb 1998 13:28:24 -0800 Organization: Cisco Systems Global Alliances X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk This is becoming fun.. %) Perry, I understand the way you feel and I'm not happy about the situation either. But it is what we are stuck with and I can't do anything about it. And it certainly will not be just me. There will be many many people in this situation. So, I need this. A bunch of us need this. If you aren't comfortable agreeing to a standards document, then provide a number and a method for negotiating down to stupid. I think that is reasonable. That gives you a way to say you don't endorse it and allows those of us that do have to depend on exporting products to stay in business or out of jail.. Righteous indignation aside, this really is critical for some of us. -Rob On Friday, February 20, 1998 12:27 PM, Perry E. Metzger [SMTP:perry@piermont.com] wrote: > > Someone writes: > > As Bob said, how to weaken the key is well known but I figured a CBC-MAC > > was well known and that apparently is not the case. We need documents > > describing things and there is no document describing "40 bit DES" > > I removed "someone"'s name because I don't want them to think the > following targets them specifically. It is directed not at particular > people but at the notion of ciphers with inadequate key lengths being > standardized, even in the "sheep's clothing" of variable length > ciphers that permit inadequate lengths. > > > > I don't understand why we wish to specify this at all. Even single DES > isn't secure any more. IBM, to their credit, doesn't call their 40 bit > DES based algorithm encryption -- they call it "commercial data > masking". > > You argue "hey, some of us have to make a living". Well, do it in a > less damaging way -- sell CD-ROM encyclopedias door to door or > something. If you insist on selling your customers junk -- and 40 bit > encryption is *junk* -- please do not ask the rest of us to endorse > your mechanism with the imprimateur of the IETF. The last thing I want > on earth is to see such a box sold with a brochure advertising its > compliance with RFC YYYY. Find a better way of marketing the > antifreeze you propose selling as booze to the third world > natives. You don't need an RFC number to do that. > > Oh, and if any vendor does go through the exercise of selling such a > thing, I suspect that software will be widely distributed on the net > to help even unskilled teenage crackers break the "encryption"[sic] > without having to know what they are doing. I suspect that because if > no one else does I'll write it and distribute it myself. A false sense > of security is worse than no security. > > The 40 bit "encryption" fraud must end. > > I've flamed on enough here already, and won't go any further with it > right now. I believe people can tell how strongly I feel about this. > > > > > Perry > From owner-ipsec Fri Feb 20 17:17:44 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA22962 for ipsec-outgoing; Fri, 20 Feb 1998 17:16:27 -0500 (EST) From: Will Fiveash Message-Id: <199802202228.QAA39814@vulcan.austin.ibm.com> Subject: Multiple Phase 1 Channels between hosts? To: ipsec@tis.com (IETF IPSEC) Date: Fri, 20 Feb 1998 16:28:57 -0600 (CST) X-Mailer: ELM [version 2.4ME+ PL37 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Is anyone supporting multiple phase 1 channels between the same two hosts when Main mode is used in the phase 1 negotiations? I ask this for two reasons: 1> Is there is a real need for a user to be able to specify that particular phase 1 security parameters protect particular phase 2 SA negotiations? 2> If 1> is true then it seems to me that when Main mode is used, the responder is going to have a hard time determining the correct Phase 1 security policy to use in phase 1 negotiations and also that a particular Phase 2 negotiation was protected by the "correct" Phase 1 SA as specified by local security policy. The following diagram shows different Phase 1 channels protecting different Phase 2 SA negotiations (for different client ID pairs). Host Host A B --- --- | | |______________Phase 1 using DES, HMD5___________________| | | | | | |___________Phase 2 using AH HMD5____________| | | (authenticate DNS) | | | | | |______________Phase 1 using 3DES, SHA___________________| | | |___________Phase 2 using AH+ESP ____________| (auth/encrypt email) -- Will Fiveash IBM AIX System Development Internet: will@austin.ibm.com 11400 Burnet Road, Bld.905/9551 Notes: will@austin.ibm.com@internet Austin, TX 78758-3493 Phone:(512) 838-7904(off)/3509(fax), T/L 678-7904 From owner-ipsec Fri Feb 20 17:20:32 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA22978 for ipsec-outgoing; Fri, 20 Feb 1998 17:20:28 -0500 (EST) Message-ID: From: Roy Pereira To: "'adams@cisco.com'" , "'perry@piermont.com'" , "'ipsec@tis.com'" Subject: RE: IPSEC WORKING GROUP LAST CALL Date: Fri, 20 Feb 1998 17:11:03 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk >Righteous indignation aside, this really is critical for some of us. > >Unless you are a Canadian company that can legally export 56 bit DES. ;-) >But I digress, so back to the yelling match.... From owner-ipsec Fri Feb 20 17:26:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA23053 for ipsec-outgoing; Fri, 20 Feb 1998 17:26:28 -0500 (EST) Message-Id: <199802202238.RAA03373@jekyll.piermont.com> To: Daniel Harkins cc: ipsec@tis.com Subject: Re: IPSEC WORKING GROUP LAST CALL In-reply-to: Your message of "Fri, 20 Feb 1998 13:22:26 PST." <199802202122.NAA02955@dharkins-ss20.cisco.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 20 Feb 1998 17:38:55 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Daniel Harkins writes: > Hey, screw you! What do you _produce_ anyway? We sell what we are permitted > by law and so do you, it's just that you sell advice. Well, okay, but be that as it may, 40 bit encryption remains worthless for confidentiality, and becomes even less worthwhile by the day. An RFC defining how to do it puts an implicit IETF imprimateur on a bad practice. I'd rather it not be standardized or endorsed in any fashion. > I'm trying to forge a compromise and am sympathetic to people who > may not have a job because their company can't make enough money in > a domestic market alone. Tell them to call up their Senator and explain to them that export controls are destroying their jobs. That is a political issue, not a technical issue. Just because the NSA would like us to pretend a sow's ear is a silk puurse does not make it the job of the IETF to pretend along. In short, standardizing bad technology to give jobs to people selling literally worthless devices is not what the IETF is about. We are not about job creation. We are about *Engineering*. Perry From owner-ipsec Fri Feb 20 17:48:48 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA23190 for ipsec-outgoing; Fri, 20 Feb 1998 17:48:31 -0500 (EST) Message-Id: <199802202301.SAA03401@jekyll.piermont.com> To: ben@Ascend.COM (Ben Rogers) cc: perry@piermont.com, ipsec@tis.com Subject: Re: IPSEC WORKING GROUP LAST CALL In-reply-to: Your message of "Fri, 20 Feb 1998 16:25:49 EST." <199802202125.QAA22003@carp.morningstar.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 20 Feb 1998 18:01:23 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Ben Rogers writes: > Perhaps that's what we need to do then. Yes, 40-bit encryption is not > secure. However, it is as secure as US companies are allowed to export. Lets say that U.S. law only allowed your pharmaceutical to export colored water. Would you pretend to your customers overseas that you were selling them antibiotics? Sure, U.S. law says that if it is useful you can't export it. Does that mean you will go along and produce > Moreover there are non-US companies which are quite willing to buy > 40 bit "encryption" because that is all they can get. That's untrue. If you know of such a company, please direct them to companies like SSH Data Security in Finland (http://www.ssh.fi/) or any one of dozens of other overseas firms that will happily sell you cryptography as strong as we know how to make it. > (It is certainly better than nothing, That is not, in fact, the case. I would strenuously argue that 40 bit encryption is worse than nothing. It promotes a dangerous illusion of security AND reduces your performance. As just one example, take 40 bit SSL. Financial applications are allowed to export crypto of high strength, but because 40 bit SSL is around, large amounts of important information is transiting the net essentially unencrypted. It doesn't even *need* to be sent that way, but the "supposedly okay" in this instance is the enemy of the good. Were it not for this quack medicine sold in pretty bottles, we'd have decent protection of many of these apps. And no, I'm not going to name the institutions involved. > Of course, this is not the wisest of decisions, and it is my > responsibility as a vendor to make sure the customer knows that. I ask you again: if the government told you you could only sell colored water as medicine, would you sell it anyway? > The bottom line is that people will ask for 40 bit encryption and it > will be provided for them. Sure. Does the IETF have to endorse this practice? > As a standards body it is our responsibility to help different > implementations interoperate. Next you will argue that the american pharmaceutical industry needs standards for our hypothetical colored water so that people in third world countries with infections can know they are getting the right colored water. I want people to understand in no uncertain terms that claiming 40 bit ciphers are trivial to break in real time with minimal expenditure is not hyperbole. It is literally true. 40 bit ciphers are a quack cure, not real medicine. > Please do. Perhaps it will wake people up enough to campaign for > exportable encryption. If nothing else, we (the corporate sector) can > approach the government with the argument that we _tried_ to sell 40 bit > encryption abroad and nobody would buy it. Heck, for that matter, save > up your pennies for a 3 hour 56-bit DES breaker and sell time on it to > anyone who might be interested. Maybe we could push ourselves past the > 56 bit barrier as well. That would cost a few hundred k. I believe putting out a "crack 40 bit keys" package for the naive end user would be a better demonstration. > Your argument is similar to telling someone not to use their seat-belt > on their aging car because it doesn't provide adequate security without > being paired with an airbag. No, I'm telling people that tying a rope around their ankle and pretending its a seat belt is not going to provide them with safety. 40 bit ciphers are useless childrens toys. They are barely a step up from Rot 13. > 40 bit encryption has certainly aged beyond its lifetime. But, cracking > it does still require a non-trivial amount of compute power. For some very low definition of "non-trivial" perhaps. > You just have to make sure that the data passing over it doesn't > exceed the value of the machine needed to crack it. True enough. Lets ask what that magic value might be, shall we? Blaze, Diffie, Rivest, Schneier, Shimomura, Thompson and Weiner estimated that, using November 1995 technology, breaking a 40 bit key would cost about $.08 per crack (that is eight cents) for a moderate expenditure, and about $.001 per crack (that is one tenth of a cent) for high expenditures. It is now 1998. Lets be generous and pretend that it still costs three whole cents to crack a message, though two or less is probably more like it. Can you think of any message containing any value whatsoever that is worth less than three cents. Just the hassle of changing my credit card numbers would cost me many dollars in wasted personal time even if I didn't lose a single penny from the fraud itself. The phone calls to the bank will cost me more than three cents. Perry From owner-ipsec Fri Feb 20 17:55:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA23271 for ipsec-outgoing; Fri, 20 Feb 1998 17:55:31 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199802201902.LAA06253@spire.inside.sealabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 20 Feb 1998 18:05:23 -0500 To: Chris Boscolo From: Stephen Kent Subject: Re: IPSEC Arch, ports, and tunnel mode SAs Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Chris, >Can I set up a tunnel mode SA between two SGs where one of the >(outbound) selectors is a protocol port? If so, what do I do when I >receive an IP fragment on my "non-IPSEC" side? I can't determine >which tunnel to send through since I may not have the port info. Yes, you can set up such an association, but you will have a problem if you receive fragments, as you observed. Appropriate of ICMP PMTU can avoid fragmentation, and many environments do not experience fragmentation due to various conventions, so it is reasonable to support this selector option. >Or, is the decision to forward fragments dependent on what I have in >the ports field of the selector. That is if the port fields are set >to "don't care", then I can send fragments. But, if they are set to >specific values, then I must drop fragments. Use of "don't care" works if you really don't care; send a PMTU ICMP to cause future packets to not be fragments, as the text suggests, if you do care. >It seems like a bad idea to me to allow ports as a selector if it >means that we can't send ip fragments through the tunnels. (you might >extend this statement and say it is a bad idea to allow ports as a >selector for tunnel mode SAs.) Not all tunnel mode SAs involve gateways, so the latter suggestion is overkill. Because there are means of addressing (red) fragment arrival problems, and because many users will want to employ port filtering at security gateways, it seems reasonable to retain this feature. Steve From owner-ipsec Fri Feb 20 17:57:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA23292 for ipsec-outgoing; Fri, 20 Feb 1998 17:57:31 -0500 (EST) Date: Fri, 20 Feb 98 15:07:29 PST From: jim@mentat.com (Jim Gillogly) Message-Id: <9802202307.AA10967@mentat.com> To: ipsec@tis.com Subject: Re: IPSEC WORKING GROUP LAST CALL Sender: owner-ipsec@ex.tis.com Precedence: bulk Regarding the 40-bit data masking issue... The argument is being made that because US export laws make it hard to export real encryption, the standard should specify a way to export totally insecure data masking instead. This seems misguided to me. IPsec is about an international standard for communicating securely. It is not about providing political support for one or another country's export regulations. Despite claims that it's up to the customer whether they want to be able to use this product in a secure or insecure mode, the fact is that most customers won't know the difference. As far as they're concerned, if the product conforms to an IETF standard then it must provide some security. If they sniff a packet and don't see their natural language in it, they couldn't tell the difference between 3DES and the Morris-Worm encryption method of XORing each byte with 0x81. If your customers want Morris-Worm Encryption, should it go into an RFC that has the IPsec seal of approval? I submit that it shouldn't. If we think back to the MUST algorithm decision, 56-bit DES was a compromise: it's really too short for serious security, and Michael Wiener's recent update to his older DES-breaking paper only reinforces this. It's been argued that breaking 40-bit crypto requires a significant amount of computational power. This seems wrong on its face: the RSA challenge was broken in about 3 hours by two different people, each with only a few dozen standard workstations. I don't know what your threat model is, but mine includes companies with access to more than a few dozen workstations. And even if it a smart thing to do, 40-bit DES would be a choice because you have all the inefficiency of full 56-bit DES combined with no security. If this isn't going to be a security standard, we might as well pack it in: if it's not worth doing, it's not worth doing right. Jim Gillogly (speaking for myself, if it needs to be said) From owner-ipsec Fri Feb 20 18:04:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA23346 for ipsec-outgoing; Fri, 20 Feb 1998 18:04:30 -0500 (EST) Message-Id: <199802202317.SAA03413@jekyll.piermont.com> To: "adams@cisco.com" cc: "ipsec@tis.com" Subject: Re: IPSEC WORKING GROUP LAST CALL In-reply-to: Your message of "Fri, 20 Feb 1998 13:28:24 PST." <01BD3E03.6F76E9D0.adams@cisco.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 20 Feb 1998 18:17:43 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Rob Adams writes: > So, I need this. A bunch of us need this. If you aren't > comfortable agreeing to a standards document, then provide a number > and a method for negotiating down to stupid. I think that is > reasonable. May I ask you why you would want to sell snake oil to customers? I mean, you know that 40 bit keys are worthless for practical purposes. You wouldn't sell a customer a "latency server" that slowed their packets down by 20ms and did nothing else for them. Why would you sell them a box that probably has just about as much use to them? > That gives you a way to say you don't endorse it and allows those of > us that do have to depend on exporting products to stay in > business or out of jail.. Why do you want to stay in this business in the first place? If your customers need IPsec products, let them buy them from folks in Finland or New Zealand. They don't need to buy junk from you when they could buy full strength crypto from other countries. > Righteous indignation aside, this really is critical for some of us. You are telling me that the crypto regulations have caused you pain, and that jobs might be lost because of them. True enough. You work for a giant company. Tell them to go and lobby the Congress to get rid of the stupidity before you lose more jobs. Don't pretend that if you sell clear polyethelene bags for your customers to walk around in that people can't still see their genitalia or that they are going to stay warm in the things in the winter. This is, in essense, a political problem. You are losing business to companies overseas, and you don't want to, so you are asking us to make it possible for you to sell something that we will pretend is "IPsec" even though it isn't really useful, so that your customers won't go to Tatu Ylonen or Eric Leay or someone else in a free country to get their crypto. Are you doing those customers a service by distracting them from products that would actually solve their security problems so that you can make another sale? Is that the ethical way to go about your business? Sure, you are losing jobs. Solve the political problem with politics, not with playing with the standards docs. Above all, I don't want naive systems managers who barely know which end of the connector to plug in to be distracted by fake cryptography. If the choice is between just having offshore vendors selling conformant products to offshore customers, or having onshore vendors selling fake security products to those offshore customers instead of the offshore vendors selling them real ones, I'd rather have the U.S. lose jobs. Perry From owner-ipsec Fri Feb 20 18:52:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA23622 for ipsec-outgoing; Fri, 20 Feb 1998 18:50:30 -0500 (EST) Message-ID: From: Greg Carter To: "'IPSEC Mailing List (E-mail)'" , "'Dan Harkins (E-mail)'" , "'Roy Pereira'" Subject: RE: Certificate Requesting Date: Fri, 20 Feb 1998 18:54:31 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Roy, I know a few IKE's that will accept the Cert Req in the SA exchange, the KE, or the final ID part. I really don't what to see the case you propose as even being valid (additional exchange). For one it allows for an awful state on the responder. Take this situation > Initiator Responder > ---------- ----------- > HDR, SA --> > <-- HDR, SA > HDR, KE, Ni --> > <-- HDR, KE, Nr > HDR*, IDii,CERT, SIG_I --> > <-- HDR*, IDir, SIG_R If I am the Responder I have all I need, my main mode is done. But now I have to keep it open just in case you want to send me a cert request payload. No sir, No sir, I don't like it. > HDR*, CERTREQ --> You can't do it under an info because the Responder has gone to the Encrypt only state because he has a valid SA. ISAKMP states that optional payloads must be accepted any time during the exchange, to me this doesn't mean it is valid to extend the exchange >to send optional payloads. Send your Cert Req either during SA, KE, or ID exchanges. Don't tack on an additional exchange. I know this isn't the greatest because you don't have the ID payload until the last exchange. Well then you cache certs based on IP, or you cache certs based on SA, or you send over your Vendor Specific cert cache info payload, or just don't cache certs and live with the 1k of additional data as opposed to the headaches you are going to cause yourself with caching... Bye. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com >---------- >From: Roy Pereira[SMTP:rpereira@TimeStep.com] >Sent: Friday, February 20, 1998 4:48 PM >To: IPSEC Mailing List (E-mail); Dan Harkins (E-mail) >Subject: Certificate Requesting > >The issue of certificate requesting came up at thursday's IPSec/CA >meeting. The issue is that the certificate payload is optional when the >authentication method is RSA_SIG, but that the system doesn't know >whether or not the other peer has their certificate. If the other peer >already has it, then there is no point of sending a 1400 byte >certificate payload in the ISAKMP message. So, this is where the >certificate request payload comes into play. Unforetunately, there >really hasn't been too much clear text of the usage of this payload. >The specifications state that this payload MAY appear in any exchange, >but it was determined at the IPSec/CA meeting that clearer wording would >be required. > >I should also mention that this does not break any of the IPSec >specifications, it only would make this situation clearer to an >implementer. > >Only two situations come to mind where the CertReq payload would come in >handy; > >(1) after the authentication exchange has been sent without a >certificate and the other peer did not have or could not get the peer's >certificate or > >(2) during the second exchange where we send over DH public keys and >nonces. A CertReq here would denote that the peer has no way of >retreiving a certificate so that the other peer must include their >certificate in the next exchange. > >Since the CERT_REQ payload can be located in any exchange, it might be >located on the last message; > > Initiator Responder > ---------- ----------- > HDR, SA --> > <-- HDR, SA > HDR, KE, Ni --> > <-- HDR, KE, Nr > HDR*, IDii, [ CERT, ] SIG_I --> > <-- HDR*, IDir, [ CERT, ] SIG_R[, >CERTREQ > [ HDR*, CERT [, CERTREQ] --> > [<-- HDR*, CERT ] ] ] > >This would cause one or two extra messages to occur as in the above >example. > >So, can we add wording to the IKE document to clearify this situation so >that we can incorporate this feature for the March 2nd bakeoff? > From owner-ipsec Fri Feb 20 18:59:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA23680 for ipsec-outgoing; Fri, 20 Feb 1998 18:59:30 -0500 (EST) Message-Id: <199802210012.QAA03298@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: perry@piermont.com Cc: ipsec@tis.com Subject: Re: IPSEC WORKING GROUP LAST CALL In-Reply-To: Your message of "Fri, 20 Feb 1998 17:38:55 EST." <199802202238.RAA03373@jekyll.piermont.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 20 Feb 1998 16:12:26 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk > Well, okay, but be that as it may, 40 bit encryption remains worthless > for confidentiality, and becomes even less worthwhile by the day. An > RFC defining how to do it puts an implicit IETF imprimateur on a bad > practice. I'd rather it not be standardized or endorsed in any > fashion. You should've read my post before you got carried away with that knee jerk reaction. I said "'40 bit DES' is out." I was suggesting standardization on a cipher which takes variable-length key, such as Blowfish, and _not_ 40 bit DES. > > I'm trying to forge a compromise and am sympathetic to people who > > may not have a job because their company can't make enough money in > > a domestic market alone. > > Tell them to call up their Senator and explain to them that export > controls are destroying their jobs. You obviously think people have been sitting on their thumbs for the past few years. Without going into the gory details let me just submit that you obviously don't know what you're talking about. > In short, standardizing bad technology to give jobs to people selling > literally worthless devices is not what the IETF is about. We are not > about job creation. We are about *Engineering*. If your worried about tarnishing the good name of the IETF or out-of-control marketeers saying their product is "blessed by the IETF" let me point a few things out: 1. Marketeers are already doing this. "We're RFC-compliant" means their proprietary protocol uses HMAC. Or even better, It's been "submitted to the IETF" means their braindead idea has been written up as an Internet Draft and languishes in some working group and will expire shortly. 2. An "exportable" IPSec implementation which only supported a variable length key cipher (like Blowfish) and refused to negotiate any length > 40 would not be "IPSec compliant" anyway because they didn't do the mandatory-to-implement transform. Of course, that won't stop the marketeers from claiming compliance but there's nothing you can do about that and there are plenty of companies that currently do only the depricated transforms with manual keying and still say they're "IPSec compliant". 3. Someone can already produce "exportable" IPSec implementations by negotiating a transform from the private use range in the DOI numberspace and negotiate a 512-bit Diffie-Hellman group directly (P,G,type instead of using one of the already-defined identifiers). And, again, there's nothing you can do to stop them from claiming they "do IPSec". 4. A standardized cipher which used variable length keys would not have to have the number 40 in it anywhere; it would not have to discuss dumbing down your crypto. It would not be an IETF endorsement to do anthing stupid in the way that a standardized 40bit DES specification would. (Of course, you know the _real_, sinister reason for variable length keyed ciphers, wouldn't you Agent Molner?). 5. I know of a company (not mine!) that is working on a version of IPSec that includes key recovery. It's gonna do 3DES especially for you Perry but the key will be leaked. They can proudly boast that the IETF imprimatur is stamped on their foreheads and their product is insecure. Given the amount of times "IETF approved" is used in vain your arguments about the sanctity of the IETF imprimatur reminds me of someone defending the good name of a prostitute. Give it up, her virginity was gone long ago. The real problem it seems to me is the blind faith that someone would put in the statement "RFC compliant" or "IETF approved" or "security expert". Especially if it come out of a marketing brochure. You're right, this is about "engineering". What is your non-political opposition to standardization on Blowfish? It's free, it's (pretty) fast, and it supports 448-bit keys if you're really hung up on key length (and it appears you are). Dan. From owner-ipsec Fri Feb 20 19:19:42 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA23770 for ipsec-outgoing; Fri, 20 Feb 1998 19:19:32 -0500 (EST) Date: Fri, 20 Feb 1998 19:32:22 -0500 Message-Id: <199802210032.TAA04172@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: Export of Weak Crypto Rathole.... Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk May I suggest to all concerned that we table this discussion of weak crypto? We've had this discussion many times before in the past, and I doubt it's profitable for us to have this discussion again. The task before us is to get the current core set of IPSEC documents out as Internet Standards. Support of export-grade "cryptography" was not in the scope of the original IPSEC drafts, and I don't believe this is time to add additional optional algorithms. There will be plenty of time to debate the merits of additional optional algorithms after we get the core documents out. I am not singling out export grade crypto with this statement; I've made similar statements about the RIPEMD hash algorithm. If we have general concensus that draft-ietf-ipsec-ciph-cbc-01.doc (which includes 3DES) is ready, then I'm not opposed to sending it to the IESG along with everything else, since it will avoid needing to rip out a lot of references from the DOI. However, now is not the right time to add new crypto algorithms, such as 112-bit 3DES, or 40 bit DES. So why don't we table this discussion for now? We can take that up after we get the core drafts out. - Ted From owner-ipsec Fri Feb 20 19:24:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA23824 for ipsec-outgoing; Fri, 20 Feb 1998 19:24:31 -0500 (EST) Message-Id: <199802210036.RAA04406@grissel.Compatible.COM> Comments: Authenticated sender is From: "Steve Goldhaber" To: ipsec@tis.com Date: Fri, 20 Feb 1998 17:36:57 -0700 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: IPSEC WORKING GROUP LAST CALL Reply-to: goldy@compatible.com In-reply-to: <01BD3E03.6F76E9D0.adams@cisco.com> X-mailer: Pegasus Mail for Win32 (v2.54) Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Rob Adams > Subject: RE: IPSEC WORKING GROUP LAST CALL > Date: Fri, 20 Feb 1998 13:28:24 -0800 > Organization: Cisco Systems Global Alliances > This is becoming fun.. %) > > Perry, I understand the way you feel and I'm not happy about the situation either. But it > is what we are stuck with and I can't do anything about it. And it certainly will not be just > me. There will be many many people in this situation. > > So, I need this. A bunch of us need this. If you aren't comfortable agreeing to > a standards document, then provide a number and a method for negotiating down > to stupid. I think that is reasonable. That gives you a way to say you don't endorse > it and allows those of us that do have to depend on exporting products to stay in > business or out of jail.. Anyone worried about jail had better read the new Bureau of Export Administration rules (see http://www.bxa.doc.gov/encstart.htm). Unless you get a license, you can't even export ROT-X where X is user-definable. The only 40-bit license available is for RC4. So the only way to legally export 40-bit DES today is to get permission to export 56-bit DES. How is 40-bit DES still critical in that environment? Does anyone on this list have actual customers who are only able to import 40-bit DES? Enough to put anyone out of a job? Steve Goldhaber Compatible Systems goldy@compatible.com http://www.compatible.com (303) 444-9532 From owner-ipsec Fri Feb 20 21:34:52 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA24572 for ipsec-outgoing; Fri, 20 Feb 1998 21:33:31 -0500 (EST) Date: Fri, 20 Feb 1998 21:43:29 -0500 (EST) From: Dave Mason Message-Id: <199802210243.VAA26269@rubicon.rv.tis.com> To: ipsec@tis.com, perry@piermont.com Subject: Re: IPSEC WORKING GROUP LAST CALL Sender: owner-ipsec@ex.tis.com Precedence: bulk Perry E. Metzger writes: > >Ben Rogers writes: >> Perhaps that's what we need to do then. Yes, 40-bit encryption is not >> secure. However, it is as secure as US companies are allowed to export. >> Moreover there are non-US companies which are quite willing to buy >> 40 bit "encryption" because that is all they can get. > >That's untrue. If you know of such a company, please direct them to >companies like SSH Data Security in Finland (http://www.ssh.fi/) or >any one of dozens of other overseas firms that will happily sell you >cryptography as strong as we know how to make it. Or direct them to TIS (Trusted Information Systems - www.tis.com) a US firm. -dmason From owner-ipsec Fri Feb 20 22:21:02 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA24781 for ipsec-outgoing; Fri, 20 Feb 1998 22:20:34 -0500 (EST) X-Lotus-FromDomain: CERTICOM From: "Paul Lambert" To: ho@earth.hpc.org cc: ipsec@tis.com Message-ID: <852565B0.00812DB6.00@domino_c02.certicom.com> Date: Fri, 20 Feb 1998 19:34:50 -0400 Subject: Re: Regrouping for IPSEC WORKING GROUP LAST CALL Sender: owner-ipsec@ex.tis.com Precedence: bulk Hilarie, >It's a big performance hit to take in response to a >"*may* have flaws". It is better to error on the side of better security. I assume that some of the same characteristics that allow you to factor the exponent to improve computation speed may also provide better attacks. I'm also not sure that it is that big of a performance hit since there are many interesting tricks to speed up elliptic curve computations. It is difficult to argue the topic of what algorithm is "strong enough" since stronger often means slower computations. The specification currently has field sizes of 155 and 185 exponents. ANSI has 163, 191, 239, 359 and 431. ANSI strongly reccomends against using field sizes less than 160! So, I propose that in the current IKE draft that: 1) The current Oakley Group 3 (2^^155) be removed. 2) Two additional groups be added from the existing ANSI definitions (163 and 239). 3) The exisitng and new field descriptions should be tweeked to match the ANSI and IEEE format for describing the information (replacement text soon). 4) The 185 (group 4) should be removed, or if it remains, a security warning on the fears associated with non-prime groups should be included. 5) If the group feels that an exportable EC exchange is required that is akin to RSA 512 this could also be added (Perry, please no flames on export issues). Regards, Paul ho@earth.hpc.org on 02/19/98 05:22:49 PM To: Paul Lambert/Certicom cc: ipsec@tis.com Subject: Re: Regrouping for IPSEC WORKING GROUP LAST CALL The Oakley groups were chosen to optimize computation time; the techniques don't work with prime exponents for the Galois field. It's a big performance hit to take in response to a "*may* have flaws". Hilarie Hilarie From owner-ipsec Fri Feb 20 23:31:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA25148 for ipsec-outgoing; Fri, 20 Feb 1998 23:28:31 -0500 (EST) Date: Fri, 20 Feb 1998 23:40:37 -0500 Message-Id: <199802210440.XAA04852@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "Paul Lambert" Cc: ho@earth.hpc.org, ipsec@tis.com In-Reply-To: Paul Lambert's message of Fri, 20 Feb 1998 19:34:50 -0400, <852565B0.00812DB6.00@domino_c02.certicom.com> Subject: Re: Regrouping for IPSEC WORKING GROUP LAST CALL Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Question to the working group: Should we remove the EC groups altogether and defer these issues to IPSECOND? I am certainly not an expert in this field, but my understanding is that each EC group can have radically different properties of speed, security, and patent encumberances (if you want to do computations in that group efficiently). Hence, it is not as simple as picking some an RSA key length, where a bigger RSA key is better than a shorter length RSA key. It's not clear to we that we can do justice to all of these complex and inter-related issues during the working group last call. Sounds to me like we might want to defer this issue. What do others think? - Ted From owner-ipsec Fri Feb 20 23:41:00 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA25205 for ipsec-outgoing; Fri, 20 Feb 1998 23:40:31 -0500 (EST) Date: Fri, 20 Feb 1998 23:53:00 -0500 Message-Id: <199802210453.XAA04873@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Greg Carter Cc: "'IPSEC Mailing List'" , "'Dan Harkins'" , "'Roy Pereira'" In-Reply-To: Greg Carter's message of Fri, 20 Feb 1998 18:54:31 -0500, Subject: Re: Certificate Requesting Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk From: Greg Carter Date: Fri, 20 Feb 1998 18:54:31 -0500 No sir, No sir, I don't like it. You may not like it, but the ISAKMP document is pretty clear on this point: >The Certificate Request payloads MUST be accepted at any point >during the exchange. The responder to the Certificate Request payload >MUST send its immediate certificate, if certificates are supported, and >SHOULD send as much of its certificate chain as possible. I understood Roy to be asking to insert some clarifying text; he's not asking for a protocol change, because ISAKMP has had this requirement for a very long time. - Ted From owner-ipsec Fri Feb 20 23:58:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA25303 for ipsec-outgoing; Fri, 20 Feb 1998 23:58:31 -0500 (EST) Date: Sat, 21 Feb 1998 00:08:46 -0500 (EST) From: Dave Mason Message-Id: <199802210508.AAA27272@rubicon.rv.tis.com> To: ipsec@tis.com Subject: Re: Regrouping for IPSEC WORKING GROUP LAST CALL Sender: owner-ipsec@ex.tis.com Precedence: bulk >Should we remove the EC groups altogether and defer these issues to >IPSECOND? > >It's not clear to we that we can do justice to all of these complex and >inter-related issues during the working group last call. Sounds to me >like we might want to defer this issue. What do others think? > > - Ted If it means delays, I vote to defer EC groups. -dmason From owner-ipsec Sat Feb 21 02:55:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA26188 for ipsec-outgoing; Sat, 21 Feb 1998 02:54:30 -0500 (EST) Message-ID: <34EDD5B1.591719A8@nortel.ca> Date: Fri, 20 Feb 1998 20:12:49 +0100 From: "Marcus Leech" Organization: Security Development X-Mailer: Mozilla 2.02 (X11; I; Linux 1.2.13 i486) MIME-Version: 1.0 To: Daniel Harkins CC: ipsec@tis.com Subject: Re: IPSEC WORKING GROUP LAST CALL References: <199802210012.QAA03298@dharkins-ss20.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Daniel Harkins wrote: > You're right, this is about "engineering". What is your non-political > opposition to standardization on Blowfish? It's free, it's (pretty) fast, > and it supports 448-bit keys if you're really hung up on key length (and > it appears you are). > Just in case that's a serious proposal: It's ugly, it's largely analysis free. From owner-ipsec Sat Feb 21 03:23:42 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA26341 for ipsec-outgoing; Sat, 21 Feb 1998 03:23:30 -0500 (EST) Message-Id: <199802210836.AAA04442@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: "Marcus Leech" Cc: ipsec@tis.com Subject: Re: IPSEC WORKING GROUP LAST CALL In-Reply-To: Your message of "Fri, 20 Feb 1998 20:12:49 +0100." <34EDD5B1.591719A8@nortel.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 21 Feb 1998 00:36:20 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk > Daniel Harkins wrote: > > You're right, this is about "engineering". What is your non-political > > opposition to standardization on Blowfish? It's free, it's (pretty) fast, > > and it supports 448-bit keys if you're really hung up on key length (and > > it appears you are). > > > Just in case that's a serious proposal: > > It's ugly, it's largely analysis free. ^^^^^^^^^^^^^^^^^^^^^ Yes, it was a serious proposal and I guess this is a reason to hold off, although beauty is in the eye of the coder. Thanks for providing a technical point to this embarassing thread. I withdraw my proposal. Dan. From owner-ipsec Sat Feb 21 03:35:49 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA26406 for ipsec-outgoing; Sat, 21 Feb 1998 03:35:31 -0500 (EST) Message-ID: <34EE94C9.7DE1@cs.umass.edu> Date: Sat, 21 Feb 1998 03:48:09 -0500 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V4.0 alpha) MIME-Version: 1.0 To: IP Security List Subject: Re: Regrouping for IPSEC WORKING GROUP LAST CALL References: <852565B0.00812DB6.00@domino_c02.certicom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk [For those who don't read PostScript, the relevant section of the cited paper by M\"{u}ller and Paulus says that "...for composite fields... there might be better methods" for attacking the elliptic curves.] Paul Lambert writes: > The specification currently has field sizes of 155 and 185 exponents. > ANSI has 163, 191, 239, 359 and 431. ANSI strongly reccomends against > using field sizes less than 160! > > So, I propose that in the current IKE draft that: [...] > 2) Two additional groups be added from the existing ANSI definitions > (163 and 239). I'm in favor of adding curves over field sizes of 163 and 239. However I oppose including the specific curves defined in ANSI. (Are these defns. from NCITS, or X9.62, or some other group?) Those curves already present relatively rich targets for precomputation attacks by virtue of their inclusion in an ANSI standard. Let's put the IPSEC eggs in separate baskets by generating some fresh curves for IKE with the requisite field sizes. -Lewis From owner-ipsec Sat Feb 21 04:14:16 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA26603 for ipsec-outgoing; Sat, 21 Feb 1998 04:12:31 -0500 (EST) Message-ID: <34EE9D72.4487@cs.umass.edu> Date: Sat, 21 Feb 1998 04:25:06 -0500 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V4.0 alpha) MIME-Version: 1.0 To: IP Security List CC: Hilarie Orman Subject: Re: IPSEC WORKING GROUP LAST CALL References: <199802182350.SAA14498@dcl.MIT.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Here are a couple of textual inconsistencies in the Oakley document : [1] There's an entry for a non-existent group in the list of Well-Known Groups at the top of Appendix E. current text: > The group identifiers: > > 0 No group (used as a placeholder and for non-DH exchanges) > 1 A modular exponentiation group with a 768 bit modulus > 2 A modular exponentiation group with a 1024 bit modulus > 3 A modular exponentiation group with a 1536 bit modulus (TBD) > 4 An elliptic curve group over GF[2^155] > 5 An elliptic curve group over GF[2^185] There's no such 1536-bit MODP group defined in the draft. Presumably this entry should be deleted, unless someone plans to determine the group within the next few days. The renumbered list would be: suggested text: _ 0 No group (used as a placeholder and for non-DH exchanges) _ 1 A modular exponentiation group with a 768 bit modulus _ 2 A modular exponentiation group with a 1024 bit modulus _ 3 An elliptic curve group over GF[2^155] _ 4 An elliptic curve group over GF[2^185] [2] Sect. 2.2.2 refers to some non-existent groups in its description of GRP: current text: > GRP is a name (32-bit value) for the group and its relevant > parameters: the size of the integers, the arithmetic operation, and > the generator element. There are a few pre-defined GRP's (for 768 > bit modular exponentiation groups, 1024 bit modexp, 2048 bit modexp, > 155-bit and 210-bit elliptic curves, see Appendix E), but > participants can share other group descriptions in a later protocol > stage (see the section NEW GROUP). [...] There's no 2048-bit MODP group defined, nor is there a 210-bit elliptic curve group. Probably it would be simplest to omit all mention of specific groups in this section, e.g.: suggested text: _ GRP is a name (32-bit value) for the group and its relevant _ parameters: the size of the integers, the arithmetic operation, and _ the generator element. There are a few pre-defined GRP's (see _ Appendix E), but participants can share other group descriptions in _ a later protocol stage (see the section NEW GROUP). [...] -Lewis From owner-ipsec Sat Feb 21 04:28:42 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA26657 for ipsec-outgoing; Sat, 21 Feb 1998 04:28:30 -0500 (EST) Message-ID: <34EEA145.6201@cs.umass.edu> Date: Sat, 21 Feb 1998 04:41:25 -0500 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V4.0 alpha) MIME-Version: 1.0 To: IP Security List CC: Hilarie Orman Subject: Re: IPSEC WORKING GROUP LAST CALL References: <199802182350.SAA14498@dcl.MIT.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk The Oakley document refers to draft-ietf-ipsec-dss-cert-00.txt, which seems to have long since expired (or did I miss it going to RFC?). The reference is in Sec. 2.5.2.d.2: > d.2 DSS keys w/ certificates > Encoding for the Digital Signature Standard with X.509 is > described in draft-ietf-ipsec-dss-cert-00.txt. Support for this > is OPTIONAL; an ISAKMP Authentication Type will be assigned. -Lewis From owner-ipsec Sat Feb 21 08:27:22 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA27821 for ipsec-outgoing; Sat, 21 Feb 1998 08:25:38 -0500 (EST) Date: Sat, 21 Feb 1998 15:47:28 +0200 (EET) From: Helger Lipmaa X-Sender: helger@keeks To: ipsec@tis.com Subject: Re: Export of Weak Crypto Rathole.... In-Reply-To: <199802210032.TAA04172@dcl.MIT.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Fri, 20 Feb 1998, Theodore Y. Ts'o wrote: > If we have general concensus that draft-ietf-ipsec-ciph-cbc-01.doc > (which includes 3DES) is ready, then I'm not opposed to sending it to > the IESG along with everything else, since it will avoid needing to rip > out a lot of references from the DOI. However, now is not the right > time to add new crypto algorithms, such as 112-bit 3DES, or 40 bit DES. > So why don't we table this discussion for now? We can take that up > after we get the core drafts out. I agree. Anyways, there are more important things to do. The general framework has to be ready before we start to worry about Russian export limitations. Helger http://home.cyber.ee/helger From owner-ipsec Sat Feb 21 19:11:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA01159 for ipsec-outgoing; Sat, 21 Feb 1998 19:05:32 -0500 (EST) Message-Id: <199802220018.TAA06026@jekyll.piermont.com> To: Daniel Harkins cc: perry@piermont.com, ipsec@tis.com Subject: Re: IPSEC WORKING GROUP LAST CALL In-reply-to: Your message of "Fri, 20 Feb 1998 16:12:26 PST." <199802210012.QAA03298@dharkins-ss20.cisco.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Sat, 21 Feb 1998 19:18:42 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Daniel Harkins writes: > > Well, okay, but be that as it may, 40 bit encryption remains worthless > > for confidentiality, and becomes even less worthwhile by the day. An > > RFC defining how to do it puts an implicit IETF imprimateur on a bad > > practice. I'd rather it not be standardized or endorsed in any > > fashion. > > You should've read my post before you got carried away with that knee > jerk reaction. I said "'40 bit DES' is out." I was suggesting standardization > on a cipher which takes variable-length key, such as Blowfish, and _not_ > 40 bit DES. Fine. We should be making sure that our Blowfish standard explicitly states that anything smaller than 90 bits of key (the length recommended as a minimum by the Blaze et al paper) doesn't conform with any RFC we put out. Anything that permits a 40 bit key to conform with an IETF standard is really not something I can support. 56 bit DES is a joke already -- I can barely support standardizing *that*, let alone 40 bit key capable algorithms. > Given the amount of times "IETF approved" is used in vain your arguments > about the sanctity of the IETF imprimatur reminds me of someone defending > the good name of a prostitute. Give it up, her virginity was gone long ago. "We know that people have committed fraud in the past. Why not just shut up and let more people do it again in the future!" Because we are better than that. Because not all of us are whores. Because some of us still have the illusion that the IETF doesn't exist as a job program for vendors selling trash. Because some of us have morals. > The real problem it seems to me is the blind faith that someone would put > in the statement "RFC compliant" or "IETF approved" or "security expert". > Especially if it come out of a marketing brochure. People out there do not have an understanding of security. They depend on people like me to help them out, and there aren't enough of me to go around, so they sometimes are forced to treat things like IETF standards documents as a good housekeeping seal. It is unreasonable to expect everyone on earth to spend years of their life getting to the point where they understand our field as well as we do. Like it or not, it is up to us to rise to the occassion. > You're right, this is about "engineering". What is your non-political > opposition to standardization on Blowfish? It's free, it's (pretty) fast, > and it supports 448-bit keys if you're really hung up on key length (and > it appears you are). I actually don't like the key scheduling in Blowfish and am not sure how much I trust the algorithm. None the less, I'll happily support an RFC standardizing the use of Blowfish with keys of 90 bits and above. Perry From owner-ipsec Sat Feb 21 19:33:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA01306 for ipsec-outgoing; Sat, 21 Feb 1998 19:31:32 -0500 (EST) Message-ID: <34EF748D.6956@cs.umass.edu> Date: Sat, 21 Feb 1998 19:42:53 -0500 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V4.0 alpha) MIME-Version: 1.0 To: Norio Korekawa CC: IP Security List Subject: Re: key derivation for ESP Authentication Algorithm References: <199802201044.TAA02097@baba-yaga.rinfo.sei.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Norio Korekawa writes: > I have a question about derivation of Phase 2 keying material and > I would greatly appreciate receiving an answer from someone of this > group. I haven't seen any replies to this, so I'll take a stab at it. > My question is: How is a key for ESP Authentication Algorithm derived > from a keying material SKEYID_d? > > I think it is derived in the same way as a key for ESP Encryption > Algorithm is derived, according to the following procedure. Yes, the raw keying material for each is derived as in the text you quoted. (The derivation of the actual keys from that raw material is algorithm specific.) > So the difference between the two(Encryption and Authentication) keys > is only its length, I think. Am I right? No, the keying material for encryption differs entirely from the keying material for authentication. This happens because the "protocol" value used to derive KEYMAT is a transform-specific value. The encryption transform is associated with one value for "protocol" and the authentication transform is associated with some other value for "protocol". Per IKE 5.5, pg.18: In either case, "protocol" and "SPI" are from the ISAKMP Proposal Payload that contained the negotiated Transform. > ----------------------------------------------------------------- > KEYMAT = prf(SKEYID_d, [g(qm)^xy] | protocol | SPI | Ni_b | Nr_b) > > KEYMAT = K1 | K2 | K3 | ... > where > K1 = prf(SKEYID_d, [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b) > K2 = prf(SKEYID_d, K1 | [ g(qm)^xy | ] protocol | SPI | Ni_b | > Nr_b) > K3 = prf(SKEYID_d, K2 | [ g(qm)^xy | ] protocol | SPI | Ni_b | > Nr_b) > etc. > ----------------------------------------------------------------- > > I'm afraid that I'm making a wrong guess, but I hope some will > kindly answer to me. > > Thanks in advance, > Norio Korekawa(korekawa@rinfo.sei.co.jp) > SUMITOMO ELECTRIC INDUSTRIES, LTD. Hope this helps -Lewis From owner-ipsec Sat Feb 21 22:48:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA02310 for ipsec-outgoing; Sat, 21 Feb 1998 22:47:33 -0500 (EST) Date: Sat, 21 Feb 1998 23:00:26 -0500 (EST) From: "M.C.Nelson" To: "Perry E. Metzger" cc: ipsec@tis.com Subject: Re: IPSEC WORKING GROUP LAST CALL In-Reply-To: <199802202027.PAA03149@jekyll.piermont.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Perry, Are we in the business of certifying or reviewing encryption algorithms? Or are we rather in the the business of providing mechanisms and interoperability for using them? Digressing only slightly, I recall that when I argued that trusted networks and security gateways are also poor security, it was said that this was a matter of policy and not the concern of standards. Regards, Mitch Nelson On Fri, 20 Feb 1998, Perry E. Metzger wrote: > > Someone writes: > > As Bob said, how to weaken the key is well known but I figured a CBC-MAC > > was well known and that apparently is not the case. We need documents > > describing things and there is no document describing "40 bit DES" > > I removed "someone"'s name because I don't want them to think the > following targets them specifically. It is directed not at particular > people but at the notion of ciphers with inadequate key lengths being > standardized, even in the "sheep's clothing" of variable length > ciphers that permit inadequate lengths. > > > > I don't understand why we wish to specify this at all. Even single DES > isn't secure any more. IBM, to their credit, doesn't call their 40 bit > DES based algorithm encryption -- they call it "commercial data > masking". > > You argue "hey, some of us have to make a living". Well, do it in a > less damaging way -- sell CD-ROM encyclopedias door to door or > something. If you insist on selling your customers junk -- and 40 bit > encryption is *junk* -- please do not ask the rest of us to endorse > your mechanism with the imprimateur of the IETF. The last thing I want > on earth is to see such a box sold with a brochure advertising its > compliance with RFC YYYY. Find a better way of marketing the > antifreeze you propose selling as booze to the third world > natives. You don't need an RFC number to do that. > > Oh, and if any vendor does go through the exercise of selling such a > thing, I suspect that software will be widely distributed on the net > to help even unskilled teenage crackers break the "encryption"[sic] > without having to know what they are doing. I suspect that because if > no one else does I'll write it and distribute it myself. A false sense > of security is worse than no security. > > The 40 bit "encryption" fraud must end. > > I've flamed on enough here already, and won't go any further with it > right now. I believe people can tell how strongly I feel about this. > > > > > Perry > From owner-ipsec Sun Feb 22 12:37:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA06346 for ipsec-outgoing; Sun, 22 Feb 1998 12:34:38 -0500 (EST) Message-Id: <199802221746.MAA00422@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: IPSEC Arch, ports, and tunnel mode SAs In-reply-to: Your message of "Fri, 20 Feb 1998 11:02:01 PST." <199802201902.LAA06253@spire.inside.sealabs.com> Date: Sun, 22 Feb 1998 12:46:05 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Chris" == Chris Boscolo writes: Chris> I have a question regarding the following change to the IPSEC Arch Chris> and a tunnel mode SA(s) set up between two SG's. Chris> Can I set up a tunnel mode SA between two SGs where one of the Chris> (outbound) selectors is a protocol port? If so, what do I do when Chris> I receive an IP fragment on my "non-IPSEC" side? I can't Chris> determine which tunnel to send through since I may not have the Chris> port info. My opinion is that you need to put non-initial fragments that match the your source/destination/protocol for your per-port SA into a queue. When the initial fragment arrives, you apply your transform to all fragments that have the same fragment ID, and if you notice that there are still more fragments to arrive, you note the fragment ID. Of course, you have to expire the queue, and the noted fragment id. This is classic stateful packet filtering. :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON Michael Richardson |Network and security consulting and contract programming Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNPBkXNiXVu0RiA21AQGrAgMAt3edxO8x5/l7zyNfDpbgwsofRkjR7LQF QvThXAJ813qDVO/TTzUkMDEIlFMhCABfEnbdgY3/LRaWWKrRvj1r/PENS00BV1c7 FJ26wlsmajf33LCqJmeFTLdPx+WvdSEM =sBSJ -----END PGP SIGNATURE----- From owner-ipsec Sun Feb 22 14:37:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA07091 for ipsec-outgoing; Sun, 22 Feb 1998 14:36:33 -0500 (EST) Message-ID: From: Greg Carter To: "'Theodore Y. Ts'o'" Cc: "'ipsec@tis.com'" Subject: RE: Regrouping for IPSEC WORKING GROUP LAST CALL Date: Sun, 22 Feb 1998 14:41:02 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk >---------- >From: Theodore Y. Ts'o[SMTP:tytso@MIT.EDU] >Sent: Friday, February 20, 1998 11:40 PM >To: Paul Lambert >Cc: ho@earth.hpc.org; ipsec@tis.com >Subject: Re: Regrouping for IPSEC WORKING GROUP LAST CALL > >Question to the working group: > >Should we remove the EC groups altogether and defer these issues to >IPSECOND? I think that would be best at this point for the reasons you stated. Bye. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com > > From owner-ipsec Sun Feb 22 14:48:46 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA07156 for ipsec-outgoing; Sun, 22 Feb 1998 14:48:33 -0500 (EST) Message-ID: From: Greg Carter To: "'Theodore Y. Ts'o'" Cc: "'IPSEC Mailing List'" , "'Dan Harkins'" , "'Roy Pereira'" Subject: RE: Certificate Requesting Date: Sun, 22 Feb 1998 14:51:49 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk >---------- >From: Theodore Y. Ts'o[SMTP:tytso@MIT.EDU] >Sent: Friday, February 20, 1998 11:53 PM >To: Greg Carter >Cc: 'IPSEC Mailing List'; 'Dan Harkins'; 'Roy Pereira' >Subject: Re: Certificate Requesting > > From: Greg Carter > Date: Fri, 20 Feb 1998 18:54:31 -0500 > >You may not like it, but the ISAKMP document is pretty clear on this >point: > >>The Certificate Request payloads MUST be accepted at any point >>during the exchange. The responder to the Certificate Request payload >>MUST send its immediate certificate, if certificates are supported, and >>SHOULD send as much of its certificate chain as possible. Thanks you just made my point. Like it says "any point during the exchange". I would not interpret this to mean that I can arbitrarily extend the exchange. There is plenty of opportunity to send the cert request during the defined exchange. Bye. Greg "Ralph Spice" Carter My cat's breath smells like cat food... greg.carter@entrust.com > From owner-ipsec Sun Feb 22 20:00:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA08597 for ipsec-outgoing; Sun, 22 Feb 1998 19:56:32 -0500 (EST) Message-Id: <3.0.3.32.19980222171305.0094a630@netcom.com> X-Sender: andrade@netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Sun, 22 Feb 1998 17:13:05 -0800 To: ipsec@tis.com From: Alex Alten Subject: Re: IPSEC WORKING GROUP LAST CALL In-Reply-To: References: <199802202027.PAA03149@jekyll.piermont.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk IPSEC WG, These are my main technical criticisms of the current set of IPSEC documents. 1. No data recovery of an encrypted IP datagram payload. Regardless of the merits of the design by not supporting this requirement it will probably kill IPSEC as a viable Internet standard. 2. Interoperability requirement not met. To ensure interoperability only one cryptographic mechanism should specified, and no others should be allowed. The current proposal allows an unlimited variety to be used, it seems primarily to allow the standard to scale cryptographic strength upwards. The requirement for DES-CBC to be always implemented cannot be met because objection #1 cannot be met with it. Probably RC4 with 40b keys will become the de facto interoperable mechanism (this has happened to SSL). 3. IPSEC does not properly fit with the IP routing model. It force fits the concept of a security session (SA) onto the IP datagram routing model. Certainy the concept of a user id does not fit the IP address model. The requirement that AH must know about the IP header structure breaks the general rule of protocol layering. 4. The design is too complex This design seems to have been driven primarily by the following. A. The desire to side-step export restrictions if necessary. This has caused two protocols, AH & ESP, to be specified. If #1 is properly satisfied then AH can be eliminated. B. The desire to use a proven cipher, i.e. DES. This decision has had a profound impact on the design. Because DES is slow, it has forced encryption & decryption to the edge hosts, requiring the SA construct to allow the packets to traverse intervening routers. This slowness also contributed to the decision to create AH. Choosing it has forced the need to handle pad & IV bytes within the IP payload, increasing protocol stack complexity when handling the mapping between clear and encrypted payloads. There are many excellent high performance ciphers available many of them do not require IV's or pad bytes. Many of these can be proved to be very secure, often in a manner obvious to most competent engineers. C. The desire to use a public key algorithm. This decision has also had an impact on the design. Because PK is so slow this has also contributed to the use of the SA construct instead of other methods which could more closely match how IP routing really works. It makes the management of trust more difficult, for example deleting untrustworthy hosts in a timely manner. D. The desire to distribute policy storage and enforcement. By distributing policy storage and enforcement across all the participating hosts and routers it has made it almost impossible to scale this design to very large numbers. 5. The design is incomplete A. Auditing needs to be completed. At the very least what policy events or queries must be specified that can trigger audits. Also for interoperability reasons, audit record formats should be specified. B. The trust model needs to be worked out more completely. How does the secure IP network first get established? How are nodes added or deleted? How does a corporate/organization need for controlling its own security get reconciled with the need for global Internet interoperability? - Alex -- Alex Alten Andrade@Netcom.Com P.O. Box 11406 Pleasanton, CA 94588 USA (510) 417-0159 From owner-ipsec Sun Feb 22 20:42:00 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA08874 for ipsec-outgoing; Sun, 22 Feb 1998 20:41:37 -0500 (EST) Message-Id: <3.0.3.32.19980223015228.0094f770@127.0.0.1> X-Sender: smb@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 23 Feb 1998 01:52:28 +0000 To: Alex Alten From: "Steven M. Bellovin" Subject: Re: IPSEC WORKING GROUP LAST CALL Cc: ipsec@tis.com In-Reply-To: <3.0.3.32.19980222171305.0094a630@netcom.com> References: <199802202027.PAA03149@jekyll.piermont.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 05:13 PM 2/22/98 -0800, Alex Alten wrote: >IPSEC WG, > >These are my main technical criticisms of the current set of IPSEC >documents. > >1. No data recovery of an encrypted IP datagram payload. > > Regardless of the merits of the design by not supporting this > requirement it will probably kill IPSEC as a viable Internet > standard. This is a feature, not a bug, by strong consensus of not just the working group, but also the entire security area. You are, of course, free to buy IPsec software from vendors who implement some form of key recovery, if that meets you operational or philosophical needs. We chose not to standardize something like that -- the IETF is an international group; in our judgment, the best technical results are obtained by not implementing such features, especially for communications protocols. See RFC 1984 for the IAB's and IESG's views on the subject. > > >2. Interoperability requirement not met. > > To ensure interoperability only one cryptographic mechanism should > specified, and no others should be allowed. The current proposal > allows an unlimited variety to be used, it seems primarily to allow > the standard to scale cryptographic strength upwards. The requirement > for DES-CBC to be always implemented cannot be met because objection > #1 cannot be met with it. Probably RC4 with 40b keys will become > the de facto interoperable mechanism (this has happened to SSL). To promote interoperability, a minimum set of algorithms was specified. Designing a mechanism that only permitted one to be used is very unsound, from a cryptographic perspective. You may well be correct that 40-bit keying will become the de facto standard. I hope not, especially in unconstrained environments (which, I should note, includes domestic traffic almost everywhere, and even international traffic if each party has purchased a legal version that implements strong cryptography -- the U.S. is not the only source for such things). > > >3. IPSEC does not properly fit with the IP routing model. > > It force fits the concept of a security session (SA) onto the IP > datagram routing model. Certainy the concept of a user id does > not fit the IP address model. The requirement that AH must know > about the IP header structure breaks the general rule of protocol > layering. The concept of an SA is necessary if one ever wishes to rekey. The desire for user-oriented keying, though somewhat controversial, is at least partially driven by some of the results in a paper of mine ("Problems with the IP Security Protocols"; see the bibliographies or check http://www.research.att.com/~smb/papers/badesp.{ps,pdf}). I think you're right about the AH design; others felt differently. I should note, btw, that using SAs closely mirrors SP3, which is at least 10 years old. As someone who had been thinking about IP encryption for quite a while before SP3 was published, I'll state that when I first saw SP3, I was extremely impressed by its elegance. > > >4. The design is too complex > > This design seems to have been driven primarily by the following. > > A. The desire to side-step export restrictions if necessary. Nonsense. That wasn't at all a consideration. > > This has caused two protocols, AH & ESP, to be specified. > If #1 is properly satisfied then AH can be eliminated. There are good reasons to do away with AH. This isn't one of them, or at least not one that was used in the working group. (The claim was made and refuted.) The two real reasons it was kept are to protect some portions of the IP header without using tunnel mode, and to permit context-free examination and monitoring of the port number fields. > > B. The desire to use a proven cipher, i.e. DES. > > This decision has had a profound impact on the design. Because > DES is slow, it has forced encryption & decryption to the edge > hosts, requiring the SA construct to allow the packets to traverse > intervening routers. This slowness also contributed to the > decision to create AH. Choosing it has forced the need to handle pad > & IV bytes within the IP payload, increasing protocol stack complexity > when handling the mapping between clear and encrypted payloads. There > are many excellent high performance ciphers available many of them do > not require IV's or pad bytes. Many of these can be proved to be very > secure, often in a manner obvious to most competent engineers. You seem to be suggesting the use of stream ciphers. Other than DES in certain modes, there are in reality very few stream ciphers that have been examined very much. There's only one popular one, RC4 -- and it's (arguably) proprietary. If you use RC4 with datagram-oriented encryption, you need a sequence number for each byte. Furthermore, you need to keep a fair amount of keying state, in case packets arrive out of order. For further difficulties with stream ciphers, especially if authentication is not used, see the paper cited above. The notion of router-to-router encryption was in SP3, too. While you're right that expense was one driving factor, speed of the encryption algorithm is a small part of that expense. There are very sound reasons for wanting to do encryption in hardware, and to put it in physically secure boxes. For that matter, policy enforcement -- that is, to what sites must one encrypt traffic -- is best put in places not accessible to typical users. The ability to trade cost for security was an explicit benefit of SP3; it's equally valuable in IPsec. As for ciphers being "proved to be very secure" -- that, in my opinion as a cryptographer, is largely beyond the state of the art. I welcome references to prove otherwise. And of course, using a "proven cipher" is generally considered a feature, not a bug. > > C. The desire to use a public key algorithm. > > This decision has also had an impact on the design. Because PK is > so slow this has also contributed to the use of the SA construct > instead of other methods which could more closely match how > IP routing really works. It makes the management of trust more > difficult, for example deleting untrustworthy hosts in a timely > manner. Use of a public key algorithm is an engineering necessity, not a desire. You receive mail on netcom -- what authority would both my employer and netcom trust to hold our *private* keys, which is the other alternative? For a discussion on why public key algorithms are preferable in such situations, see Whit Diffie's ten year retropsective on public key cryptography. SKIP -- a design rejected for other reasons -- more closely matches the IP model. But it also uses public key algorithms. > > D. The desire to distribute policy storage and enforcement. > > By distributing policy storage and enforcement across all the > participating hosts and routers it has made it almost impossible > to scale this design to very large numbers. I'm not entirely certain what you mean here. But why shouldn't policy be distributed, in a network as heterogeneous as the Internet? > > >5. The design is incomplete > > A. Auditing needs to be completed. At the very least what policy events > or queries must be specified that can trigger audits. Also for > interoperability reasons, audit record formats should be specified. Since many systems don't have audit abilities, it can't be specified. Many auditable events are. There may or may not be a need for an interoperable audit format; if there is, it's well beyond the scope of this group. > > B. The trust model needs to be worked out more completely. How does the > secure IP network first get established? How are nodes added or > deleted? How does a corporate/organization need for controlling > its own security get reconciled with the need for global > Internet interoperability? This is an issue. It's largely been deferred to the vpn and/or IPsecond working groups. For now, such configuration is largely static, and set by individual sites. Briefly, each encryption endpoint has a list of IP addresses to which traffic must be encrypted; for all others, either plaintext is used, or the site responds to IPsec negotiations initiated by its peers. From owner-ipsec Sun Feb 22 20:48:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA08907 for ipsec-outgoing; Sun, 22 Feb 1998 20:48:35 -0500 (EST) To: ipsec@tis.com Subject: Re: IPSEC WORKING GROUP LAST CALL References: <199802202027.PAA03149@jekyll.piermont.com> <3.0.3.32.19980222171305.0094a630@netcom.com> From: EKR Date: 22 Feb 1998 18:02:53 -0800 In-Reply-To: Alex Alten's message of Sun, 22 Feb 1998 17:13:05 -0800 Message-Id: <3sopbhycy.fsf@kmac.terisa.com> Lines: 103 X-Mailer: Gnus v5.4.37/XEmacs 19.15 Sender: owner-ipsec@ex.tis.com Precedence: bulk It's a bit late in the game for this kind of criticism. However, some of your comments are so basically wrong, that I'll take the time to correct some of your misapprehensions. Alex Alten writes: > IPSEC WG, > > These are my main technical criticisms of the current set of IPSEC > documents. > > 1. No data recovery of an encrypted IP datagram payload. > > Regardless of the merits of the design by not supporting this > requirement it will probably kill IPSEC as a viable Internet > standard. I'm not sure what this is supposed to mean. > 2. Interoperability requirement not met. > > To ensure interoperability only one cryptographic mechanism should > specified, and no others should be allowed. The current proposal > allows an unlimited variety to be used, it seems primarily to allow > the standard to scale cryptographic strength upwards. I disagree with the position that only one cryptographic algorithm should be available. Different systems have different security requirements. However, that said, the specs do specify required algorithms, precisely to facilitate interoperability. > The requirement > for DES-CBC to be always implemented cannot be met because objection > #1 cannot be met with it. Probably RC4 with 40b keys will become > the de facto interoperable mechanism (this has happened to SSL). You're really going to need to explain what objection (1) means here, since I don't see what (good) properties RC4-40 has that DES-CBC doesn't. It almost seems like when you say Data Recovery, what you want is an encryption algorithm that doesn't provide confidentiality against a dedicated attacker. > 3. IPSEC does not properly fit with the IP routing model. > > It force fits the concept of a security session (SA) onto the IP > datagram routing model. Certainy the concept of a user id does > not fit the IP address model. Yep. This is a problem. Unfortunately, endpoint naming is always a problem. > The requirement that AH must know > about the IP header structure breaks the general rule of protocol > layering. I agree, this is bad. Unfortunately, it's also necessary if you want to have the features that AH provides, namely only one set of headers for the datagram. This has some advantages, including a slightly smaller packet size. > 4. The design is too complex > > This design seems to have been driven primarily by the following. > > A. The desire to side-step export restrictions if necessary. > > This has caused two protocols, AH & ESP, to be specified. > If #1 is properly satisfied then AH can be eliminated. This misunderstands the history of IPSEC. AH and ESP exist because they provide subtly different security services. > B. The desire to use a proven cipher, i.e. DES. > > This decision has had a profound impact on the design. Because > DES is slow, it has forced encryption & decryption to the edge > hosts, This is incredibly confused. The reason for having cryptographic processing is to provide end-to-end security without trusting the routers in between. For the motivation behind this, I suggest you read "Security Mechanisms in High Level Network Protocols" by Voydock and Kent, and "End To End Arguments in Systems Design" by Clark et. al. > There > are many excellent high performance ciphers available many of them do > not require IV's or pad bytes. Many of these can be proved to be very > secure, often in a manner obvious to most competent engineers. This is simply false. There are in fact no cipher systems which can be proven to be secure (with the exception of the One Time Pad). That said, there are very few publicly available ciphers with any substantial body of analysis behind them, and all of them are block ciphers. Of these ciphers, DES has by far the most analysis. Moreover, IVs and pad bytes simply don't add that much complexity to the implementation. > C. The desire to use a public key algorithm. > > This decision has also had an impact on the design. Because PK is > so slow this has also contributed to the use of the SA construct > instead of other methods which could more closely match how > IP routing really works. It makes the management of trust more > difficult, for example deleting untrustworthy hosts in a timely > manner. Do you have another suggestion besides using Public Key? -Ekr -- [Eric Rescorla Terisa Systems, Inc.] "Put it in the top slot." From owner-ipsec Sun Feb 22 21:11:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA09043 for ipsec-outgoing; Sun, 22 Feb 1998 21:10:35 -0500 (EST) Message-Id: <199802230223.LAA00749@baba-yaga.rinfo.sei.co.jp> X-Authentication-Warning: baba-yaga.rinfo.sei.co.jp: localhost.rinfo.sei.co.jp [127.0.0.1] didn't use HELO protocol To: lmccarth@cs.umass.edu Cc: ipsec@tis.com Subject: Re: key derivation for ESP Authentication Algorithm In-Reply-To: Your message of "Sat, 21 Feb 1998 19:42:53 -0500" References: <34EF748D.6956@cs.umass.edu> X-Mailer: Mew version 1.70 on Emacs 19.28.1 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 23 Feb 1998 11:23:43 +0900 From: Norio Korekawa Sender: owner-ipsec@ex.tis.com Precedence: bulk > > I have a question about derivation of Phase 2 keying material and > > I would greatly appreciate receiving an answer from someone of this > > group. > > I haven't seen any replies to this, so I'll take a stab at it. Thanks for your prompt answer. But please let me ask you once again. > > So the difference between the two(Encryption and Authentication) keys > > is only its length, I think. Am I right? > > No, the keying material for encryption differs entirely from > the keying material for authentication. This happens because the > "protocol" value used to derive KEYMAT is a transform-specific value. > The encryption transform is associated with one value for "protocol" > and the authentication transform is associated with some other value > for "protocol". > > Per IKE 5.5, pg.18: > > In either case, "protocol" and "SPI" are from the ISAKMP > Proposal Payload that contained the negotiated Transform. > > Hope this helps I should have written "(ESP Encryption and ESP Authentication)", instead of "(Encryption and Authentication)". In this case, only ESP is employed, and I think "protocol" is PROTO_IPSEC_ESP. That's why, I think that a key for ESP Encryption and a key for ESP Authentication are derived from the same KEYMAT, because the same "protocol" value(PROTO_IPSEC_ESP) and the same SPI are used for the computation. Hope to hear your comments again. Thanks, Norio Korekawa From owner-ipsec Sun Feb 22 21:17:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA09115 for ipsec-outgoing; Sun, 22 Feb 1998 21:17:35 -0500 (EST) Date: Sun, 22 Feb 1998 21:28:35 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199802230228.VAA17540@earth.hpc.org> To: tytso@MIT.EDU Cc: plambert@certicom.com, ipsec@tis.com In-reply-to: Yourmessage <199802210440.XAA04852@dcl.MIT.EDU> Subject: Re: Regrouping for IPSEC WORKING GROUP LAST CALL Sender: owner-ipsec@ex.tis.com Precedence: bulk > Should we remove the EC groups altogether and defer these issues to > IPSECOND? There's a scene in Music Man where everyone goes around singing "trouble, trouble, trouble, trouble." Meant to show a kind of small-town attitude, as I remember. Rabelais, Bal-zac. EC. The groups are optional. The NEWGROUP mode has always been there exactly for the purpose of accommodating the expected drift of the opinio-of-the-art. And there will never be a last call that doesn't bring out controversy. But no Y coordinate ... :-) ref. obs. Hilarie From owner-ipsec Sun Feb 22 21:23:46 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA09177 for ipsec-outgoing; Sun, 22 Feb 1998 21:23:36 -0500 (EST) Date: Sun, 22 Feb 1998 21:36:11 -0500 (EST) Message-Id: <199802230236.VAA25245@carp.morningstar.com> From: Ben Rogers To: Alex Alten Cc: ipsec@tis.com Subject: Re: IPSEC WORKING GROUP LAST CALL In-Reply-To: <3.0.3.32.19980222171305.0094a630@netcom.com> References: <199802202027.PAA03149@jekyll.piermont.com> <3.0.3.32.19980222171305.0094a630@netcom.com> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Alex Alten writes: > 4. The design is too complex > B. The desire to use a proven cipher, i.e. DES. > > This decision has had a profound impact on the design. Because > DES is slow, it has forced encryption & decryption to the edge > hosts, requiring the SA construct to allow the packets to traverse > intervening routers. I'm not certain how valid a point this really is. If we want routers (security gateways) to protect traffic for the hosts behind them, then we need to take the additional security processing into account. It doesn't make much sense to design a security protocol around existing hardware because that hardware was rarely designed with security in mind and doesn't usually have the extra horsepower needed to handle _any_ sort of crypto processing. The core IPsec protocol (AH and ESP) was closely monitored by a number of router vendors, and has been (IMHO) optimized for speed as much as is possible given certain unavoidable constrants. Note that there is nothing inherent in ESP which prevents vendors from utilizing faster encryption algorithms. > C. The desire to use a public key algorithm. > > This decision has also had an impact on the design. Because PK is > so slow this has also contributed to the use of the SA construct > instead of other methods which could more closely match how > IP routing really works. It makes the management of trust more > difficult, for example deleting untrustworthy hosts in a timely > manner. Note that this can be sidestepped by using pre-shared keys in ISAKMP. Depending on your security needs, this may be an entirely adequate solution, and would not carry the extra baggage of the PK computations and the Certificate management. However, for many of the proposed uses of ISAKMP, keeping a database of pre-shared keys is simply out of the question, as this database will be much too large. > D. The desire to distribute policy storage and enforcement. > > By distributing policy storage and enforcement across all the > participating hosts and routers it has made it almost impossible > to scale this design to very large numbers. I guess I don't see this as a real problem, given that it would be a much more messy problem to try and figure out how to securely bootstrap a system from a policy server. There is nothing inherent in the protocol which prevents such a server from being used, however, and you will probably find that the support of such a concept is not orthogonal to IPsec, but will probably mesh nicely. ben From owner-ipsec Sun Feb 22 21:50:49 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA09304 for ipsec-outgoing; Sun, 22 Feb 1998 21:50:35 -0500 (EST) Message-Id: <199802230303.WAA04680@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: IPSEC WORKING GROUP LAST CALL In-reply-to: Your message of "Sun, 22 Feb 1998 21:36:11 EST." <199802230236.VAA25245@carp.morningstar.com> Date: Sun, 22 Feb 1998 22:02:55 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Ben" == Ben Rogers writes: >> This decision has also had an impact on the design. Because PK is so >> slow this has also contributed to the use of the SA construct instead >> of other methods which could more closely match how IP routing really >> works. It makes the management of trust more difficult, for example >> deleting untrustworthy hosts in a timely manner. Ben> Note that this can be sidestepped by using pre-shared keys in Ben> ISAKMP. Depending on your security needs, this may be an entirely Or, by using other means of getting a symmetric key to each end, such as by using a Kerberos 4, 5 or NT5.0 KDC. :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON Michael Richardson |Network and security consulting and contract programming Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. From owner-ipsec Sun Feb 22 22:07:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA09446 for ipsec-outgoing; Sun, 22 Feb 1998 22:07:35 -0500 (EST) Message-ID: <34F0EAE4.4DAA@cs.umass.edu> Date: Sun, 22 Feb 1998 22:20:04 -0500 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V4.0 alpha) MIME-Version: 1.0 To: Norio Korekawa CC: IP Security List Subject: Re: key derivation for ESP Authentication Algorithm References: <34EF748D.6956@cs.umass.edu> <199802230223.LAA00749@baba-yaga.rinfo.sei.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Norio Korekawa writes: >>> I should have written "(ESP Encryption and ESP Authentication)", >>> instead of "(Encryption and Authentication)". In this case, >>> only ESP is employed, and I think "protocol" is PROTO_IPSEC_ESP. >>> That's why, I think that a key for ESP Encryption and a key for >>> ESP Authentication are derived from the same KEYMAT, because >>> the same "protocol" value(PROTO_IPSEC_ESP) and the same SPI >>> are used for the computation. >>> >>> Hope to hear your comments again. Whoops, thanks for clarifying the question. I was hallucinating "transform-id" while writing "protocol-id". Here's an answer that I think will be more informative: The Architecture document (previous rev., , Sec. 4.6.2) specifies the procedure for slicing KEYMAT into multiple keys needed for a single SA: > When an automated SA/key management protocol is employed, the output > from this protocol may be used to generate multiple keys, e.g., for a > single ESP SA. This may arise because: > > o the encryption algorithm uses multiple keys (e.g., triple DES) > o the authentication algorithm uses multiple keys > o both encryption and authentication algorithms are employed > > The Key Management System may provide a separate string of bits for > each key or it may generate one string of bits from which all of them > are extracted. If a single string of bits is provided, care needs to > be taken to ensure that the parts of the system that map the string > of bits to the required keys do so in the same fashion at both ends > of the SA. To ensure that the IPsec implementations at each end of > the SA use the same bits for the same keys, and irrespective of which > part of the system divides the string of bits into individual keys, > the encryption key(s) MUST be taken from the first (left-most, high- > order) bits and the authentication key(s) MUST be taken from the > remaining bits. The number of bits for each key is defined in the > relevant algorithm specification RFC. In the case of multiple > encryption keys or multiple authentication keys, the specification > for the algorithm must specify the order in which they are to be > selected from a single string of bits provided to the algorithm. -- Lewis http://www.cs.umass.edu/~lmccarth/ "In our opinion provable security is nothing more than a phantom, similar to the perpetuum mobile in thermodynamics." -- Joan Daemen, 1995 From owner-ipsec Sun Feb 22 22:27:11 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA09594 for ipsec-outgoing; Sun, 22 Feb 1998 22:26:35 -0500 (EST) Message-Id: <199802230338.WAA09145@jekyll.piermont.com> To: Alex Alten cc: ipsec@tis.com Subject: Re: IPSEC WORKING GROUP LAST CALL In-reply-to: Your message of "Sun, 22 Feb 1998 17:13:05 PST." <3.0.3.32.19980222171305.0094a630@netcom.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Sun, 22 Feb 1998 22:38:39 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Alex Alten writes: > IPSEC WG, > > These are my main technical criticisms of the current set of IPSEC > documents. > > 1. No data recovery of an encrypted IP datagram payload. > > Regardless of the merits of the design by not supporting this > requirement it will probably kill IPSEC as a viable Internet > standard. "Data Recovery" would obviate the ability of IPSec to function as a security standard, as if you can recover the data without recourse to the cryptographic keys, you have not provided security. > 3. IPSEC does not properly fit with the IP routing model. > > It force fits the concept of a security session (SA) onto the IP > datagram routing model. Huh? Have you read the documents? > 4. The design is too complex Can you describe a simpler design than encapsulation? .pm From owner-ipsec Sun Feb 22 22:33:44 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA09662 for ipsec-outgoing; Sun, 22 Feb 1998 22:33:35 -0500 (EST) Date: Sun, 22 Feb 1998 22:46:22 -0500 (EST) From: "M.C.Nelson" To: Alex Alten cc: ipsec@tis.com Subject: Re: IPSEC WORKING GROUP LAST CALL In-Reply-To: <3.0.3.32.19980222171305.0094a630@netcom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Regarding the first point below (data recovery), on a scale of 1-5 for strongly agree-strongly disagree, I think I would choose 10. Data recovery is an application issue. IP is (prior to IPSEC) simply an unreliable connectionless datagram service. The two are completely unrelated by definition. Unless of course, by data recovery, the contributor means key escrow, or in plain language - sanctioned eavesdropping, in which case my response, on a scale of 1-5, is 10,000. Moreover, the argument would seem to actually go to the reverse. If IPSEC were to mandate data recovery, or key escrow, then the grass roots will simply use something else, or use application layer encryption to render the "data recovery" mechanism useless. Regards, Mitch Nelson On Sun, 22 Feb 1998, Alex Alten wrote: > IPSEC WG, > > These are my main technical criticisms of the current set of IPSEC > documents. > > 1. No data recovery of an encrypted IP datagram payload. > > Regardless of the merits of the design by not supporting this > requirement it will probably kill IPSEC as a viable Internet > standard. > > > 2. Interoperability requirement not met. > > To ensure interoperability only one cryptographic mechanism should > specified, and no others should be allowed. The current proposal > allows an unlimited variety to be used, it seems primarily to allow > the standard to scale cryptographic strength upwards. The requirement > for DES-CBC to be always implemented cannot be met because objection > #1 cannot be met with it. Probably RC4 with 40b keys will become > the de facto interoperable mechanism (this has happened to SSL). > > > 3. IPSEC does not properly fit with the IP routing model. > > It force fits the concept of a security session (SA) onto the IP > datagram routing model. Certainy the concept of a user id does > not fit the IP address model. The requirement that AH must know > about the IP header structure breaks the general rule of protocol > layering. > > > 4. The design is too complex > > This design seems to have been driven primarily by the following. > > A. The desire to side-step export restrictions if necessary. > > This has caused two protocols, AH & ESP, to be specified. > If #1 is properly satisfied then AH can be eliminated. > > B. The desire to use a proven cipher, i.e. DES. > > This decision has had a profound impact on the design. Because > DES is slow, it has forced encryption & decryption to the edge > hosts, requiring the SA construct to allow the packets to traverse > intervening routers. This slowness also contributed to the > decision to create AH. Choosing it has forced the need to handle pad > & IV bytes within the IP payload, increasing protocol stack complexity > when handling the mapping between clear and encrypted payloads. There > are many excellent high performance ciphers available many of them do > not require IV's or pad bytes. Many of these can be proved to be very > secure, often in a manner obvious to most competent engineers. > > C. The desire to use a public key algorithm. > > This decision has also had an impact on the design. Because PK is > so slow this has also contributed to the use of the SA construct > instead of other methods which could more closely match how > IP routing really works. It makes the management of trust more > difficult, for example deleting untrustworthy hosts in a timely > manner. > > D. The desire to distribute policy storage and enforcement. > > By distributing policy storage and enforcement across all the > participating hosts and routers it has made it almost impossible > to scale this design to very large numbers. > > > 5. The design is incomplete > > A. Auditing needs to be completed. At the very least what policy events > or queries must be specified that can trigger audits. Also for > interoperability reasons, audit record formats should be specified. > > B. The trust model needs to be worked out more completely. How does the > secure IP network first get established? How are nodes added or > deleted? How does a corporate/organization need for controlling > its own security get reconciled with the need for global > Internet interoperability? > > - Alex > -- > Alex Alten > Andrade@Netcom.Com > P.O. Box 11406 > Pleasanton, CA 94588 USA > (510) 417-0159 > > From owner-ipsec Sun Feb 22 22:38:49 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA09689 for ipsec-outgoing; Sun, 22 Feb 1998 22:38:37 -0500 (EST) Message-Id: <199802230350.WAA04848@istari.sandelman.ottawa.on.ca> To: wdm@epoch.ncsc.mil (W. Douglas Maughan) CC: ipsec@tis.com Subject: Re: new draft-ietf-ipsec-isakmp? In-reply-to: Your message of "Thu, 19 Feb 1998 12:36:17 EST." <9802191736.AA01808@dolphin.ncsc.mil> Date: Sun, 22 Feb 1998 22:50:02 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "W" == W Douglas Maughan writes: W> There was considerable discussion about the vendor ID payload. Is W> there consensus that it should be included in the next ISAKMP draft? W> If so, I'll use the text sent to IPSEC list by Michael Richardson on W> 13 Oct 1997. Thank you! That message did not make it to the list... (At least, it isn't in the archives.... ) Here is my original text. If anyone wants me to post the discussion that ensued, I will do that, assuming that the parties involved don't object. Word smithing welcome. To: Daniel Harkins , wdm@epoch.ncsc.mil (W. Douglas Maughan) CC: ylo@ssh.fi, piper@cisco.com, mjs@terisa.com, mss@tycho.ncsc.mil, tmo@ssh.fi, kivinen@ssh.fi Subject: Re: vendor id in isakmp In-reply-to: Your message of "Sun, 12 Oct 1997 14:37:42 PDT." <199710122137.OAA24282@dharkins-ss20> Date: Mon, 13 Oct 1997 15:47:05 -0400 From: "Michael C. Richardson" - -----BEGIN PGP SIGNED MESSAGE----- My text: (the MD5 hash was produced with MD5File from the NetBSD-current libc. I expect that it is compliant, but I haven't checked it against our IPsec engine's version) 3.16 Vendor ID payload The Vendor ID Payload contains a vendor defined constant. The constant is used by vendors to identify and recognize remote instances of their implementations. Figure 17 shows the format of the Vendor ID Payload. The Vendor ID should be sent in the phase I negotiation. Reception of a familiar Vendor ID payload in the phase I negotiation allows an implementation to make use of payload numbers 128-255 for vendor specific extensions during phase II. If a private payload was sent without prior agreement to send it, a compliant implementation may reject a proposal with a notify message of type INVALID-PAYLOAD-TYPE. This mechanism allows a vendor to experiment with new features while maintaining backwards compatibility. This is not a general extension facility: widely used extensions SHOULD be documented and standardized in a future version of ISAKMP. The vendor defined constant MUST be unique. Vendors SHOULD generate their vendor id by taking a plain (non-keyed) hash of a string containing the product name, and the version of the product. For instance: "Example Company IPsec. Version 97.1" (not including the quotes) has MD5 hash: 48544f9b1fe662af98b9b39e50c01a5a, and the vendor id could be taken to the first 96 bits: 48544f9b1fe662af98b9b39. The vendor ID is opaque, so the choice of hash and text to hash is left to the vendor to decide. Vendors SHOULD change their vendor ID for major revisions of their product as this allows them to work around problems in previous versions of their product. A hash is used instead of a vendor registry to avoid local cryptographic policy problems with having a list of "approved" products, and to allow classified products to avoid having to appear on any list. The definition of "familiar" is left to implementations to determine. Some vendors may wish to implement another vendor's extension prior to standardization. This practice SHOULD not be widespread: vendors should work towards standardization instead. The Vendor ID payload is not an announcement from the sender that it will send private payload types. A vendor sending the vendor ID MUST not make any assumptions about private payloads that it may send unless a Vendor ID is received as well. Multiple Vendor ID payloads MAY be sent. An implementation is NOT REQUIRED to understand any Vendor ID payloads. An implementation is NOT REQUIRED to send any Vendor ID payload at all. If Vendor ID(s) are sent, they MUST be sent during the Phase I exchange. [comment please! MCR] 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ! VENDOR ID: 96 bits ! ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 17: Vendor ID payload The Vendor ID Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. This is always 16 bytes. o Vendor ID (12 octets) - hash of vendor string plus version. The payload type for the Vendor ID Payload is twelve (13). - -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNEJ6sKZpLyXYhL+BAQGciwL+PXyLWZJPWlrH0d/e6PV/WClq919DOQ07 Jrzcp+HAoonlBzChSzhQzZhe9bBfADHGmSKtyURYWoTAhh2yODdql6sYi+ffFIJU WOyMJTmgHFudS0yPCYgZOcCnBVPl7hYE =9ZDn - -----END PGP SIGNATURE----- :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON Michael Richardson |Network and security consulting and contract programming Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNPDx6NiXVu0RiA21AQFjZAL/bbwdLvPlJdD+61YxYxXa6AeihHslwyS2 NvaHyx0dlbMvWXJ+jYCeqbvL+WHkrEI+2K5vgaqxT4Tq7wKUL6uVbNEvCT99L57g Dqw00jYOe7KRMHEURfGWTnR2iuiz+kWm =EDIg -----END PGP SIGNATURE----- From owner-ipsec Sun Feb 22 22:46:51 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA09769 for ipsec-outgoing; Sun, 22 Feb 1998 22:46:36 -0500 (EST) Date: Sun, 22 Feb 1998 22:59:01 -0500 (EST) From: "M.C.Nelson" To: Alex Alten cc: ipsec@tis.com Subject: Re: IPSEC WORKING GROUP LAST CALL In-Reply-To: <3.0.3.32.19980222171305.0094a630@netcom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk P.S. Regarding the comments in 3 - "breaks the layering model", and in 4 - "too complex", and in 5 - "incomplete" (as related to deployment) is there perhaps a ring of truth here? On Sun, 22 Feb 1998, Alex Alten wrote: > IPSEC WG, > > These are my main technical criticisms of the current set of IPSEC > documents. > > 1. No data recovery of an encrypted IP datagram payload. > > Regardless of the merits of the design by not supporting this > requirement it will probably kill IPSEC as a viable Internet > standard. > > > 2. Interoperability requirement not met. > > To ensure interoperability only one cryptographic mechanism should > specified, and no others should be allowed. The current proposal > allows an unlimited variety to be used, it seems primarily to allow > the standard to scale cryptographic strength upwards. The requirement > for DES-CBC to be always implemented cannot be met because objection > #1 cannot be met with it. Probably RC4 with 40b keys will become > the de facto interoperable mechanism (this has happened to SSL). > > > 3. IPSEC does not properly fit with the IP routing model. > > It force fits the concept of a security session (SA) onto the IP > datagram routing model. Certainy the concept of a user id does > not fit the IP address model. The requirement that AH must know > about the IP header structure breaks the general rule of protocol > layering. > > > 4. The design is too complex > > This design seems to have been driven primarily by the following. > > A. The desire to side-step export restrictions if necessary. > > This has caused two protocols, AH & ESP, to be specified. > If #1 is properly satisfied then AH can be eliminated. > > B. The desire to use a proven cipher, i.e. DES. > > This decision has had a profound impact on the design. Because > DES is slow, it has forced encryption & decryption to the edge > hosts, requiring the SA construct to allow the packets to traverse > intervening routers. This slowness also contributed to the > decision to create AH. Choosing it has forced the need to handle pad > & IV bytes within the IP payload, increasing protocol stack complexity > when handling the mapping between clear and encrypted payloads. There > are many excellent high performance ciphers available many of them do > not require IV's or pad bytes. Many of these can be proved to be very > secure, often in a manner obvious to most competent engineers. > > C. The desire to use a public key algorithm. > > This decision has also had an impact on the design. Because PK is > so slow this has also contributed to the use of the SA construct > instead of other methods which could more closely match how > IP routing really works. It makes the management of trust more > difficult, for example deleting untrustworthy hosts in a timely > manner. > > D. The desire to distribute policy storage and enforcement. > > By distributing policy storage and enforcement across all the > participating hosts and routers it has made it almost impossible > to scale this design to very large numbers. > > > 5. The design is incomplete > > A. Auditing needs to be completed. At the very least what policy events > or queries must be specified that can trigger audits. Also for > interoperability reasons, audit record formats should be specified. > > B. The trust model needs to be worked out more completely. How does the > secure IP network first get established? How are nodes added or > deleted? How does a corporate/organization need for controlling > its own security get reconciled with the need for global > Internet interoperability? > > - Alex > -- > Alex Alten > Andrade@Netcom.Com > P.O. Box 11406 > Pleasanton, CA 94588 USA > (510) 417-0159 > > From owner-ipsec Mon Feb 23 00:15:15 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA10288 for ipsec-outgoing; Mon, 23 Feb 1998 00:13:35 -0500 (EST) Message-Id: <199802230524.AAA21018@relay.hq.tis.com> To: "Michael C. Richardson" cc: ipsec@tis.com Subject: Re: IPSEC WORKING GROUP LAST CALL In-reply-to: Your message of "Sun, 22 Feb 1998 22:02:55 EST." <199802230303.WAA04680@istari.sandelman.ottawa.on.ca> Date: Sun, 22 Feb 1998 21:25:39 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk > Or, by using other means of getting a symmetric key to each end, such >as by using a Kerberos 4, 5 or NT5.0 KDC. True enough. See 'draft-ietf-ipsec-gssapi-auth-01.txt' for a description of how one might use Kerberos within the IKE framework. Derrell From owner-ipsec Mon Feb 23 02:14:32 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA10992 for ipsec-outgoing; Mon, 23 Feb 1998 02:11:38 -0500 (EST) Message-Id: <199802230723.XAA05381@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: "Michael C. Richardson" Cc: wdm@epoch.ncsc.mil (W. Douglas Maughan), ipsec@tis.com Subject: Re: new draft-ietf-ipsec-isakmp? In-Reply-To: Your message of "Sun, 22 Feb 1998 22:50:02 EST." <199802230350.WAA04848@istari.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 22 Feb 1998 23:23:47 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Michael, > Here is my original text. If anyone wants me to post the discussion > that ensued, I will do that, assuming that the parties involved don't > object. Word smithing welcome. I don't object if you feel it is necessary. > To: Daniel Harkins , > wdm@epoch.ncsc.mil (W. Douglas Maughan) > CC: ylo@ssh.fi, piper@cisco.com, mjs@terisa.com, mss@tycho.ncsc.mil, > tmo@ssh.fi, kivinen@ssh.fi > Subject: Re: vendor id in isakmp > In-reply-to: Your message of "Sun, 12 Oct 1997 14:37:42 PDT." > <199710122137.OAA24282@dharkins-ss20> > Date: Mon, 13 Oct 1997 15:47:05 -0400 > From: "Michael C. Richardson" [snip] > If Vendor ID(s) are sent, they MUST be sent during the Phase I > exchange. [comment please! MCR] > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Next Payload ! RESERVED ! Payload Length ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! ! > ! VENDOR ID: 96 bits ! > ! ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Does this have to be 96bits? Since a payload length is included can't this just be an opaque blob whose length is determined by the payload length field? Dan. From owner-ipsec Mon Feb 23 08:07:49 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA13328 for ipsec-outgoing; Mon, 23 Feb 1998 08:03:36 -0500 (EST) eturn-Path: Message-Id: <199802202033.PAA14586@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-auth-hmac-sha196-03.txt Date: Fri, 20 Feb 1998 15:33:51 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Use of HMAC-SHA-1-96 within ESP and AH Author(s) : C. Madson, R. Glenn Filename : draft-ietf-ipsec-auth-hmac-sha196-03.txt Pages : 6 Date : 18-Feb-98 This draft describes the use of the HMAC algorithm [RFC-2104] in conjunction with the SHA-1 algorithm [FIPS-180-1] as an authentication mechanism within the revised IPSEC Encapsulating Security Payload [ESP] and the revised IPSEC Authentication Header [AH]. HMAC with SHA-1 provides data origin authentication and integrity protection. Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a]. 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-auth-hmac-sha196-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-sha196-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-auth-hmac-sha196-03.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: <19980218151527.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-auth-hmac-sha196-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-auth-hmac-sha196-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980218151527.I-D@ietf.org> --OtherAccess-- --NextPart-- -- John Kelley johnk@tis.com Director, Systems Administration Trusted Information Systems, Inc. (A NASDAQ company: "TISX") http://www.tis.com From owner-ipsec Mon Feb 23 09:25:23 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA14689 for ipsec-outgoing; Mon, 23 Feb 1998 09:23:38 -0500 (EST) Message-ID: <6B5344C210C7D011835C0000F8012766BE501C@exna01.securitydynamics.com> From: "Linn, John" To: Paul Lambert , "'Ted Ts'o'" Cc: ho@earth.hpc.org, ipsec@tis.com Subject: RE: Regrouping for IPSEC WORKING GROUP LAST CALL Date: Mon, 23 Feb 1998 09:37:52 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Ted's assessment makes sense to me. At a finer level of detail, if EC group definitions remain at this stage, I believe that current text in isakmp-oakley-06 appears self-inconsistent about the level of the groups' optionality and probably needs some adjustment or clarification: section 4 states generally that "ECP and EC2N groups MAY be supported", but sections 6.3 and 6.4 describe the particular cited groups as SHOULDs. --jl > ---------- > From: Theodore Y. Ts'o[SMTP:tytso@MIT.EDU] > Sent: Friday, February 20, 1998 11:40 PM > To: Paul Lambert > Cc: ho@earth.hpc.org; ipsec@tis.com > Subject: Re: Regrouping for IPSEC WORKING GROUP LAST CALL > > Question to the working group: > > Should we remove the EC groups altogether and defer these issues to > IPSECOND? > > I am certainly not an expert in this field, but my understanding is > that > each EC group can have radically different properties of speed, > security, and patent encumberances (if you want to do computations in > that group efficiently). Hence, it is not as simple as picking some > an > RSA key length, where a bigger RSA key is better than a shorter length > RSA key. > > It's not clear to we that we can do justice to all of these complex > and > inter-related issues during the working group last call. Sounds to me > like we might want to defer this issue. What do others think? > > - Ted > From owner-ipsec Mon Feb 23 12:44:19 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA16045 for ipsec-outgoing; Mon, 23 Feb 1998 12:38:42 -0500 (EST) Date: Mon, 23 Feb 1998 12:51:13 -0500 Message-Id: <199802231751.MAA05467@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Greg Carter Cc: "'Theodore Y. Ts'o'" , "'IPSEC Mailing List'" , "'Dan Harkins'" , "'Roy Pereira'" In-Reply-To: Greg Carter's message of Sun, 22 Feb 1998 14:51:49 -0500, Subject: Re: Certificate Requesting Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk From: Greg Carter Date: Sun, 22 Feb 1998 14:51:49 -0500 Thanks you just made my point. Like it says "any point during the exchange". I would not interpret this to mean that I can arbitrarily extend the exchange. There is plenty of opportunity to send the cert request during the defined exchange. The text I quoted is from the ISAKMP document; within the context of ISAKMP, there can be an arbitrary number of round-trips. IKE rides on top of ISAKMP, and defines three round trips for main mode, and one and a half round trips for quick mode. However, IKE doesn't restrict the number of round-trips to those it defines. Note that the ISAKMP spec also states: The responder to the Certificate Request payload MUST send its immediate certificate, if certificates are supported, So your interpretation would require violating this part of the ISAMP spec. - Ted From owner-ipsec Mon Feb 23 15:29:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA17263 for ipsec-outgoing; Mon, 23 Feb 1998 15:27:47 -0500 (EST) Message-ID: From: Roy Pereira To: "IPSEC Mailing List (E-mail)" , "VPN Mailing List (E-mail)" Subject: IPSec Policy Model draft Date: Mon, 23 Feb 1998 14:44:19 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Internet Engineering Task Force R. Pereira, TimeStep Corp. IP Security Working Group P. Bhattacharya, IBM Corp. Internet Draft Expires in six months February 19, 1998 IPSec Policy Data Model Status of this Memo This document is a submission to the IETF Internet Protocol Security (IPSECond) Working Group. Comments are solicited and should be addressed to the working group mailing list (ipsec@tis.com) or to the editor. 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 draft documents are 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). Distribution of this memo is unlimited. Abstract This document presents a data model for IPSec policy based on ISAKMP. R. Pereira, P. Bhattacharya [Page 1] Internet Draft IPSec Policy Data Model February, 98 Table of Contents 1. Introduction...................................................2 1.1. Specification of Requirements..............................2 2. Data Model.....................................................2 2.1. ISAKMP Model...............................................3 2.2. IPSec Model................................................4 3. Security Considerations........................................7 4. References.....................................................7 5. Editors' Addresses.............................................8 1. Introduction The original intent of this document was to present a flexible, extensible and interoperable IPSec policy model that would be used by all IPSec compliant devices. This version of this document represents a scaled down effort of that original goal. This is due to many reasons, most notably the size of such an undertaking and the number of equally correct policy paradigms that IPSec can be molded into. The authors hope that this base IPSec data model will provide implementers sufficient information on the base IPSec negotiation mechanism that they can create an Enterprise policy architecture with the correct IPSec model. It is assumed that the reader is familiar with the terms and concepts described in the "Security Architecture for the Internet Protocol" [Atkinso95] and "IP Security Document Roadmap" [Thayer97] documents as well as all other referenced IPSec documents. 1.1. Specification of Requirements The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" that appear in this document are to be interpreted as described in [Bradner97]. 2. Data Model To understand IPSec, the reader must realize that there really exists two different policy areas; one for the ISAKMP security association and one for the actual IPSec (ESP/AH) security association. While the ISAKMP SA relies on the two negotiating peers, the IPSec SA will rely on the hosts actually being protected, which in many cases are the same as the negotiating peers (client to client). R. Pereira, P. Bhattacharya [Page 2] Internet Draft IPSec Policy Data Model February, 98 The current version of this document does not try to represent objects on the network (gateways, firewalls, routers, workstations, ...) and their relationship to these data models. This work might be in future versions of this document, but it is foreseeable that most organizations will require different network security policy architectures. The following data models are represented in ASN.1 notation merely for clarity and is not intended to imply any preference for ASN.1 based policy mechanisms however, a LDAP schema will be added to future versions of this document. 2.1. ISAKMP Model The ISAKMP SA protects the two negotiating peers while they are communicating with ISAKMP. The specification below allows for such examples as; '(DES MD5) or (DES SHA)' IsakmpDescriptor ::= SEQUENCE { exchange ENUMERATED { MainMode, AggressiveMode } OPTIONAL, proposal SEQUENCE OF IsakmpProposal } o The main ISAKMP object mainly includes proposals, but also includes which exchange to utilize. AggressiveMode does not hide the identity of the negotiating peers, while MainMode does. Please refer to [Harkins98] for a more complete reference to both of these two exchange modes. The exchange mode MAY not be included in this object since it MAY instead depend on the peers. o The proposals are all taken as logical ORs when presented together. R. Pereira, P. Bhattacharya [Page 3] Internet Draft IPSec Policy Data Model February, 98 IsakmpProposal ::= SEQUENCE { cipher IsakmpCipherAlg, keylength INTEGER OPTIONAL, hash HashAlg, group INTEGER OPTIONAL, expiry Expiry } o The keylength attribute is only valid when the cipher algorithm is CAST, RC5 or Blowfish. o The default for the group attribute is 1. HashAlg ::= ENUMERATED { md5, sha1, tiger } o The hash algorithm values are specified in [Harkins98]. IsakmpCipherAlg ::= ENUMERATED { des, idea, blowfish, rc5, des3, cast } o The cipher algorithm values are specified in [Harkins98]. Expiry ::= SEQUENCE { seconds INTEGER OPTIONAL, kilobytes INTEGER OPTIONAL } 2.2. IPSec Model The IPSec SA(s) protects the actual IP traffic between two systems. IPSec allows for security gateways (firewalls, routers or edge devices, ...) to proxy on behalf of systems behind them so that the R. Pereira, P. Bhattacharya [Page 4] Internet Draft IPSec Policy Data Model February, 98 negotiating system may not be the end-system. Thus rules based on IpsecDescriptor SHOULD be referenced by the actual end-systems being protected. Additionally, rules MAY also be referenced by either edge devices proxing on their behalf. The specification below allows for such examples as; '(ESP (DES HMAC MD5) OR (DES HMAC SHA)) OR ((ESP DES) AND (AH (HMAC MD5) OR (HMAC SHA)))' IpsecDescriptor ::= SEQUENCE { pfs BOOLEAN, proposal SEQUENCE OF IpsecProposal } o The Perfect Forward Secrecy (pfs) attribute is situated in the IPSec object and not in the ISAKMP object since this attribute is used in QuickMode (phase 2) for the initial IPSec SA and for subsequent rekeyed SAs. o The proposals are all taken as logical ORs when presented together. IpsecProposal ::= SEQUENCE OF { protectionSuite IpsecSuite } o The protectionSuite attributes are all taken as logical ANDs when presented together thus allowing for multiple protocols to be negotiated together. IpsecSuite ::= CHOICE { espProtocol SEQUENCE OF EspProposal, ahProtocol SEQUENCE OF AhProposal, compProtocol SEQUENCE OF IpcompProposal } o The IpsecSuite represents one of three possible protocol types. ESP allows for confidentiality and integrity/authentication, AH only allows for integrity/authentication and IPComp allows for compression. R. Pereira, P. Bhattacharya [Page 5] Internet Draft IPSec Policy Data Model February, 98 EspProposal ::= SEQUENCE { cipher IpsecCipherAlg, keylength INTEGER OPTIONAL, keyrounds INTEGER OPTIONAL, integrity IntegrityAlg OPTIONAL, group INTEGER OPTIONAL, expiry Expiry OPTIONAL } o The keylength attribute MUST only be present when the cipher algorithm is either CAST, RC5, or blowfish. o Key rounds is currently not defined for any cipher algorithm, but if a cipher algorithm is specified in the future that utilizes key rounds, then this attribute MAY be present. o The group attribute defaults to 1 and SHOULD only be present if the PFS attribute is TRUE. AhProposal ::= SEQUENCE { integrity IntegrityAlg, group INTEGER OPTIONAL, expiry Expiry OPTIONAL } o The group attribute defaults to 1 and SHOULD only be present if the PFS attribute is TRUE. IpcompProposal ::= SEQUENCE { compression CompressionAlg, expiry Expiry OPTIONAL } CompressionAlg ::= ENUMERATED { oui, deflate, lzs, v42bis } o The compression algorithm values are specified in [Piper98]. R. Pereira, P. Bhattacharya [Page 6] Internet Draft IPSec Policy Data Model February, 98 IntegrityAlg ::= ENUMERATED { hmacMd5, hmacSha1, hmacDes, keyedMd5, hmacRipem } o The integrity algorithm values are specified in [Piper98]. IpsecCipherAlg ::= ENUMERATED { none, rfc1829-iv64, des, des3, rc5, idea, cast, blowfish, 3idea, rfc1829-iv32, rc4 } o The cipher algorithm values are specified in [Piper98]. 3. Security Considerations This draft merely presents a data model of the IPSec documents. All security considerations within those actual specification MUST be considered previously to implementing a policy architecture. 4. References [Atkinso95] R. Atkinson, "Security Architecture for the Internet Protocol", draft-ietf-ipsec-arch-sec-01 [Bradner97] S. Bradner, "Key words for use in RFCs to indicate Requirement Levels", RFC2119 [ISAKMP] D. Maughan, M. Schertler, M. Schneider, J. Turner, "Internet Security Association and Key Management Protocol", draft-ietf-ipsec-isakmp-08 R. Pereira, P. Bhattacharya [Page 7] Internet Draft IPSec Policy Data Model February, 98 [Harkins98] D. Harkins, "The Resolution of ISAKMP and Oakley", draft-ietf-ipsec-isakmp-oakley-06 [Droms97] R. Droms, "Dynamic Host Configuration Protocol", RFC2131 [Radius97] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC2138 [Ldap97] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3)", RFC2251 [Keromy98] A. Keromytis, N. Provos, "The Use of HMAC-RIPEMD-160-96 within ESP and AH", draft-ietf-ipsec-auth-hmac-ripemd- 160-96-01.txt [Piper98] D. Piper, "The Internet IP Security Domain of Interpretation for ISAKMP", draft-ietf-ipsec-ipsec-doi- 07.txt 5. Editors' Addresses Roy Pereira rpereira@timestep.com TimeStep Corporation +1 (613) 599-3610 x 4808 Partha Bhattacharya IBM Corporation partha@watson.ibm.com +1 (919) 863-7981 The IPSec working group can be contacted via the IPSec working group's mailing list (ipsec@tis.com) or through its chairs: Robert Moskowitz rgm@icsa.net International Computer Security Association Theodore Y. Ts'o tytso@MIT.EDU Massachusetts Institute of Technology R. Pereira, P. Bhattacharya [Page 8] From owner-ipsec Mon Feb 23 15:40:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA17355 for ipsec-outgoing; Mon, 23 Feb 1998 15:40:49 -0500 (EST) Message-ID: From: Roy Pereira To: "'Greg Carter'" , "'IPSEC Mailing List (E-mail)'" , "'Dan Harkins (E-mail)'" Subject: RE: Certificate Requesting Date: Mon, 23 Feb 1998 15:15:39 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk The additional exchange scenario that you do not agree with only happens if the initiator does not send a certificate and the responder does not have it. The responder will then append a CertReq payload to the ISAKMP message. If the initiator receives the CertReq in the sixth message of MainMode (RSA_SIG), then he must reply back with his certificate in a MainMode message. He may also append a CertReq to that message if the responder did not include a certificate in the sixth message and he does not have it. This would force the responder to reply back with his certificate. This scenario was brought forth by a rather large software corporation since this is what they do in their IPSec implementation. >-----Original Message----- >From: Greg Carter [SMTP:greg.carter@entrust.com] >Sent: Friday, February 20, 1998 6:55 PM >To: Roy Pereira; 'IPSEC Mailing List (E-mail)'; 'Dan Harkins (E-mail)' >Subject: RE: Certificate Requesting > >Hi Roy, > >I know a few IKE's that will accept the Cert Req in the SA exchange, the >KE, or the final ID part. I really don't what to see the case you >propose as even being valid (additional exchange). For one it allows >for an awful state on the responder. Take this situation > >> Initiator Responder >> ---------- ----------- >> HDR, SA --> >> <-- HDR, SA >> HDR, KE, Ni --> >> <-- HDR, KE, Nr >> HDR*, IDii,CERT, SIG_I --> >> <-- HDR*, IDir, SIG_R > >If I am the Responder I have all I need, my main mode is done. But now >I have to keep it open just in case you want to send me a cert request >payload. > >No sir, No sir, I don't like it. > >> HDR*, CERTREQ --> > >You can't do it under an info because the Responder has gone to the >Encrypt only state because he has a valid SA. > >ISAKMP states that optional payloads must be accepted any time during >the exchange, to me this doesn't mean it is valid to extend the exchange >>to send optional payloads. > >Send your Cert Req either during SA, KE, or ID exchanges. Don't tack on >an additional exchange. I know this isn't the greatest because you >don't have the ID payload until the last exchange. Well then you cache >certs based on IP, or you cache certs based on SA, or you send over your >Vendor Specific cert cache info payload, or just don't cache certs and >live with the 1k of additional data as opposed to the headaches you are >going to cause yourself with caching... >Bye. >---- >Greg Carter, Entrust Technologies >greg.carter@entrust.com > > >>---------- >>From: Roy Pereira[SMTP:rpereira@TimeStep.com] >>Sent: Friday, February 20, 1998 4:48 PM >>To: IPSEC Mailing List (E-mail); Dan Harkins (E-mail) >>Subject: Certificate Requesting >> >>The issue of certificate requesting came up at thursday's IPSec/CA >>meeting. The issue is that the certificate payload is optional when the >>authentication method is RSA_SIG, but that the system doesn't know >>whether or not the other peer has their certificate. If the other peer >>already has it, then there is no point of sending a 1400 byte >>certificate payload in the ISAKMP message. So, this is where the >>certificate request payload comes into play. Unforetunately, there >>really hasn't been too much clear text of the usage of this payload. >>The specifications state that this payload MAY appear in any exchange, >>but it was determined at the IPSec/CA meeting that clearer wording would >>be required. >> >>I should also mention that this does not break any of the IPSec >>specifications, it only would make this situation clearer to an >>implementer. >> >>Only two situations come to mind where the CertReq payload would come in >>handy; >> >>(1) after the authentication exchange has been sent without a >>certificate and the other peer did not have or could not get the peer's >>certificate or >> >>(2) during the second exchange where we send over DH public keys and >>nonces. A CertReq here would denote that the peer has no way of >>retreiving a certificate so that the other peer must include their >>certificate in the next exchange. >> >>Since the CERT_REQ payload can be located in any exchange, it might be >>located on the last message; >> >> Initiator Responder >> ---------- ----------- >> HDR, SA --> >> <-- HDR, SA >> HDR, KE, Ni --> >> <-- HDR, KE, Nr >> HDR*, IDii, [ CERT, ] SIG_I --> >> <-- HDR*, IDir, [ CERT, ] SIG_R[, >>CERTREQ >> [ HDR*, CERT [, CERTREQ] --> >> [<-- HDR*, CERT ] ] ] >> >>This would cause one or two extra messages to occur as in the above >>example. >> >>So, can we add wording to the IKE document to clearify this situation so >>that we can incorporate this feature for the March 2nd bakeoff? >> From owner-ipsec Mon Feb 23 15:41:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA17356 for ipsec-outgoing; Mon, 23 Feb 1998 15:40:50 -0500 (EST) Message-ID: From: Roy Pereira To: "'Daniel Harkins'" , "'Michael C. Richardson'" Cc: "'wdm@epoch.ncsc.mil'" , "'ipsec@tis.com'" Subject: RE: new draft-ietf-ipsec-isakmp? Date: Mon, 23 Feb 1998 15:22:14 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk FYI: defines a mechanism for exchanging this type of information without defining a new payloda and its values can be any length, not just 96 bits. >-----Original Message----- >From: Daniel Harkins [SMTP:dharkins@cisco.com] >Sent: Monday, February 23, 1998 2:24 AM >To: Michael C. Richardson >Cc: wdm@epoch.ncsc.mil; ipsec@tis.com >Subject: Re: new draft-ietf-ipsec-isakmp? > > Michael, > >> Here is my original text. If anyone wants me to post the discussion >> that ensued, I will do that, assuming that the parties involved don't >> object. Word smithing welcome. > >I don't object if you feel it is necessary. > >> To: Daniel Harkins , >> wdm@epoch.ncsc.mil (W. Douglas Maughan) >> CC: ylo@ssh.fi, piper@cisco.com, mjs@terisa.com, mss@tycho.ncsc.mil, >> tmo@ssh.fi, kivinen@ssh.fi >> Subject: Re: vendor id in isakmp >> In-reply-to: Your message of "Sun, 12 Oct 1997 14:37:42 PDT." >> <199710122137.OAA24282@dharkins-ss20> >> Date: Mon, 13 Oct 1997 15:47:05 -0400 >> From: "Michael C. Richardson" >[snip] >> If Vendor ID(s) are sent, they MUST be sent during the Phase I >> exchange. [comment please! MCR] >> >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> ! Next Payload ! RESERVED ! Payload Length ! >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> ! ! >> ! VENDOR ID: 96 bits ! >> ! ! >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >Does this have to be 96bits? Since a payload length is included can't this >just be an opaque blob whose length is determined by the payload length >field? > > Dan. > From owner-ipsec Mon Feb 23 16:05:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA17553 for ipsec-outgoing; Mon, 23 Feb 1998 16:04:54 -0500 (EST) Message-Id: <199802232117.NAA05958@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Roy Pereira Cc: "'Greg Carter'" , "'IPSEC Mailing List (E-mail)'" Subject: Re: Certificate Requesting In-Reply-To: Your message of "Mon, 23 Feb 1998 15:15:39 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 23 Feb 1998 13:17:45 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Roy, > The additional exchange scenario that you do not agree with only happens > if the initiator does not send a certificate and the responder does not > have it. The responder will then append a CertReq payload to the ISAKMP > message. If the initiator receives the CertReq in the sixth message of > MainMode (RSA_SIG), then he must reply back with his certificate in a > MainMode message. He may also append a CertReq to that message if the > responder did not include a certificate in the sixth message and he does > not have it. This would force the responder to reply back with his > certificate. > > This scenario was brought forth by a rather large software corporation > since this is what they do in their IPSec implementation. [snip] Perhaps I'm missing something here but you're asking for the cert's too late. You need them to verify the signature but you're not asking for them until you've already, presumably, authenticated your security association by checking the peer's signature. >> Initiator Responder >> ---------- ----------- >> HDR, SA --> >> <-- HDR, SA >> HDR, KE, Ni --> >> <-- HDR, KE, Nr >> HDR*, IDii, [ CERT, ] SIG_I --> >> <-- HDR*, IDir, [ CERT, ] SIG_R[, >>CERTREQ >> [ HDR*, CERT [, CERTREQ] --> >> [<-- HDR*, CERT ] ] ] >> If the Initiator didn't send his cert in his 3rd message then the responder wouldn't be able to verify his signature and would abort the communication. Why not send a CERTREQ in the 2nd messages. That way you're still keeping a modicum of identity protection (sending it in the 1st messages requires the other party to respond with his cert in the clear). At the point you're sending the KE and nonce payloads you know what your authentication method is. If it's signature based and you don't have a cert for the peer (granted it's tough to know if you do since all you have to go on at that point is IP address and not everyone will be encoding an IP address in their certs) send the CERTREQ then. Why the need for the extra round trip? And the suspension of authentication and retention of state? Am I missing something here? Dan. From owner-ipsec Mon Feb 23 16:26:19 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA17692 for ipsec-outgoing; Mon, 23 Feb 1998 16:25:52 -0500 (EST) Message-ID: From: Greg Carter To: "'Theodore Y. Ts'o'" Cc: "'IPSEC Mailing List'" Subject: RE: Certificate Requesting Date: Mon, 23 Feb 1998 16:27:57 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk >---------- >From: Theodore Y. Ts'o[SMTP:tytso@MIT.EDU] >Sent: Monday, February 23, 1998 12:51 PM >To: Greg Carter >Cc: 'Theodore Y. Ts'o'; 'IPSEC Mailing List'; 'Dan Harkins'; 'RoyPereira' >Subject: Re: Certificate Requesting > > From: Greg Carter > Date: Sun, 22 Feb 1998 14:51:49 -0500 > > I would not interpret this to mean that I can arbitrarily extend the > exchange. There is plenty of opportunity to send the cert request during > the defined exchange. > >The text I quoted is from the ISAKMP document; within the context of >ISAKMP, there can be an arbitrary number of round-trips. IKE rides on Hi Ted, Can you point me to where in ISAKMP that it states arbitrary number of round trips are allowed? All I could find was text to the contrary. >From Section 2.1 Exchange Type - An exchange type is a specification of the number of messages in an ISAKMP exchange, and the payload types that are contained in each of those messages. What's the purpose of specifying the number of messages in an exchange if the number can be arbitrarily modified? Thanks. Bye ---- Greg Carter, Entrust Technologies greg.carter@entrust.com > > > From owner-ipsec Mon Feb 23 16:27:07 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA17705 for ipsec-outgoing; Mon, 23 Feb 1998 16:26:53 -0500 (EST) Date: Mon, 23 Feb 1998 16:39:49 -0500 (EST) Message-Id: <199802232139.QAA29702@carp.morningstar.com> From: Ben Rogers To: Roy Pereira Cc: "IPSEC Mailing List (E-mail)" , "VPN Mailing List (E-mail)" Subject: IPSec Policy Model draft In-Reply-To: References: Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Roy Pereira writes: > > Internet Engineering Task Force R. Pereira, TimeStep Corp. > IP Security Working Group P. Bhattacharya, IBM Corp. > IsakmpDescriptor ::= > SEQUENCE { > exchange ENUMERATED { > MainMode, > AggressiveMode } OPTIONAL, > proposal SEQUENCE OF IsakmpProposal > } > > o The main ISAKMP object mainly includes proposals, but also > includes which exchange to utilize. AggressiveMode does not > hide the identity of the negotiating peers, while MainMode does. > Please refer to [Harkins98] for a more complete reference to > both of these two exchange modes. > > The exchange mode MAY not be included in this object since it > MAY instead depend on the peers. > > o The proposals are all taken as logical ORs when presented > together. Thank you both for such a clear and concise document! Even though I wasn't entirely familiar with the notation, I quickly found the text well organized, unambiguous and simple to understand. It took me less than 5 minutes to read and digest the contents of the document. This draft should be a model for future draft authors. ben From owner-ipsec Mon Feb 23 22:21:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA19902 for ipsec-outgoing; Mon, 23 Feb 1998 22:17:55 -0500 (EST) Date: Mon, 23 Feb 1998 22:31:22 -0500 From: hugh@mimosa.com ("D. Hugh Redelmeier") Message-Id: <199802240331.WAA11793@mimosa.com> To: ipsec@tis.com Cc: gnu@toad.com, henry%spenford@zoo.toronto.edu, hugh@toad.com, rgb@conscoop.flora.org Subject: Comments on draft-ietf-ipsec-arch-sec-02.txt Sender: owner-ipsec@ex.tis.com Precedence: bulk I was disappointed that there wasn't more said about ISAKMP/Oakley etc. Section 3.2, has the sentence: In transport mode the protocols provide protection primarily for upper layer protocols; in tunnel mode, the protocols are applied to tunneled IP packets. as a naive reader, I have no idea what this is trying to communicate about tunnel mode. It sounds like a tautology. Section 4.3 states: o Transport adjacency refers to applying more than one security protocol to the same IP datagram, without invoking tunneling. This approach to combining AH and ESP allows for only one level of combination; further nesting yields no added benefit since the processing is performed at one IPsec instance the (ultimate) destination. This statement must be assuming that two composed ESP transforms are no more secure than a single one (otherwise the conclusion is false). Similarly, it must assume that two AHs don't lead to more confidence. I think that neither of these assumptions is true. On the other hand, one approach available is to add a new AH or ESP that is equivalent to the compositions of interest. I'm not quibbling with the decision to limit adjacency. I just think that the quoted text isn't precisely correct. The first normal paragraph after this quoted text starts: These two approaches also can be combined, i.e., an SA bundle could be constructed from one tunnel mode SA and one or two transport mode SAs, applied in sequence. The use of "i.e." is incorrect; "eg." is meant; "for example" is better. Section 4.4.1, paragraph 3, sentence 2 states: This interface must allow the user (or system administrator) to specify the security processing to be applied to each packet entering or exiting the system, on a packet by packet basis. I don't think that the user/sysadmin would be willing to specify security processing on a packet by packet basis. What exactly is intended by this sentence? Section 4.5, near the end: The following combinations of AH and ESP MUST be supported in the indicated contexts: - Cases 1, 3, 4 (between H1 and H2): a. AH in transport mode b. ESP in transport mode b. AH followed by ESP in transport mode d. any one of a, b, or c above AH or ESP in tunnel mode - Cases 1, 2, 3, and 4 (all SAs shown): e. AH in tunnel mode f. ESP in tunnel mode As noted above, support for additional combinations of AH and ESP is optional. Use of other, optional combinations may adversely affect interoperability. I think that the second "b." ought to be "c.". In "d.", what does "above" mean? I know, but am not sure that this term is defined (certainly not in this section). I am uncomfortable with this apparently intricate and empirical enumeration of possibilities. Section 5.1.2, first point: o The outer IP header Source Address and Destination Address identify the "endpoints" of the tunnel (the encapsulator and decapsulator). The inner IP header Source Address and Destination Addresses identify the original sender and recipient of the datagram, respectively. The word "original" is a little tricky. We might be dealing with tunneling in tunneling. In Acknowledgements there is a comma preceded by a space. Appendix C Each occurrence of "1 << diff" should probably be "1ul << diff". I'm not sure that the test harness should be included. Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253 From owner-ipsec Mon Feb 23 22:21:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA19914 for ipsec-outgoing; Mon, 23 Feb 1998 22:18:57 -0500 (EST) Date: Mon, 23 Feb 1998 22:33:07 -0500 From: hugh@mimosa.com ("D. Hugh Redelmeier") Message-Id: <199802240333.WAA11800@mimosa.com> To: ipsec@tis.com Cc: gnu@toad.com, henry%spenford@zoo.toronto.edu, hugh@toad.com, rgb@conscoop.flora.org Subject: comments on draft-ietf-ipsec-oakley-02.txt Sender: owner-ipsec@ex.tis.com Precedence: bulk A table of contents is worthwhile for a document of this size. Section 2.3, first paragraph, last sentence: The encodings and meanings for these choices are presented in Appendix B. This turns out not to be the case. Section 2.4.1, near the end, has a sequence of steps that the initiator performs. The last three are: sends the reply message, signed with the public key of ID(I), marks the KEYID (CKY-I|CKY-R) as authenticated, and composes the reply message and signature. I suspect I don't understand the last step because it seems to me that this would have to be done before the third last step. Sort of like "Ready, Fire, Aim". Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253 From owner-ipsec Mon Feb 23 22:22:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA19937 for ipsec-outgoing; Mon, 23 Feb 1998 22:20:57 -0500 (EST) Date: Mon, 23 Feb 1998 22:35:33 -0500 From: hugh@mimosa.com ("D. Hugh Redelmeier") Message-Id: <199802240335.WAA11842@mimosa.com> To: ipsec@tis.com Cc: gnu@toad.com, henry%spenford@zoo.toronto.edu, hugh@toad.com, rgb@conscoop.flora.org Subject: comments on draft-ietf-ipsec-isakmp-08.txt Sender: owner-ipsec@ex.tis.com Precedence: bulk Section 3.5, describes the Payload Length of a Proposal Payload as: o Payload Length (2 octets) - Length in octets of the entire Proposal payload, including the Proposal payload, and all Transform payloads associated with this proposal. In the event there are multiple proposals with the same proposal number (see section 4.1), the This seem a bit circular ("the entire Proposal payload, including the Proposal payload"). I think that transform payloads ought to be considered part of the payload of their proposal. As such, the diagram for the Proposal Payload ought to be be changed to include them. Then this would not seem so confusing. Section 3.8 describes the Identification Payload. o RESERVED2 (3 octets) - Unused, set to 0. This field is used in the IPsec DOI to hold Port and Protocol. If I interpret everything correctly, this is invalid. The best fix would be to change this field to be DOI-specified (as is done for the Identification Data). Section 3.14, in describing the Notification Payload, says: o Domain of Interpretation (4 octets) - Identifies the DOI (as described in Section 2.1) under which this notification is taking place. For the Internet, the DOI is one (1). Other DOI's can be defined using the description in appendix B. As far as I can tell, 1 is the DOI for "IETF IP Security DOI" (as described in 2.1). This would better be shortened to "IPsec DOI" rather than "Internet DOI". I think this description ought to mention 0 for the ISAKMP DOI too. These comments probably apply to other places in the draft (for example 3.15). I think that the ISAKMP DOI may need to be spelled out as per appendix B. Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253 From owner-ipsec Mon Feb 23 22:22:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA19936 for ipsec-outgoing; Mon, 23 Feb 1998 22:20:57 -0500 (EST) Date: Mon, 23 Feb 1998 22:34:18 -0500 From: hugh@mimosa.com ("D. Hugh Redelmeier") Message-Id: <199802240334.WAA11835@mimosa.com> To: ipsec@tis.com Cc: gnu@toad.com, henry%spenford@zoo.toronto.edu, hugh@toad.com, rgb@conscoop.flora.org Subject: comments on draft-ietf-ipsec-isakmp-oakley-06.txt Sender: owner-ipsec@ex.tis.com Precedence: bulk The table of contents does not give the full names of the sections within 5. Each says what phase it is part of, and I would have found that useful in the TOC. The TOC entries for Appendices should have mentioned what was in each. Section 1, in describing SKEME says: [Kra96] (SKEME) describes a versatile key exchange technique which provides anonymity, repudiability, and quick key refreshment. I don't know SKEME, but claiming repudiability seems odd. Perhaps "non-repudiability" is meant. Section 3.2 describes notation: IDx is the identity payload for "x". x can be: "ii" or "ir" for the ISAKMP initiator and responder respectively during phase one negotiation; or "ui" or "ur" for the user initiator and responder respectively during phase two. The ID payload format for the Internet DOI is defined in [Pip97]. I have posted notes about Identification Payload issues. The correct term appears to be "Identification Payload", not identity payload. I think that the definition in the ISAKMP draft [MSST97] applies simultaneously (in the IPsec DOI) or only (in the ISAKMP DOI). The term "Internet DOI" seems misleading; I'd use "IPsec DOI". Section 5.5 describes how to cook up more keying material, if it is needed: For situations where the amount of keying material desired is greater than that supplied by the prf, KEYMAT is expanded by feeding the results of the prf back into itself and concatenating results until the required keying material has been reached. In other words, I'm not a cryptographer, but... This sounds like something for nothing. What are the cryptographic implications of generating extra keying material this way? I think that the document should address this question. Appendix A, under group description: - Group Description default 768-bit MODP group (section 6.1) 1 alternate 1024-bit MODP group (section 6.2) 2 .sp EC2N group on GP[2^155] (section 6.3) 3 .sp EC2N group on GP[2^185] (section 6.4) 4 values 5-32767 are reserved to IANA. Values 32768-65535 are for private use among mutually consenting parties. Indented troff commands don't work. Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253 From owner-ipsec Mon Feb 23 23:30:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA20356 for ipsec-outgoing; Mon, 23 Feb 1998 23:27:56 -0500 (EST) Date: Mon, 23 Feb 1998 22:36:38 -0500 From: hugh@mimosa.com ("D. Hugh Redelmeier") Message-Id: <199802240336.WAA11849@mimosa.com> To: ipsec@tis.com Cc: gnu@toad.com, henry%spenford@zoo.toronto.edu, hugh@toad.com, rgb@conscoop.flora.org Subject: comments on draft-ietf-ipsec-ipsec-doi-06.txt Sender: owner-ipsec@ex.tis.com Precedence: bulk This document is long enough that I would have found a table of contents useful. Section 4.6.2 describes the Identification Payload. This layout contradicts the ISAKMP description for this payload (the Protocol ID and Port fields are reserved (0) according the ISAKMP). I have recommended that ISAKMP be changed. During Phase I negotiations, the ID port and protocol fields MUST be set to zero or to UDP port 500. If an implementation receives any other values, this MUST be treated as an error and the security association setup MUST be aborted. This event SHOULD be auditable. I sometimes run an ISAKMP/Oakley Daemon from another port. If it were to fill in the Port field, 500 would then be a lie. Should this Port number not be the actual one? At the very least, the *meaning* of 500 should be mentioned. I'm not sure where to find it, but draft-ietf-ipsec-isakmp-08.txt claims that it has been assigned to ISAKMP. In the same spot, it says: Implementations MAY additionally support ISAKMP over other transport protocols or over IP itself. This re-enforces the previous point. During Phase 1, it might be better to match the ISAKMP DOI. These fields should then be zero. Having a choice here seems not very useful, but it does add complexity. o Protocol ID (1 octet) - Value specifying an associated IP protocol ID (e.g. UDP/TCP). A value of zero means that the Protocol ID field should be ignored. There should be a reference to nail down the encoding. I know that we all know it. Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253 From owner-ipsec Mon Feb 23 23:45:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA20472 for ipsec-outgoing; Mon, 23 Feb 1998 23:43:56 -0500 (EST) Message-ID: <34F25319.2781@cs.umass.edu> Date: Mon, 23 Feb 1998 23:56:57 -0500 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V4.0 alpha) MIME-Version: 1.0 To: "D. Hugh Redelmeier" CC: IP Security List Subject: Re: comments on draft-ietf-ipsec-isakmp-oakley-06.txt References: <199802240334.WAA11835@mimosa.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk D. Hugh Redelmeier writes: > Section 1, in describing SKEME says: > > [Kra96] (SKEME) describes a versatile key exchange technique which > provides anonymity, repudiability, and quick key refreshment. > > I don't know SKEME, Per Sec. 13: [Kra96] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange Mechanism for Internet", from IEEE Proceedings of the 1996 Symposium on Network and Distributed Systems Security. > but claiming repudiability seems odd. I'm not following your line of reasoning here. > Perhaps "non-repudiability" is meant. Nope. Here's an excerpt from the end of Sec. 5.2 that discusses this feature of the protocol: >>> Using encryption for authentication provides for a plausably deniable >>> exchange. There is no proof (as with a digital signature) that the >>> conversation ever took place since each party can completely >>> reconstruct both sides of the exchange. In addition, security is >>> added to secret generation since an attacker would have to >>> successfully break not only the Diffie-Hellman exchange but also >>> both RSA encryptions. This exchange was motivated by [Kra96]. -Lewis From owner-ipsec Tue Feb 24 02:08:11 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA21266 for ipsec-outgoing; Tue, 24 Feb 1998 02:06:55 -0500 (EST) Message-ID: <34F274A0.794B@cs.umass.edu> Date: Tue, 24 Feb 1998 02:20:00 -0500 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V4.0 alpha) MIME-Version: 1.0 To: "D. Hugh Redelmeier" CC: IP Security List Subject: Re: Comments on draft-ietf-ipsec-arch-sec-02.txt References: <199802240331.WAA11793@mimosa.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk D. Hugh Redelmeier writes: > Section 4.3 states: > > o Transport adjacency refers to applying more than one security > protocol to the same IP datagram, without invoking tunneling. > This approach to combining AH and ESP allows for only one > level of combination; further nesting yields no added benefit > since the processing is performed at one IPsec instance the > (ultimate) destination. > > This statement must be assuming that two composed ESP transforms are > no more secure than a single one (otherwise the conclusion is false). > Similarly, it must assume that two AHs don't lead to more confidence. > I think that neither of these assumptions is true. For each of {ESP, AH} the IPsec suite allows for SAs whose transforms involve combinations of algorithms, modes, and keylengths that are believed to offer high levels of long-term security. If you accept these cryptographic judgments then you have cause to expect that a single application of the transforms in an appropriately-chosen ESP (respectively AH) SA in transport mode provides the desired level of security. Once a portion of a system is "secure enough" w.r.t. the anticipated threat model, efforts to "strengthen" that portion of the system don't actually increase the security of the system. So an additional adjacent transport mode application of ESP (resp. AH) transforms is no more secure than the solo case. If you reject some of the cryptographic assumptions underlying the defined set of algorithms, etc., then multiple adjacent applications _might_ offer you greater security than any single application. This would depend upon the nature and complexity of the additional attacks to which you believe the affected algorithm(s) is (are) susceptible. > On the other hand, > one approach available is to add a new AH or ESP that is equivalent to > the compositions of interest. Right. At various times it will probably happen that some existing algorithms fall into cryptographic disfavor, and people will see the need to define some new ones. However at any given time the operative premise is that the available algorithms offer sufficient security guarantees without multiple adjacent applications. Those who aren't content with the status quo can define the protocol use of algorithms with which they feel more comfortable. Architectural support for composition of algorithms via adjacent applications of transforms from multiple SAs would therefore be redundant, as far as I can see. > I'm not quibbling with the decision to limit adjacency. I just think > that the quoted text isn't precisely correct. -Lewis From owner-ipsec Tue Feb 24 02:09:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA21280 for ipsec-outgoing; Tue, 24 Feb 1998 02:08:55 -0500 (EST) Date: Tue, 24 Feb 1998 09:21:24 +0200 (EET) Message-Id: <199802240721.JAA00984@pilari.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Roy Pereira Cc: "'Greg Carter'" , "'IPSEC Mailing List (E-mail)'" , "'Dan Harkins (E-mail)'" Subject: RE: Certificate Requesting In-Reply-To: References: X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 8 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Roy Pereira writes: > The additional exchange scenario that you do not agree with only happens > if the initiator does not send a certificate and the responder does not > have it. The responder will then append a CertReq payload to the ISAKMP > message. If the initiator receives the CertReq in the sixth message of > MainMode (RSA_SIG), then he must reply back with his certificate in a > MainMode message. He may also append a CertReq to that message if the > responder did not include a certificate in the sixth message and he does > not have it. This would force the responder to reply back with his > certificate. And if responder again includes certificate request (it can, there is no limitation that there must be only one of certificate request) the initiator must again reply to it and so on. Is there any limit for this? I can see that someone might want to use this kind of system when they don't want the other end even to know what CA's they need. They could first ask can you provide certificate for this CA, and if so they know OK, now it is ok to ask next level of CA etc. I really don't like the exchange to be extended this way. I would really like to explicitly say that certificate requests are only allowed if the other end is going to reply this message anyway. You can also expand the exchange from normal six or three messages if you set commit bit. > This scenario was brought forth by a rather large software corporation > since this is what they do in their IPSec implementation. Is there really any real use for this? It makes the state machine even more complicated than it is now, and the there are quite a lot of different stuff there already given all the different authentications, aggressive/main mode, commit bit etc. -- kivinen@iki.fi Work : +358-9-4354 3207 Magnus Enckellin kuja 9 K 19, 02610, Espoo Home : +358-9-502 1573 From owner-ipsec Tue Feb 24 02:31:15 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA21408 for ipsec-outgoing; Tue, 24 Feb 1998 02:30:55 -0500 (EST) Date: Tue, 24 Feb 1998 09:42:41 +0200 (EET) Message-Id: <199802240742.JAA01083@pilari.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Roy Pereira Cc: "'Daniel Harkins'" , "'Michael C. Richardson'" , "'wdm@epoch.ncsc.mil'" , "'ipsec@tis.com'" Subject: RE: new draft-ietf-ipsec-isakmp? In-Reply-To: References: X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 16 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Roy Pereira writes: > FYI: defines a mechanism for > exchanging this type of information without defining a new payloda and > its values can be any length, not just 96 bits. I assume you mean draft-ietf-ipsec-isakmp-mode-cfg-01.txt? I think the vendor-id and cfg-mode mechanism are for different things. The vendor-id payload is to tell the other end that if we use private extensions later this can be used to detect who's extensions I am using. The configuration mode can be used to exchange configuration stuff with two hosts. The configuration mode has the same problem than normal modes, because if I want to send some private attribute to other end and that attribute has no meaning outside our own implementation, I cannot send it by using configuration mode unless I allocate global identifier for it. I cannot use private range because we cannot know if the other end is our own implementation or not, and that other implementation might use that exactly same number from private range to something else. The meaning of private range has no sense if I need to allocate those numbers globally. Vendor-ID payload is there to provide information who's private number space / extensions we are using. > >> If Vendor ID(s) are sent, they MUST be sent during the Phase I > >> exchange. [comment please! MCR] I think it is good to restrict them to Phase I, because it makes thing simplier. And if someone wants to use something like that in Phase II the can first use Vendor ID payload in Phase I and if they detect their own implementation at the other end they can use some private extensions or something to get same results than using vendor id (for example configuration mode or some other notify payload using private number space). > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> ! Next Payload ! RESERVED ! Payload Length ! > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> ! ! > >> ! VENDOR ID: 96 bits ! > >> ! ! > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >Does this have to be 96bits? Since a payload length is included can't this > >just be an opaque blob whose length is determined by the payload length > >field? I think it might be simplier to just allow it to be any length, and not to restrict to 96 bits. There is no reason to truncate it and if someone wants to use hash truncated to 96 bits he can do it. BTW. I think the notify codes in the configuration mode (101-104) should be renumbered out from the error types range (1-8192). They are not really error types so I think something from the status types range (16384-24575) is better. -- kivinen@iki.fi Work : +358-9-4354 3207 Magnus Enckellin kuja 9 K 19, 02610, Espoo Home : +358-9-502 1573 From owner-ipsec Tue Feb 24 03:01:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA21651 for ipsec-outgoing; Tue, 24 Feb 1998 03:01:00 -0500 (EST) Message-ID: <34F2814E.15FB@cs.umass.edu> Date: Tue, 24 Feb 1998 03:14:06 -0500 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V4.0 alpha) MIME-Version: 1.0 To: "D. Hugh Redelmeier" CC: IP Security List Subject: Re: Comments on draft-ietf-ipsec-arch-sec-02.txt References: <199802240331.WAA11793@mimosa.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk D. Hugh Redelmeier writes: [...] > Section 4.4.1, paragraph 3, sentence 2 states: > > This interface must allow the user (or system administrator) to > specify the security processing to be applied to each packet > entering or exiting the system, on a packet by packet basis. > > I don't think that the user/sysadmin would be willing to specify > security processing on a packet by packet basis. What exactly is > intended by this sentence? I can't and won't speak to the question of what was intended. My interpretation is along these lines: The interface must allow the specification of a set of security-related processing rules. These processing rules are applied to each packet crossing the system boundary. It must be possible to specify processing rules that have the granularity of a single packet -- rules that potentially indicate distinct actions to be taken when those rules are applied to distinct packets. IMHO the text in the draft is clear. [...] > Section 5.1.2, first point: > > o The outer IP header Source Address and Destination Address > identify the "endpoints" of the tunnel (the encapsulator and > decapsulator). The inner IP header Source Address and > Destination Addresses identify the original sender and recipient > of the datagram, respectively. > > The word "original" is a little tricky. We might be dealing with > tunneling in tunneling. So we have something ever so vaguely resembling, for example: [IP_3 [ESP_2 [IP_2 [ESP_1 [IP_1 [TCP ....]]]]]] W.r.t. the outer tunnel "ESP_2", the inner IP header is "IP_2" and the datagram is [IP_2 [ESP_1 [IP_1 [TCP ....]]]]. The Source and Dest Addr of "IP_2" identify the original sender and receiver, respectively, of that datagram beginning with IP header "IP_2". They just happen to be the encapsulator (resp. decapsulator) of the inner tunnel "ESP_1". I don't see an ambiguity. [...] > In Acknowledgements there is a comma preceded by a space. [...] LOL ;-> -Lewis From owner-ipsec Tue Feb 24 06:46:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA22886 for ipsec-outgoing; Tue, 24 Feb 1998 06:43:54 -0500 (EST) Date: Tue, 24 Feb 98 06:54:15 EST From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9802241154.AA00793@dolphin.ncsc.mil> To: rpereira@TimeStep.com, dharkins@cisco.com, greg.carter@entrust.com, tytso@MIT.EDU, kivinen@ssh.fi Subject: RE: Certificate Requesting Cc: ipsec@tis.com, wdm@epoch.ncsc.mil Sender: owner-ipsec@ex.tis.com Precedence: bulk All, Let me try to clear up the whole issue surrounding ISAKMP and Certificate Requesting. It was initially added for the purpose the text in section 3.10 states: "Certificate Request payloads SHOULD be included in an exchange whenever an appropriate directory service (e.g. Secure DNS [DNSSEC]) is not available to distribute certificates" It's inclusion was a "poor man's" certificate retrieval approach (to be used until such time as directories, etc. were available). It was never meant to be a "fully functional" certificate management component. However, the text in section 3.10 is unclear. Ted was correct in his interpretation of the text and effectively a CertReq payload could be sent by the responder in the last message of the exchange, thus, extending the exchange. It was NEVER intended to be used in this manner. Tero has captured the problem with the "never-ending" certificate request message exchanges example. As stated previously, the initial intent was to have the CertReq payload within the context of the given exchanges (not including the last message from the responder). The reason, from a security standpoint, is captured by Dan in his message below. That having been said, I'm willing to: (a) write clarifying text to make sure there is no misunderstanding about when a CertReq payload is included in the exchange (i.e. anytime before the last message from the responder). NOTE: This is my preference and we can state that a Key Exchange (IKE, et. al.) can extend the exchange model if they so desire. OR (b) change to the text to include the capability to continually extend the exchange (which I don't really like). OR (c) something different. What say ye?? Doug > > Roy Pereira writes: > > The additional exchange scenario that you do not agree with only happens > > if the initiator does not send a certificate and the responder does not > > have it. The responder will then append a CertReq payload to the ISAKMP > > message. If the initiator receives the CertReq in the sixth message of > > MainMode (RSA_SIG), then he must reply back with his certificate in a > > MainMode message. He may also append a CertReq to that message if the > > responder did not include a certificate in the sixth message and he does > > not have it. This would force the responder to reply back with his > > certificate. > > Tero Kivinen writes: > And if responder again includes certificate request (it can, there is > no limitation that there must be only one of certificate request) the > initiator must again reply to it and so on. Is there any limit for > this? > > I can see that someone might want to use this kind of system when they > don't want the other end even to know what CA's they need. They could > first ask can you provide certificate for this CA, and if so they know > OK, now it is ok to ask next level of CA etc. > > I really don't like the exchange to be extended this way. I would > really like to explicitly say that certificate requests are only > allowed if the other end is going to reply this message anyway. You > can also expand the exchange from normal six or three messages if you > set commit bit. > > > This scenario was brought forth by a rather large software corporation > > since this is what they do in their IPSec implementation. > > Is there really any real use for this? It makes the state machine even > more complicated than it is now, and the there are quite a lot of > different stuff there already given all the different authentications, > aggressive/main mode, commit bit etc. > > Dan Harkins writes: > Perhaps I'm missing something here but you're asking for the cert's > too late. You need them to verify the signature but you're not asking > for them until you've already, presumably, authenticated your security > association by checking the peer's signature. > > >> Initiator Responder > >> ---------- ----------- > >> HDR, SA --> > >> <-- HDR, SA > >> HDR, KE, Ni --> > >> <-- HDR, KE, Nr > >> HDR*, IDii, [ CERT, ] SIG_I --> > >> <-- HDR*, IDir, [ CERT, ] SIG_R[, > >>CERTREQ > >> [ HDR*, CERT [, CERTREQ] --> > >> [<-- HDR*, CERT ] ] ] > >> > > If the Initiator didn't send his cert in his 3rd message then the > responder wouldn't be able to verify his signature and would abort > the communication. Why not send a CERTREQ in the 2nd messages. That > way you're still keeping a modicum of identity protection (sending it > in the 1st messages requires the other party to respond with his cert > in the clear). > > At the point you're sending the KE and nonce payloads you know what your > authentication method is. If it's signature based and you don't have a > cert for the peer (granted it's tough to know if you do since all you have > to go on at that point is IP address and not everyone will be encoding an > IP address in their certs) send the CERTREQ then. > > Why the need for the extra round trip? And the suspension of authentication > and retention of state? Am I missing something here? > > Greg Carter writes: > >---------- > >From: Theodore Y. Ts'o[SMTP:tytso@MIT.EDU] > >Sent: Monday, February 23, 1998 12:51 PM > >To: Greg Carter > >Cc: 'Theodore Y. Ts'o'; 'IPSEC Mailing List'; 'Dan Harkins'; 'RoyPereira' > >Subject: Re: Certificate Requesting > > > > From: Greg Carter > > Date: Sun, 22 Feb 1998 14:51:49 -0500 > > > > I would not interpret this to mean that I can arbitrarily extend the > > exchange. There is plenty of opportunity to send the cert request during > > the defined exchange. > > > >The text I quoted is from the ISAKMP document; within the context of > >ISAKMP, there can be an arbitrary number of round-trips. IKE rides on > > Hi Ted, > Can you point me to where in ISAKMP that it states arbitrary number of > round trips are allowed? All I could find was text to the contrary. > > >From Section 2.1 > > Exchange Type - An exchange type is a specification of the number of > messages in an ISAKMP exchange, and the payload types that are contained > in each of those messages. > > What's the purpose of specifying the number of messages in an exchange > if the number can be arbitrarily modified? From owner-ipsec Tue Feb 24 09:00:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA23997 for ipsec-outgoing; Tue, 24 Feb 1998 08:58:56 -0500 (EST) Message-Id: <199802241410.JAA06672@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: new draft-ietf-ipsec-isakmp? In-reply-to: Your message of "Tue, 24 Feb 1998 09:42:41 +0200." <199802240742.JAA01083@pilari.ssh.fi> Date: Tue, 24 Feb 1998 09:10:36 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Tero" == Tero Kivinen writes: >> >Does this have to be 96bits? Since a payload length is included can't >> this >just be an opaque blob whose length is determined by the payload >> length >field? Tero> I think it might be simplier to just allow it to be any length, and Tero> not to restrict to 96 bits. There is no reason to truncate it and Tero> if someone wants to use hash truncated to 96 bits he can do it. I have no objections, it was simply my first thought. :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON Michael Richardson |Network and security consulting and contract programming Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. From owner-ipsec Tue Feb 24 16:03:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA27112 for ipsec-outgoing; Tue, 24 Feb 1998 15:56:24 -0500 (EST) Date: Tue, 24 Feb 1998 16:09:20 -0500 (EST) Message-Id: <199802242109.QAA01519@carp.morningstar.com> From: Ben Rogers To: dharkins@cisco.com, ipsec@tis.com Subject: KE payloads in IKE Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk 3.2 Notation KE is the key exchange payload which contains the public information exchanged in a Diffie-Hellman exchange. There is no particular encoding used for the data of a KE payload. [...] 6.3 Third Oakley Group [...] The data in the KE payload when using this group is the value x from the solution (x,y), the point on the curve chosen by taking the... Anyone mind telling me what the format is for the MODP KE payload? I was assuming that since IKE doesn't mention anything, the following text from draft-ietf-ipsec-oakley-02.txt was used: g^x and g^y are encodings of group elements, where g is a special group element indicated in the group description (see Appendix A) and g^x indicates that element raised to the x'th power. The type of the encoding is either a variable precision integer [...] APPENDIX C Encoding a variable precision integer. Variable precision integers will be encoded as a 32-bit length field followed by one or more 32-bit quantities containing the representation of the integer, aligned with the most significant bit in the first 32-bit item. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! first value word (most significant bits) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ additional value words ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ben From owner-ipsec Tue Feb 24 17:01:11 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA27543 for ipsec-outgoing; Tue, 24 Feb 1998 16:58:22 -0500 (EST) X-Lotus-FromDomain: CERTICOM From: "John O Goyo" To: ipsec@tis.com Message-ID: <852565B5.0079275E.00@domino_c02.certicom.com> Date: Tue, 24 Feb 1998 17:07:38 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk Greetings, IPsec Working Group: With respect to the IKE draft (draft-ietf-ipsec-isakmp-oakley-06.txt), I wish to recommend the following changes. (1) Replace the existing Section 6.3 with the following text. 6.3 Third Oakley Group IKE implementations SHOULD support a EC2N group with the following characteristics. The curve is based on the Galois Field GF[2^^163] of size 163. The irreducible polynomial for the field is the following. u^^163 + u^^7 + u^^6 + u^^3 + 1. The equation for the elliptic curve is the following. y^^2 + xy = x^^3 + ax^^2 + b. The group parameters are the following. Field Size: 163 Irreducible Polynomial: 800000000000000000000000000000000000000C9 Group Generator: x = 00BBB949D3D5B393DE4F5F02A9AC41EEF6501E43FA y = 04DE2AD998E55B65000BA7C260D7F8E5D06F87048A Group Curve A: 023AA0F25B12388DE8A10FF9554F90AFBAA9A08B6F Group Curve B: 04DFA8D4FAE77C4A9CA2DEB14EAA8169DD9DA43647 Cofactor: 2 Point Order: 03FFFFFFFFFFFFFFFFFFFF48AAB689C29CA710279B (2) Replace the existing Section 6.4 with the following text. 6.4 Fourth Oakley Group IKE implementations SHOULD support a EC2N group with the following characteristics. The curve is based on the Galois Field GF[2^^239] of size 239. The irreducible polynomial for the field is the following. u^^239 + u^^158 + 1. The equation for the elliptic curve is the following. y^^2 + xy = x^^3 + ax + b. The group parameters are the following. Field Size: 239 Irreducible Polynomial: 800000000000000000004000000000000000000000000000000000000001 Group Generator: x = 53986A165E814AD03D242D490933FE786FA6FBD40B8175B82C0ACC56132E y = 68A7846741E0E093DCAD2B8D6FD3201E2450E9D8DDD3A844B3D473EEC11B Group Curve A: 4F0E193BE91357A5091FD679B55D9CAC6EE2BC27B83BD66F18446B10D567 Group Curve B: 70755A7735113F34FA488C2510F22DC1E54BA8BFE0B33CB7A15B92B11701 Cofactor: 4 Point Order: 200000000000000000000000000000474F7E69F42FE430931D0B455AAE8B [end] The suggested new Group 3 has the cryptographic strength of RSA at 1024 bits and the suggested new Group 4 has the cryptographic strength of RSA at 2500 bits. Thank you. john o goyo From owner-ipsec Tue Feb 24 23:04:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA00365 for ipsec-outgoing; Tue, 24 Feb 1998 23:01:27 -0500 (EST) Date: Tue, 24 Feb 1998 23:14:18 -0500 Message-Id: <199802250414.XAA24442@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: wdm@epoch.ncsc.mil Cc: rpereira@TimeStep.com, dharkins@cisco.com, greg.carter@entrust.com, kivinen@ssh.fi, ipsec@tis.com, wdm@epoch.ncsc.mil In-Reply-To: W. Douglas Maughan's message of Tue, 24 Feb 98 06:54:15 EST, <9802241154.AA00793@dolphin.ncsc.mil> Subject: Re: Certificate Requesting Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Well, here's the problem. The identity payload (and the optional certificate) don't get sent until the very end of the IKE exchanges. So unless there is some other "out of band" way (*) for the implementation to know what the identity of its communication partner, by the time it receives the identity payload and discovers that a certificate hadn't been sent, it's too late for the implementation to do anything than abort the entire IKE exchange and try again, this time with a CERT-REQ earlier in the protocol. (*) Deductions based on the (unsecure) IP address of communications partner, looking at the previous failed IKE exchanges, psychic abilities, etc. Alternatively, you could always send a CERT-REQ payload, even before you discover whether or not you really needed the payload, but that doesn't seem awfully clean either. I believe this is what was driving the implementations to do the CERT-REQ that late in the game. So the question is, what do we do? Doug very nicely outlined our possible choices of how to make the specification unambiguous. There are tradeoffs with either choice; implementation complexity, versus problems in knowing whether or not you need to put a CERT-REQ earlier in the exchange. However we decide, either alternative is better than not making a decision at all, so we need to settle this issue and then move on. - Ted From owner-ipsec Wed Feb 25 07:29:54 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA04013 for ipsec-outgoing; Wed, 25 Feb 1998 07:26:26 -0500 (EST) Message-ID: From: "Patel, Baiju V" To: "'ipsec'" Subject: RE: IPSEC WORKING GROUP LAST CALL Date: Tue, 24 Feb 1998 16:01:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk I have a concern with AH+ESP in transport mode. Based on the requirements of ESP, ESP must negotiate an integrity check mechanism. The MD5-HMAC or SHA-1 HMAC MUST be supported for ESP. Similarly, the same integrity algorithms are used by AH. Therefore, it looks like I have to compute authentication data twice using possibly same algorithm over mostly same data. Something tells me that in this combination, I should be able to negotiate NULL authentication algorithm for ESP. I do understand that DES-CBC values can be used for authentication data in ESP but then what happens when we are not using DES. Any comments? Baiju From owner-ipsec Wed Feb 25 10:06:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA05631 for ipsec-outgoing; Wed, 25 Feb 1998 10:04:37 -0500 (EST) Message-Id: <3.0.5.32.19980225101455.0098f950@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 25 Feb 1998 10:14:55 -0500 To: "Theodore Y. Ts'o" , wdm@epoch.ncsc.mil From: Robert Moskowitz Subject: Re: Certificate Requesting Cc: rpereira@TimeStep.com, dharkins@cisco.com, greg.carter@entrust.com, kivinen@ssh.fi, ipsec@tis.com, wdm@epoch.ncsc.mil In-Reply-To: <199802250414.XAA24442@dcl.MIT.EDU> References: Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 11:14 PM 2/24/98 -0500, Theodore Y. Ts'o wrote: > >Alternatively, you could always send a CERT-REQ payload, even before you >discover whether or not you really needed the payload, but that doesn't >seem awfully clean either. I believe this is what was driving the >implementations to do the CERT-REQ that late in the game. This might be the 'best' way. See below. >So the question is, what do we do? Doug very nicely outlined our >possible choices of how to make the specification unambiguous. There >are tradeoffs with either choice; implementation complexity, versus >problems in knowing whether or not you need to put a CERT-REQ earlier in >the exchange. However we decide, either alternative is better than not >making a decision at all, so we need to settle this issue and then move >on. Consider the discussion we had last week in Boston with the CA vendors. Those on this list that were there, help me along, please. There are two 'standard' IKE exchanges: Trade DNs and then each looks up a cert for that DN from its CA (or local cache) and uses that cert in the exchange. leftThis might have some interesting spoof/DOS attacks if a system gives a DN that it knows the other side knows about but it does not have the private key for? Trade full cert chains. This will probably be more than 1400 bytes, particularly for longish cert chains. The challenge here is if the two systems have multiple certs and trust multiple roots with some overlap, or live in a cross-certified PKI that has a 'trusted third party' root. After the exchange, one or both systems might not have established authentication, becuase either the wrong cert and chain was sent, or the cert chain ended at the root, and did not proceed along the cross-cert link to the trusted third party root. Thus there is a need to issue a cert-req and tell the other party, 'give me a cert plus chain that goes back to one of these DNs' (either a list of trusted roots, or your CA's root plus the TTP's root). When to do this is the question. given performance issues, it might almost be 'smart' to first do a DN exchange and if you don't have the cert cached give a cert-req, or some such. better minds than mine might see a clearer way through this fog of operational implementations.... Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Wed Feb 25 10:07:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA05648 for ipsec-outgoing; Wed, 25 Feb 1998 10:07:32 -0500 (EST) Message-Id: <199802251516.KAA27869@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-xauth-01.txt Date: Wed, 25 Feb 1998 10:16:25 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Extended Authentication Within ISAKMP/Oakley Author(s) : R. Pereira Filename : draft-ietf-ipsec-isakmp-xauth-01.txt Pages : 9 Date : 24-Feb-98 This document describes a method for using existing unidirectional authentication mechanisms such as RADIUS, SecureID, and OTP with ISAKMP. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-isakmp-xauth-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-xauth-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-isakmp-xauth-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19980224113100.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-xauth-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-xauth-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980224113100.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed Feb 25 10:08:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA05661 for ipsec-outgoing; Wed, 25 Feb 1998 10:08:32 -0500 (EST) Message-Id: <199802251516.KAA27925@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-mode-cfg-02.txt Date: Wed, 25 Feb 1998 10:16:39 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The ISAKMP Configuration Method Author(s) : B. Patel, R. Pereira, S. Anand Filename : draft-ietf-ipsec-isakmp-mode-cfg-02.txt Pages : 10 Date : 24-Feb-98 This document describes a new ISAKMP method that allows information like configuration items to be exchanged securely by using both push/acknowledge or request/reply paradigms. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-isakmp-mode-cfg-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-mode-cfg-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-isakmp-mode-cfg-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: <19980224142751.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-mode-cfg-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-mode-cfg-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980224142751.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed Feb 25 12:22:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA06676 for ipsec-outgoing; Wed, 25 Feb 1998 12:17:39 -0500 (EST) Date: Wed, 25 Feb 1998 12:30:41 -0500 Message-Id: <199802251730.MAA27334@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "Patel, Baiju V" Cc: "'ipsec'" In-Reply-To: Patel, Baiju V's message of Tue, 24 Feb 1998 16:01:16 -0800, Subject: Re: IPSEC WORKING GROUP LAST CALL Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk From: "Patel, Baiju V" Date: Tue, 24 Feb 1998 16:01:16 -0800 I have a concern with AH+ESP in transport mode. Based on the requirements of ESP, ESP must negotiate an integrity check mechanism. The MD5-HMAC or SHA-1 HMAC MUST be supported for ESP. Similarly, the same integrity algorithms are used by AH. Therefore, it looks like I have to compute authentication data twice using possibly same algorithm over mostly same data. Something tells me that in this combination, I should be able to negotiate NULL authentication algorithm for ESP. Why do you want to use both AH and ESP in transport mode in the first place? What's the desired functionality and application that you're trying to accomplish? - Ted From owner-ipsec Wed Feb 25 12:23:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA06758 for ipsec-outgoing; Wed, 25 Feb 1998 12:22:43 -0500 (EST) Date: Wed, 25 Feb 1998 12:34:50 -0500 Message-Id: <199802251734.MAA27336@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Robert Moskowitz Cc: "Theodore Y. Ts'o" , wdm@epoch.ncsc.mil, rpereira@TimeStep.com, dharkins@cisco.com, greg.carter@entrust.com, kivinen@ssh.fi, ipsec@tis.com, wdm@epoch.ncsc.mil In-Reply-To: Robert Moskowitz's message of Wed, 25 Feb 1998 10:14:55 -0500, <3.0.5.32.19980225101455.0098f950@homebase.htt-consult.com> Subject: Re: Certificate Requesting Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Wed, 25 Feb 1998 10:14:55 -0500 From: Robert Moskowitz When to do this is the question. given performance issues, it might almost be 'smart' to first do a DN exchange and if you don't have the cert cached give a cert-req, or some such. Bob, Just to clarify what you're suggesting here.... Do a DN exchange how? Via an aborted IKE exchange? Or via some other out of band means? The problem is that by the time you do the DN exchange within the current IKE framework, there's no time to do a cert-req without extending the number of round trips, *or* aborting the IKE exchange and trying again. We can do one or the other, but we had better document which, and everyone will need to agree to do it the same way. (And to not log too verbosely aborted IKE exchanges if that's how we decide to do things, etc.) - Ted From owner-ipsec Wed Feb 25 12:31:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA06788 for ipsec-outgoing; Wed, 25 Feb 1998 12:28:39 -0500 (EST) Date: Wed, 25 Feb 1998 12:41:23 -0500 (EST) Message-Id: <199802251741.MAA04085@carp.morningstar.com> From: Ben Rogers To: ipsec@tis.com Subject: Deleting IPsec SA's Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk How do we do this? When sending a Delete message, I only get to include one SPI, which I would assume is the SPI of the SA terminating at my end. But, I'm going on assumption because I can't find anything in the documents which will clarify. Is there no way to tell the remote end that I'm no longer going to be sending him packets under one of his SA's? Do I have to assume that the remote end is smart enough to kill his own SA's when I delete the corresponding ones on my end? This needs to be added to the DOI document. ben From owner-ipsec Wed Feb 25 12:31:44 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA06844 for ipsec-outgoing; Wed, 25 Feb 1998 12:31:38 -0500 (EST) Message-Id: <199802251743.MAA12465@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: Certificate Requesting In-reply-to: Your message of "Wed, 25 Feb 1998 10:14:55 EST." <3.0.5.32.19980225101455.0098f950@homebase.htt-consult.com> Date: Wed, 25 Feb 1998 12:43:22 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Robert" == Robert Moskowitz writes: Robert> After the exchange, one or both systems might not have Robert> established authentication, becuase either the wrong cert and Robert> chain was sent, or the cert chain ended at the root, and did not Robert> proceed along the cross-cert link to the trusted third party Robert> root. Thus there is a need to issue a cert-req and tell the Robert> other party, 'give me a cert plus chain that goes back to one of Robert> these DNs' (either a list of trusted roots, or your CA's root Robert> plus the TTP's root). I think we must permit IKE exchanges to continue until enough certs have been exchanged. :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON Michael Richardson |Network and security consulting and contract programming Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. From owner-ipsec Wed Feb 25 14:10:16 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA07504 for ipsec-outgoing; Wed, 25 Feb 1998 14:08:45 -0500 (EST) Message-Id: <3.0.5.32.19980225141652.00990d70@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 25 Feb 1998 14:16:52 -0500 To: "Theodore Y. Ts'o" From: Robert Moskowitz Subject: Re: Certificate Requesting Cc: "Theodore Y. Ts'o" , wdm@epoch.ncsc.mil, rpereira@TimeStep.com, dharkins@cisco.com, greg.carter@entrust.com, kivinen@ssh.fi, ipsec@tis.com, wdm@epoch.ncsc.mil In-Reply-To: <199802251734.MAA27336@dcl.MIT.EDU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 12:34 PM 2/25/98 -0500, Theodore Y. Ts'o wrote: > >Bob, > >Just to clarify what you're suggesting here.... Do a DN exchange how? >Via an aborted IKE exchange? Or via some other out of band means? Via an identification payload of type ID_DER_ASN1_DN, or that is the way I read ISAKMP-08 and DOI-06 (yeah, yeah, got to grap the new DOI...). >The >problem is that by the time you do the DN exchange within the current >IKE framework, there's no time to do a cert-req without extending the >number of round trips, *or* aborting the IKE exchange and trying again. exacticially. >We can do one or the other, but we had better document which, and >everyone will need to agree to do it the same way. (And to not log too >verbosely aborted IKE exchanges if that's how we decide to do things, >etc.) Yes indeed. There seems to be an unintended consequence here that may be for the good. It might be for IPsecond, but I think we can get this exchange to have just enough flexibility to cover real PKI needs (beyond a single CA or at best a single hierarchy), but not enough to hang ourselves. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Wed Feb 25 14:19:06 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA07588 for ipsec-outgoing; Wed, 25 Feb 1998 14:18:45 -0500 (EST) Message-Id: <3.0.2.32.19980225113017.0080eb80@diablo.cisco.com> X-Sender: stuphill@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Wed, 25 Feb 1998 11:30:17 -0800 To: ipsec@tis.com From: Stuart Phillips Subject: shipping equipment to the Hotel Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, The conference is going well. We have had quite a positive response. If you need to ship equipment to the hotel, please use this address: Attn: Terri Perrin Embassy Suites 201 Harrison Oaks Blvd. Cary, NC 27513 tel: 919-677-1840 x2011 The equipment will be in the ballroom Monday morning. Thanks, Stuart ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | Stuart Phillips - Product Manager .|||. .|||. | IOS Security - Secondary Authentication ..:|||||||:...:||||||:..| VoiceMail ...: 408.527.7668 or x(7)7668 ------------------------| Fax .........: 408.526.4952 Cisco Systems, Inc. | E-mail ......: stuphill@cisco.com 170 West Tasman SJ-F | Pager E-Mail.: stuphill@airnote.net San Jose CA 95134-1706 | Pager........: 800.365.4578 http://www.cisco.com | Meeting Maker: Stuart Phillips ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "The greatest secrets are oft carried in the weakest cyphers" Sir Francis Bacon - 1609 AD ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-ipsec Wed Feb 25 16:38:15 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA08622 for ipsec-outgoing; Wed, 25 Feb 1998 16:34:49 -0500 (EST) Message-Id: <3.0.32.19980225134828.009e6210@192.43.161.2> X-Sender: jburke@192.43.161.2 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 25 Feb 1998 13:48:30 -0800 To: ipsec@tis.com, wdm@epoch.ncsc.mil From: John Burke Subject: RE: Certificate Requesting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I want to state a detail because no one has mentioned it in all the discussion on this subject. Greg Carter indicated the problem in his first response on this, but there have been no suggestions for a solution to in ISAKMP to problems noted below. Yes, it would be workable and straightforward to say, "if the last message of an exchange contains a CERTREQ, then this means the exchange is extended, to include replying with a CERT." This just means everyone has to add one state, and make that transition if they send/receive the CERTREQ in the otherwise-last state (not to mention the additional state in an exchange which uses Commit, and the fact that this event would change who needs to set/obey a Commit). However some other things are a problem without additional mechanisms in ISAKMP: o If the Responder's final ID in Main Mode is one the Initiator does not have a Cert for, the Responder has already finished Main Mode and believes the SA is now established; it is not expecting another message. o Same problem if the CERTREQ/CERT are sent in the last messages but the party who gets the CERT finds it inadequate and needs to make another CERTREQ, as when the other end now believes SA is established. To handle these things, ISAKMP would have to state, that the party which sends the last of the basic messages, cannot consider the exchange completed absolutely. How do I deal with the case that perhaps the SA is complete but perhaps the other party finds it must send me a CERTREQ? It occurs to me that if the parties were using Commit, this would give us an absolute indicator of completion of an exchange whose end is indefinite. Roy Pereira began the discussion with this statement and this diagram of a proposed expanded exchange: >Since the CERT_REQ payload can be located in any exchange, it might be >located on the last message; > > Initiator Responder > ---------- ----------- > HDR, SA --> > <-- HDR, SA > HDR, KE, Ni --> > <-- HDR, KE, Nr > HDR*, IDii, [ CERT, ] SIG_I --> > <-- HDR*, IDir, [ CERT, ] SIG_R >[, CERTREQ > [ HDR*, CERT [, CERTREQ] --> > [<-- HDR*, CERT ] ] ] > This diagram illustrates this point; Responder here believes it is done after sending the ID, but more is coming. From owner-ipsec Thu Feb 26 01:08:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA11896 for ipsec-outgoing; Thu, 26 Feb 1998 01:04:53 -0500 (EST) Message-Id: <3.0.3.32.19980225222304.0092d480@netcom.com> X-Sender: andrade@netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Wed, 25 Feb 1998 22:23:04 -0800 To: "Steven M. Bellovin" From: Alex Alten Subject: Re: IPSEC WORKING GROUP LAST CALL Cc: ipsec@tis.com In-Reply-To: <3.0.3.32.19980223015228.0094f770@127.0.0.1> References: <3.0.3.32.19980222171305.0094a630@netcom.com> <199802202027.PAA03149@jekyll.piermont.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 01:52 AM 2/23/98 +0000, Steven M. Bellovin wrote: >At 05:13 PM 2/22/98 -0800, Alex Alten wrote: >>IPSEC WG, >> >>These are my main technical criticisms of the current set of IPSEC >>documents. >> >>1. No data recovery of an encrypted IP datagram payload. >> >> Regardless of the merits of the design by not supporting this >> requirement it will probably kill IPSEC as a viable Internet >> standard. > >This is a feature, not a bug, by strong consensus of not just the working >group, but also the entire security area. > >You are, of course, free to buy IPsec software from vendors who implement >some form of key recovery, if that meets you operational or philosophical >needs. We chose not to standardize something like that -- the IETF is an >international group; in our judgment, the best technical results are >obtained by not implementing such features, especially for communications >protocols. See RFC 1984 for the IAB's and IESG's views on the subject. I understand this. I am certain that this requirement will not change for the forseeable future, regardless of our consensus. I am also certain that this requirement can be met, in a manner that would satisfy our community, and still be technically excellent. I strongly feel that it should be an integral part of the IPSEC design to ensure interoperability and to help product vendors meet the requirement. >> >> >>2. Interoperability requirement not met. >> >> To ensure interoperability only one cryptographic mechanism should >> specified, and no others should be allowed. The current proposal >> allows an unlimited variety to be used, it seems primarily to allow >> the standard to scale cryptographic strength upwards. The requirement >> for DES-CBC to be always implemented cannot be met because objection >> #1 cannot be met with it. Probably RC4 with 40b keys will become >> the de facto interoperable mechanism (this has happened to SSL). > >To promote interoperability, a minimum set of algorithms was specified. >Designing a mechanism that only permitted one to be used is very unsound, >from a cryptographic perspective. > I disagree with you. The US electronic funds transfer network has used only one cipher for over 20 years. From a software engineering perspective allowing more than one is a poor design, leading to unnecessary complexity and making interoperability much more difficult. >> >> >>3. IPSEC does not properly fit with the IP routing model. >> >> It force fits the concept of a security session (SA) onto the IP >> datagram routing model. Certainy the concept of a user id does >> not fit the IP address model. The requirement that AH must know >> about the IP header structure breaks the general rule of protocol >> layering. > >The concept of an SA is necessary if one ever wishes to rekey. The >desire for user-oriented keying, though somewhat controversial, is at >least partially driven by some of the results in a paper of mine ("Problems >with the IP Security Protocols"; see the bibliographies or check >http://www.research.att.com/~smb/papers/badesp.{ps,pdf}). I think >you're right about the AH design; others felt differently. > I am very uncomfortable with the use of SA for end-to-end hosts (assuming an intervening set of routers). This is more of a transport service. The SP3 you mentions sounds like it might be a good model. Do you have a URL to a description of it? >> >> >>4. The design is too complex >> >> This design seems to have been driven primarily by the following. >> ... >> >> B. The desire to use a proven cipher, i.e. DES. >> >> This decision has had a profound impact on the design. Because >> DES is slow, it has forced encryption & decryption to the edge >> hosts, requiring the SA construct to allow the packets to traverse >> intervening routers. This slowness also contributed to the >> decision to create AH. Choosing it has forced the need to handle pad >> & IV bytes within the IP payload, increasing protocol stack complexity >> when handling the mapping between clear and encrypted payloads. There >> are many excellent high performance ciphers available many of them do >> not require IV's or pad bytes. Many of these can be proved to be very >> secure, often in a manner obvious to most competent engineers. > >You seem to be suggesting the use of stream ciphers. Other than DES in >certain modes, there are in reality very few stream ciphers that have >been examined very much. There's only one popular one, RC4 -- and it's >(arguably) proprietary. If you use RC4 with datagram-oriented encryption, >you need a sequence number for each byte. Furthermore, you need to keep >a fair amount of keying state, in case packets arrive out of order. For >further difficulties with stream ciphers, especially if authentication is >not used, see the paper cited above. > I wasn't thinking of stream ciphers. You are right, there are tradeoffs. >> >> C. The desire to use a public key algorithm. >> >> This decision has also had an impact on the design. Because PK is >> so slow this has also contributed to the use of the SA construct >> instead of other methods which could more closely match how >> IP routing really works. It makes the management of trust more >> difficult, for example deleting untrustworthy hosts in a timely >> manner. > >Use of a public key algorithm is an engineering necessity, not a desire. >You receive mail on netcom -- what authority would both my employer and >netcom trust to hold our *private* keys, which is the other alternative? >For a discussion on why public key algorithms are preferable in such >situations, see Whit Diffie's ten year retropsective on public key >cryptography. > Here I think we differ on what the secure IP network model should be. I believe that it should be a resource owned by an organization or a company that wants to control access to it and protect their communications. Hosts and routers are then allowed by the owner to participate by giving them each a key. In this model PK has no advantage and other algorithms outperform it. >> >> D. The desire to distribute policy storage and enforcement. >> >> By distributing policy storage and enforcement across all the >> participating hosts and routers it has made it almost impossible >> to scale this design to very large numbers. > >I'm not entirely certain what you mean here. But why shouldn't policy >be distributed, in a network as heterogeneous as the Internet? Say an organization has 10,000 hosts and routers. Should policy be on each and every one of them? How about 100,000 or more? >> >> >>5. The design is incomplete >> >> A. Auditing needs to be completed. At the very least what policy events >> or queries must be specified that can trigger audits. Also for >> interoperability reasons, audit record formats should be specified. > >Since many systems don't have audit abilities, it can't be specified. >Many auditable events are. There may or may not be a need for an >interoperable audit format; if there is, it's well beyond the scope >of this group. It depends on your design. Systems charged with policy enforcement need to audit, the rest don't need to. -- Alex Alten Andrade@Netcom.Com P.O. Box 11406 Pleasanton, CA 94588 USA (510) 417-0159 From owner-ipsec Thu Feb 26 01:23:02 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA11989 for ipsec-outgoing; Thu, 26 Feb 1998 01:22:53 -0500 (EST) Date: Thu, 26 Feb 1998 01:34:41 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Patel, Baiju V" From: Stephen Kent Subject: RE: IPSEC WORKING GROUP LAST CALL Cc: "'ipsec'" Sender: owner-ipsec@ex.tis.com Precedence: bulk Baiju, >I have a concern with AH+ESP in transport mode. >Based on the requirements of ESP, ESP must negotiate >an integrity check mechanism. The MD5-HMAC or SHA-1 HMAC >MUST be supported for ESP. Similarly, the same integrity >algorithms are used by AH. > >Therefore, it looks like I have to compute authentication data >twice using possibly same algorithm over mostly same data. >Something tells me that in this combination, I should be able >to negotiate NULL authentication algorithm for ESP. If you choose to employ BOTH AH and ESP, AND if you elect to use authentication with ESP (which is an option, not a requirement), then you will need to perform two HMAC computations, since the two ICVs cover different portions of the packet. However, a primary reason for not requiring authentication with ESP in all cases is precisely this example. Yes, you should be able to negotiate a null authentication algorithm for use with ESP. >I do understand that DES-CBC values can be used for authentication >data in ESP but then what happens when we are not using DES. Use of DEC-CBC is for encryption, and any authentication benefits are secondary, as far as ESP is concerned. However, if you employ a suitable block cipher base, other algorithms used in CBC mode offer analogous functionality re authentication. Steve From owner-ipsec Thu Feb 26 07:10:16 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA14020 for ipsec-outgoing; Thu, 26 Feb 1998 07:07:53 -0500 (EST) Message-ID: From: "Patel, Baiju V" To: "'Theodore Y. Ts'o'" Cc: "'ipsec'" Subject: RE: IPSEC WORKING GROUP LAST CALL Date: Wed, 25 Feb 1998 16:49:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk I gave transport mode as an example. Same holds for tunnel mode. Correct me if I am wrong, but if I want to protect IP header (from adversary), and want integrity and confidentiality (which is reasonable, I would think), I do not have a choice but to use AH+ESP. This means that I need two authentication digests, one for AH, and other for ESP. Since authentication digest for AH covers everything that authentication digest for ESP covers, and more, I am wasting resources. It is my understanding that if I am doing AH+ESP, first I will encrypt the IP payload, then compute the ESP authentication digest over the encrypted payload, and then add AH header and compute the authentication digest for entire message (including parts of IP header, and encrypted payload of the original message). So, I cannot figure out any value in computing ESP's authentication digest. Baiju > -----Original Message----- > From: Theodore Y. Ts'o [SMTP:tytso@MIT.EDU] > Sent: Wednesday, February 25, 1998 9:31 AM > To: Patel, Baiju V > Cc: 'ipsec' > Subject: Re: IPSEC WORKING GROUP LAST CALL > > From: "Patel, Baiju V" > Date: Tue, 24 Feb 1998 16:01:16 -0800 > > I have a concern with AH+ESP in transport mode. > Based on the requirements of ESP, ESP must negotiate > an integrity check mechanism. The MD5-HMAC or SHA-1 HMAC > MUST be supported for ESP. Similarly, the same integrity > algorithms are used by AH. > > Therefore, it looks like I have to compute authentication data > twice using possibly same algorithm over mostly same data. > Something tells me that in this combination, I should be able > to negotiate NULL authentication algorithm for ESP. > > Why do you want to use both AH and ESP in transport mode in the first > place? What's the desired functionality and application that you're > trying to accomplish? > > - Ted From owner-ipsec Thu Feb 26 07:26:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA14338 for ipsec-outgoing; Thu, 26 Feb 1998 07:25:57 -0500 (EST) Message-Id: <3.0.3.32.19980226123647.009b5a20@127.0.0.1> X-Sender: smb@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 26 Feb 1998 12:36:47 +0000 To: "Patel, Baiju V" From: "Steven M. Bellovin" Subject: RE: IPSEC WORKING GROUP LAST CALL Cc: "'Theodore Y. Ts'o'" , "'ipsec'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 04:49 PM 2/25/98 -0800, Patel, Baiju V wrote: >I gave transport mode as an example. Same holds for >tunnel mode. > >Correct me if I am wrong, but if I want to protect >IP header (from adversary), and want integrity >and confidentiality (which is reasonable, I would think), >I do not have a choice but to use AH+ESP. This means >that I need two authentication digests, one for AH, and >other for ESP. Since authentication digest for AH covers >everything that authentication digest for ESP covers, and more, >I am wasting resources. > >It is my understanding that if I am doing AH+ESP, first I will encrypt >the IP payload, then compute the ESP authentication digest over >the encrypted payload, and then add AH header and compute the >authentication digest for entire message (including parts of IP header, >and encrypted payload of the original message). So, I cannot figure out >any value in computing ESP's authentication digest. No. You could just do ESP in tunnel mode, in which case the inner IP header would be protected. The reason you need to have an authentication field in ESP is that authentication is mandatory under many circumstances, just to protect confidentiality. See http://www.research.att.com/~smb/papers/badesp.ps (or .pdf) for a lot more discussion of that. Given that authentication is basically mandatory, there was no reason to have the overhead of an AH header every time, too. A different question is whether or not ESP should have included the IP header fields in its authentication scope. Frankly, that's the ugliest part of AH; I'm glad it wasn't added to ESP. As I've argued in the past, protection of the IP header is generally irrelevant, but that's neither here nor there at this point. That's an architectural decision that was settled long ago; we're not changing it at this point in the process, I hope. From owner-ipsec Thu Feb 26 10:13:42 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA15483 for ipsec-outgoing; Thu, 26 Feb 1998 10:11:56 -0500 (EST) Message-Id: <199802261429.JAA02728@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-policy-model-00.txt Date: Thu, 26 Feb 1998 09:29:56 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IPSec Policy Data Model Author(s) : P. Bhattacharya, R. Pereira Filename : draft-ietf-ipsec-policy-model-00.txt Pages : 8 Date : 25-Feb-98 This document presents a data model for IPSec policy based on ISAKMP. 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-policy-model-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-policy-model-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-policy-model-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: <19980225155946.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-policy-model-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-policy-model-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980225155946.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Thu Feb 26 10:19:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA15541 for ipsec-outgoing; Thu, 26 Feb 1998 10:18:57 -0500 (EST) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C011D5A72@wade.reo.dec.com> From: Stephen Waters To: ipsec@tis.com Cc: Stephen Waters Subject: IPSEC tunnels and Mobile IP Date: Thu, 26 Feb 1998 15:28:45 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Does IPSEC tunnel mean I can forget about Mobile IP? Here is the Mobile IP model as I understand it: Client----- PPP[IP1]-----NAS/Mobile IP ------ [IP2][stuff][IP1]-----NAS/Mobile IP ---[xxx][IP1]---- client Mobile IP Issue: Client passes Intranet addressed packets to the NAS. I am assuming that VPN customers will want to encrypt their own data. I am also assuming that VPN customers will want to 'hide' their Intranet addresses. To achieve this, the client could use IPSEC ESP, and the NAS/Mobile IP would need to re-encrypt to protect the Intranet address. So, if the customer can do their own tunnel (IPSEC tunnel), why do I need Mobile IP? Well, there seems to be some loss of service going from Mobile IP to IPSEC tunnels : 1) tunnel server address resolution 2) exposure to denial-of-service attacks 3) client needs global Internet address These services COULD be replaced with other solutions - e.g. NAT, Filtering, IPCP or DNS tunnel server address resolution. Any other takes on this? Cheers, Steve. From owner-ipsec Thu Feb 26 10:43:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA15765 for ipsec-outgoing; Thu, 26 Feb 1998 10:42:59 -0500 (EST) X-Authentication-Warning: zoo.utoronto.ca: u_spsys set sender to spenford!henry using -f To: Alex Alten Cc: ipsec@tis.com Subject: Re: IPSEC WORKING GROUP LAST CALL From: Henry Spencer Date: Thu, 26 Feb 1998 10:48:28 -0500 (EST) Message-ID: Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>1. No data recovery of an encrypted IP datagram payload. >>This is a feature, not a bug, by strong consensus... > >I understand this. I am certain that this requirement will not change for >the forseeable future, regardless of our consensus. I am also certain that >this requirement can be met, in a manner that would satisfy our community... A significant fraction of the community will not be satisfied by any protocol which incorporates key recovery. The objection is not to the technical details of key recovery, but to its presence in any form. Key recovery is readily added by separate mechanisms, e.g. a separate key-escrow system, but is not readily removed if it is present in the central protocol. >>> C. The desire to use a public key algorithm. >>Use of a public key algorithm is an engineering necessity, not a desire. > >Here I think we differ on what the secure IP network model should be. >I believe that it should be a resource owned by an organization or a >company that wants to control access to it and protect their >communications... What of two organizations which wish to limit access to, and protect, their inter-organization communications? This is not an imaginary example: the auto industry has been pushing IPSEC, because the car manufacturers want secure electronic communication with their part suppliers. Note that the pattern of trust and non-trust here is complex, and probably could not be satisfied by a single key authority or a small number of them: many of the companies involved are competitors, and the supplier relationship is a complex dynamic directed graph, not a simple fixed tree. Any attempt to solve this with private keys ends up inventing something vaguely analogous to a public-key system, but more complex and with more vulnerabilities. IPSEC, like IP, is not just for single-organization private networks. A *general-purpose* cryptographic security system must use public-key technology. Henry Spencer henry%spenford@zoo.toronto.edu From owner-ipsec Thu Feb 26 11:19:15 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA16168 for ipsec-outgoing; Thu, 26 Feb 1998 11:17:59 -0500 (EST) Message-Id: <3.0.5.32.19980226100710.00971680@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) X-Priority: 2 (High) Date: Thu, 26 Feb 1998 10:07:10 -0500 To: Stuart Phillips , ipsec@tis.com From: Robert Moskowitz Subject: Re: shipping equipment to the Hotel In-Reply-To: <3.0.2.32.19980225113017.0080eb80@diablo.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 11:30 AM 2/25/98 -0800, Stuart Phillips wrote: Stu, Can you please send me the vendor list/subnet assignment? I need this to develop the test recording templet. > >The conference is going well. We have had quite a positive response. > >If you need to ship equipment to the hotel, please use this address: > >Attn: Terri Perrin >Embassy Suites >201 Harrison Oaks Blvd. >Cary, NC 27513 >tel: 919-677-1840 x2011 > > >The equipment will be in the ballroom Monday morning. > >Thanks, > >Stuart > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > | | | Stuart Phillips - Product Manager > .|||. .|||. | IOS Security - Secondary Authentication >..:|||||||:...:||||||:..| VoiceMail ...: 408.527.7668 or x(7)7668 >------------------------| Fax .........: 408.526.4952 >Cisco Systems, Inc. | E-mail ......: stuphill@cisco.com >170 West Tasman SJ-F | Pager E-Mail.: stuphill@airnote.net >San Jose CA 95134-1706 | Pager........: 800.365.4578 >http://www.cisco.com | Meeting Maker: Stuart Phillips >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >"The greatest secrets are oft carried in the weakest cyphers" > Sir Francis Bacon - 1609 AD >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Thu Feb 26 12:12:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA16827 for ipsec-outgoing; Thu, 26 Feb 1998 12:12:03 -0500 (EST) Message-ID: <34F5A524.D3E1C7C2@nt.com> Date: Thu, 26 Feb 1998 12:23:48 -0500 From: "Marcus Leech" Organization: Nortel Technology, Messaging and Security Infrastructure X-Mailer: Mozilla 4.04 [en] (X11; U; HP-UX A.09.05 9000/712) MIME-Version: 1.0 To: Henry Spencer , ipsec@tis.com Subject: Re: IPSEC WORKING GROUP LAST CALL References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Henry Spencer wrote: > > >>> C. The desire to use a public key algorithm. > >>Use of a public key algorithm is an engineering necessity, not a desire. > > > >Here I think we differ on what the secure IP network model should be. > >I believe that it should be a resource owned by an organization or a > >company that wants to control access to it and protect their > >communications... > > What of two organizations which wish to limit access to, and protect, > their inter-organization communications? This is not an imaginary > example: the auto industry has been pushing IPSEC, because the car > manufacturers want secure electronic communication with their part > suppliers. Note that the pattern of trust and non-trust here is complex, > and probably could not be satisfied by a single key authority or a small > number of them: many of the companies involved are competitors, and the > supplier relationship is a complex dynamic directed graph, not a simple > fixed tree. Any attempt to solve this with private keys ends up inventing > something vaguely analogous to a public-key system, but more complex and > with more vulnerabilities. > > IPSEC, like IP, is not just for single-organization private networks. > A *general-purpose* cryptographic security system must use public-key > technology. > In fact, for single-organization networks of larger than, perhaps, a couple of nodes, the only workable, acceptable key-management mechanism uses public-keys. Intercompany/interenterprise is not the only reason driving technical leaders in the security community towards public-key mechanisms. I'll agree with the original poster that the choice of public-key based algorithms carries with it a not-insignificant computing burden. Careful operational engineering can alleviate most of those problems. -- ---------------------------------------------------------------------- Marcus Leech Mail: Dept 8M86, MS 012, FITZ Systems Security Architect Phone: (ESN) 393-9145 +1 613 763 9145 Messaging and Security Infrastructure Fax: (ESN) 395-1407 +1 613 765 1407 Nortel Technology mleech@nortel.ca -----------------Expressed opinions are my own, not my employer's------ From owner-ipsec Thu Feb 26 15:13:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA18059 for ipsec-outgoing; Thu, 26 Feb 1998 15:11:09 -0500 (EST) Message-ID: From: Roy Pereira To: "'ben@Ascend.COM'" Cc: "'IPSEC Mailing List (E-mail)'" , "'VPN Mailing List (E-mail)'" Subject: RE: IPSec Policy Model draft Date: Thu, 26 Feb 1998 15:56:13 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Thank you for your kind words. We hope to extend the document to include how this base IPSec policy would be used with actual topology objects. >-----Original Message----- >From: Ben Rogers [SMTP:ben@Ascend.COM] >Sent: Monday, February 23, 1998 4:40 PM >To: Roy Pereira >Cc: IPSEC Mailing List (E-mail); VPN Mailing List (E-mail) >Subject: IPSec Policy Model draft > >Roy Pereira writes: >> >> Internet Engineering Task Force R. Pereira, TimeStep Corp. >> IP Security Working Group P. Bhattacharya, IBM Corp. > >> IsakmpDescriptor ::= >> SEQUENCE { >> exchange ENUMERATED { >> MainMode, >> AggressiveMode } OPTIONAL, >> proposal SEQUENCE OF IsakmpProposal >> } >> >> o The main ISAKMP object mainly includes proposals, but also >> includes which exchange to utilize. AggressiveMode does not >> hide the identity of the negotiating peers, while MainMode does. >> Please refer to [Harkins98] for a more complete reference to >> both of these two exchange modes. >> >> The exchange mode MAY not be included in this object since it >> MAY instead depend on the peers. >> >> o The proposals are all taken as logical ORs when presented >> together. > >Thank you both for such a clear and concise document! Even though I >wasn't entirely familiar with the notation, I quickly found the text >well organized, unambiguous and simple to understand. It took me less >than 5 minutes to read and digest the contents of the document. This >draft should be a model for future draft authors. > > >ben > From owner-ipsec Thu Feb 26 15:19:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA18105 for ipsec-outgoing; Thu, 26 Feb 1998 15:18:08 -0500 (EST) Message-ID: From: Roy Pereira To: "'Daniel Harkins'" Cc: "'Greg Carter'" , "'IPSEC Mailing List (E-mail)'" Subject: RE: Certificate Requesting Date: Thu, 26 Feb 1998 16:02:52 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk The extra round trip was because we don't know that we do not have that certificate because we do not have the ID yet. This scenario was put forth by Rob Adams at the IPSec CA meeting and I do see his point. IP Address are usually not good enough to find a certificate, thus we must wait for the ID. >-----Original Message----- >From: Daniel Harkins [SMTP:dharkins@cisco.com] >Sent: Monday, February 23, 1998 4:18 PM >To: Roy Pereira >Cc: 'Greg Carter'; 'IPSEC Mailing List (E-mail)' >Subject: Re: Certificate Requesting > > Roy, > >> The additional exchange scenario that you do not agree with only happens >> if the initiator does not send a certificate and the responder does not >> have it. The responder will then append a CertReq payload to the ISAKMP >> message. If the initiator receives the CertReq in the sixth message of >> MainMode (RSA_SIG), then he must reply back with his certificate in a >> MainMode message. He may also append a CertReq to that message if the >> responder did not include a certificate in the sixth message and he does >> not have it. This would force the responder to reply back with his >> certificate. >> >> This scenario was brought forth by a rather large software corporation >> since this is what they do in their IPSec implementation. >[snip] > > Perhaps I'm missing something here but you're asking for the cert's >too late. You need them to verify the signature but you're not asking >for them until you've already, presumably, authenticated your security >association by checking the peer's signature. > >>> Initiator Responder >>> ---------- ----------- >>> HDR, SA --> >>> <-- HDR, SA >>> HDR, KE, Ni --> >>> <-- HDR, KE, Nr >>> HDR*, IDii, [ CERT, ] SIG_I --> >>> <-- HDR*, IDir, [ CERT, ] SIG_R[, >>>CERTREQ >>> [ HDR*, CERT [, CERTREQ] --> >>> [<-- HDR*, CERT ] ] ] >>> > >If the Initiator didn't send his cert in his 3rd message then the >responder wouldn't be able to verify his signature and would abort >the communication. Why not send a CERTREQ in the 2nd messages. That >way you're still keeping a modicum of identity protection (sending it >in the 1st messages requires the other party to respond with his cert >in the clear). > >At the point you're sending the KE and nonce payloads you know what your >authentication method is. If it's signature based and you don't have a >cert for the peer (granted it's tough to know if you do since all you have >to go on at that point is IP address and not everyone will be encoding an >IP address in their certs) send the CERTREQ then. > >Why the need for the extra round trip? And the suspension of authentication >and retention of state? Am I missing something here? > > Dan. > From owner-ipsec Fri Feb 27 07:24:07 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA24483 for ipsec-outgoing; Fri, 27 Feb 1998 07:17:13 -0500 (EST) Message-ID: <19980226165832.22709@hazel> Date: Thu, 26 Feb 1998 16:58:32 -0500 From: Raul Miller To: Stephen Waters , ipsec@tis.com Subject: Re: IPSEC tunnels and Mobile IP Mail-Followup-To: Stephen Waters , ipsec@tis.com References: <250F9C8DEB9ED011A14D08002BE4F64C011D5A72@wade.reo.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C011D5A72@wade.reo.dec.com>; Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen Waters wrote: > So, if the customer can do their own tunnel (IPSEC tunnel), why do I > need Mobile IP? Client should have at least two ip addresses for Mobile IP under IPSEC. One is a fixed address and is used inside the client's tunnel. The other may vary with location and would be used to establish the client's tunnel. You still need something like the NAS for a remote machine to hook up with the current instance of the client's tunnel. -- Raul From owner-ipsec Fri Feb 27 10:21:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA26081 for ipsec-outgoing; Fri, 27 Feb 1998 10:19:20 -0500 (EST) Message-Id: <3.0.5.32.19980227102904.0099ade0@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 27 Feb 1998 10:29:04 -0500 To: Stephen Waters , ipsec@tis.com From: Robert Moskowitz Subject: Re: IPSEC tunnels and Mobile IP Cc: Stephen Waters In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C011D5A72@wade.reo.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 03:28 PM 2/26/98 -0000, Stephen Waters wrote: > >Does IPSEC tunnel mean I can forget about Mobile IP? IMNSHO, Mobile IP is for mobile units. ie cars, tanks, soldiers, and pedestrians. A notebook I plug into a phone jack in a hotel, car dealer, or conference LAN does not need Mobile IP, only IPsec. In IPsecond when we add something like draft-ietf-ipsec-isakmp-mode-cfg-02.txt, IPsec will have a straight-forward model for 'road warrior'. Of course, Mobile IP needs IPsec for solid security... >Here is the Mobile IP model as I understand it: > > >Client----- PPP[IP1]-----NAS/Mobile IP ------ >[IP2][stuff][IP1]-----NAS/Mobile IP ---[xxx][IP1]---- client > > > >Mobile IP Issue: Client passes Intranet addressed packets to the NAS. > >I am assuming that VPN customers will want to encrypt their own data. I >am also assuming that VPN customers will want to 'hide' their Intranet >addresses. To achieve this, the client could use IPSEC ESP, and the >NAS/Mobile IP would need to re-encrypt to protect the Intranet address. > >So, if the customer can do their own tunnel (IPSEC tunnel), why do I >need Mobile IP? > >Well, there seems to be some loss of service going from Mobile IP to >IPSEC tunnels : > >1) tunnel server address resolution >2) exposure to denial-of-service attacks >3) client needs global Internet address > >These services COULD be replaced with other solutions - e.g. NAT, >Filtering, IPCP or DNS tunnel server address resolution. > >Any other takes on this? >Cheers, Steve. > Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Fri Feb 27 14:22:00 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA28144 for ipsec-outgoing; Fri, 27 Feb 1998 14:20:24 -0500 (EST) Date: Fri, 27 Feb 1998 14:32:33 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199802271932.OAA23424@earth.hpc.org> To: rgm-sec@htt-consult.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199802271543.IAA13242@baskerville.CS.Arizona.EDU> Subject: Re: IPSEC tunnels and Mobile IP Sender: owner-ipsec@ex.tis.com Precedence: bulk > IMNSHO, Mobile IP is for mobile units. ie cars, tanks, soldiers, and > pedestrians. A notebook I plug into a phone jack in a hotel, car dealer, > or conference LAN does not need Mobile IP, only IPsec. While not disagreeing in principle, I'd like to note that there is tremendous utility in using a dynamically assigned IP address from the wireless provider and setting up IPSEC tunneling associations authenticated by user identity. In this way, a laptop can be mobile throughout a large wireless service structure and maintain secure connections without the necessity for level 3 handoffs. Hilarie From owner-ipsec Fri Feb 27 14:51:46 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA28414 for ipsec-outgoing; Fri, 27 Feb 1998 14:51:19 -0500 (EST) Date: Fri, 27 Feb 1998 14:51:19 -0500 (EST) From: owner-ipsec@ex.tis.com Message-Id: <199802271951.OAA28414@portal.ex.tis.com> Fri, 27 Feb 1998 14:48:19 -0500 (EST) Message-ID: From: "Patel, Baiju V" To: "'Stephen Kent'" , "Patel, Baiju V" Cc: "'ipsec'" Subject: RE: IPSEC WORKING GROUP LAST CALL Date: Fri, 27 Feb 1998 11:12:12 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk Steve Kent writes: If you choose to employ BOTH AH and ESP, AND if you elect to use authentication with ESP (which is an option, not a requirement), then you will need to perform two HMAC computations, since the two ICVs cover different portions of the packet. However, a primary reason for not requiring authentication with ESP in all cases is precisely this example. Yes, you should be able to negotiate a null authentication algorithm for use with ESP. Steven M. Bellovin [smb@research.att.com] writes: No. You could just do ESP in tunnel mode, in which case the inner IP header would be protected. The reason you need to have an authentication field in ESP is that authentication is mandatory under many circumstances, just to protect confidentiality. My comments: If I read above statements carefully, it seems that Steve Bellovin is saying that authentication is mandatory for ESP which is different from what Steve Kent says. I have been reading documents to figure out how you can specify not to use authentication with ESP Here are the values allowed for AH transforms in DOI spec (by the way in this paragraph, there are two mandatory transforms and not one). 4.4.3 IPSEC AH Transform Identifiers The Authentication Header Protocol (AH) defines one mandatory and several optional transforms used to provide authentication, integrity, and replay detection. The following table lists the defined AH Transform Identifiers for the ISAKMP Proposal Payload for the IPSEC DOI. Transform ID Value ------------ ----- RESERVED 0-1 AH_MD5 2 AH_SHA 3 AH_DES 4. I do not see an AH NULL here. ESP specs to not have authentication data optional. therefore, we do need this field. If we indeed managed to specify null authentication what will be the length of this field and what would we put there. there is also a broader question here. If you do not need AH+ESP in tunnel mode, what is the drawback of using ESP with tunnel mode to achieve equivalent functionality of AH+ESP in transport mode (the packet sizes are same anyway, and both protect IP headers). Unless there is a convincing argument to use AH+ESP in transport mode over ESP in tunnel mode, why don't we scrap AH+ESP from the requirements. Baiju 4.4.3 IPSEC AH Transform Identifiers The Authentication Header Protocol (AH) defines one mandatory and several optional transforms used to provide authentication, integrity, and replay detection. > -----Original Message----- > From: Stephen Kent [SMTP:kent@bbn.com] > Sent: Wednesday, February 25, 1998 10:35 PM > To: Patel, Baiju V > Cc: 'ipsec' > Subject: RE: IPSEC WORKING GROUP LAST CALL > > Baiju, > > >I have a concern with AH+ESP in transport mode. > >Based on the requirements of ESP, ESP must negotiate > >an integrity check mechanism. The MD5-HMAC or SHA-1 HMAC > >MUST be supported for ESP. Similarly, the same integrity > >algorithms are used by AH. > > > >Therefore, it looks like I have to compute authentication data > >twice using possibly same algorithm over mostly same data. > >Something tells me that in this combination, I should be able > >to negotiate NULL authentication algorithm for ESP. > > If you choose to employ BOTH AH and ESP, AND if you elect to use > authentication with ESP (which is an option, not a requirement), then > you > will need to perform two HMAC computations, since the two ICVs cover > different portions of the packet. However, a primary reason for not > requiring authentication with ESP in all cases is precisely this > example. > Yes, you should be able to negotiate a null authentication algorithm > for > use with ESP. > > >I do understand that DES-CBC values can be used for authentication > >data in ESP but then what happens when we are not using DES. > > Use of DEC-CBC is for encryption, and any authentication benefits are > secondary, as far as ESP is concerned. However, if you employ a > suitable > block cipher base, other algorithms used in CBC mode offer analogous > functionality re authentication. > > Steve > From owner-ipsec Fri Feb 27 14:59:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA28489 for ipsec-outgoing; Fri, 27 Feb 1998 14:57:20 -0500 (EST) Message-Id: <199802272007.PAA11418@postal.research.att.com> To: ho@earth.hpc.org (Hilarie Orman) cc: rgm-sec@htt-consult.com, ipsec@tis.com Subject: Re: IPSEC tunnels and Mobile IP Date: Fri, 27 Feb 1998 15:07:24 -0500 From: Steve Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk > IMNSHO, Mobile IP is for mobile units. ie cars, tanks, soldiers, and > pedestrians. A notebook I plug into a phone jack in a hotel, car de aler, > or conference LAN does not need Mobile IP, only IPsec. While not disagreeing in principle, I'd like to note that there is tremendous utility in using a dynamically assigned IP address from the wireless provider and setting up IPSEC tunneling associations authenticated by user identity. In this way, a laptop can be mobile throughout a large wireless service structure and maintain secure connections without the necessity for level 3 handoffs. Yes. IP addresses -- especially IP addresses of dial-up clients -- are transient and meaningless. The sooner we get away from them, the better. From owner-ipsec Fri Feb 27 15:06:52 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA28568 for ipsec-outgoing; Fri, 27 Feb 1998 15:06:21 -0500 (EST) Date: Fri, 27 Feb 1998 12:19:21 -0800 (PST) From: Gabriel Montenegro Reply-To: Gabriel Montenegro Subject: Re: IPSEC tunnels and Mobile IP To: ipsec@tis.com In-Reply-To: "Your message with ID" <199802271932.OAA23424@earth.hpc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > > IMNSHO, Mobile IP is for mobile units. ie cars, tanks, soldiers, and > > pedestrians. A notebook I plug into a phone jack in a hotel, car dealer, > > or conference LAN does not need Mobile IP, only IPsec. > > While not disagreeing in principle, I'd like to note that there is > tremendous utility in using a dynamically assigned IP address from the > wireless provider and setting up IPSEC tunneling associations > authenticated by user identity. In this way, a laptop can be mobile > throughout a large wireless service structure and maintain secure > connections without the necessity for level 3 handoffs. > > Hilarie Today, nomadicity as achieved by overloading ISAKMP via the mechanism alluded to by Bob, may seem sufficient. However, as Hilarie points out, there are definite advantages to solutions that incorporate full mobility via a more flexible protocol that only does tunneling establishment. (Of course, data transfer could -- and over the public internet, must -- be done via ISAKMP.) You can get goodies like multi-protocol and switching support, the ability to compose compound tunnels for separate security domains, to virtually appear to be in a given place or places (your office, or another location/domain), to preserve your sessions across interface switching and/or migration, to incrementally move beyond remote access into full mobility ... Maybe not essential, but it could be a compelling competitive advantage... -gabriel From owner-ipsec Fri Feb 27 15:07:26 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA28582 for ipsec-outgoing; Fri, 27 Feb 1998 15:07:20 -0500 (EST) Message-Id: <199802272017.PAA11757@postal.research.att.com> To: ipsec@tis.com Date: Fri, 27 Feb 1998 15:17:38 -0500 From: Steve Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk Fri, 27 Feb 1998 14:48:19 -0500 (EST) Message-ID: From: "Patel, Baiju V" To: "'Stephen Kent'" , "Patel, Baiju V" Cc: "'ipsec'" Subject: RE: IPSEC WORKING GROUP LAST CALL Date: Fri, 27 Feb 1998 11:12:12 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk Steve Kent writes: If you choose to employ BOTH AH and ESP, AND if you elect to us e authentication with ESP (which is an option, not a requirement) , then you will need to perform two HMAC computations, since the two ICVs cover different portions of the packet. However, a primary reason fo r not requiring authentication with ESP in all cases is precisely thi s example. Yes, you should be able to negotiate a null authentication algorithm for use with ESP. Steven M. Bellovin [smb@research.att.com] writes: No. You could just do ESP in tunnel mode, in which case the inner IP header would be protected. The reason you need to have an authentication fie ld in ESP is that authentication is mandatory under many circumstances, just to protect confidentiality. My comments: If I read above statements carefully, it seems that Steve Bellovin is saying that authentication is mandatory for ESP which is different from what Steve Kent says. Let me be very precise here. In most cases, you will want to use authentication with ESP -- so many that the authentication *field* is a standard part of the ESP packet format. Use is optional; you could negotiate not using it. The same applies to the anti-replay counter. But both fields are always present. The paper of mine that I cited earlier explains why you generally should use these services. You can use AH+ESP to protect the IP header, or you could use ESP in tunnel mode, even between two end hosts. While some of us do indeed feel that we should not have two such similar options, there was no consensus on eliminating AH+ESP, or on eliminating AH altogether, in favor of ESP with a null encryption transform. AH with a null algorithm is useless, and hence is not defined. What would its purpose be? There is one other use for AH+ESP -- when the AH security association is to a different endpoint -- say, a firewall -- than the ESP association. From owner-ipsec Fri Feb 27 15:25:44 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA28706 for ipsec-outgoing; Fri, 27 Feb 1998 15:22:20 -0500 (EST) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C011D5A8A@wade.reo.dec.com> From: Stephen Waters To: ipsec@tis.com Subject: LAN-to-LAN IPSEC tunnels over the Internet Date: Fri, 27 Feb 1998 20:33:08 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk I know that the recommendation is for 'block-mode' encryption so that major-damage is not done to the data-stream when the odd packet goes missing. But, for LAN-to-LAN, certain QOS is required anyway (and the carriers and ISPs seem to be working towards offering better services for LAN-to-LAN - i.e. less packet loss and no reordering), so, is there a way of using IPSEC encryption in cipher-stream mode when the service is good enough - I hear this makes the cipher harder to crack. The same is true for compression (IPCOMP), but I'll but that note on the other list. Cheers, Steve. From owner-ipsec Fri Feb 27 15:43:31 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA28843 for ipsec-outgoing; Fri, 27 Feb 1998 15:42:22 -0500 (EST) Message-Id: <3.0.3.32.19980227154932.00a2d100@pophost.gte.com> X-Sender: sjj0@pophost.gte.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 27 Feb 1998 15:49:32 -0500 To: ho@earth.hpc.org (Hilarie Orman), rgm-sec@htt-consult.com From: Stuart Jacobs Subject: Re: IPSEC tunnels and Mobile IP Cc: ipsec@tis.com In-Reply-To: <199802271932.OAA23424@earth.hpc.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I would disagree on the point about not needing mobile IP in a hotel room. There is a good reason why a hotel should offer support for visiting laptop, $$$. Hotels are already providing enhanced office services to their customers for a fee. Offering Mobile IP would allow them to provide enhanced network access (above dial-up modem speeds) to business meeting attendees, conference gatherings in adition to guests. The only way Mobile IP will get out of the lab and into commercial products and service offerings is by allowing service providers the ability to generate revenues necessitating scaleable, robust authentication and access control for billing purposes. Stu At 02:32 PM 2/27/98 -0500, you wrote: >> IMNSHO, Mobile IP is for mobile units. ie cars, tanks, soldiers, and >> pedestrians. A notebook I plug into a phone jack in a hotel, car dealer, >> or conference LAN does not need Mobile IP, only IPsec. > >While not disagreeing in principle, I'd like to note that there is >tremendous utility in using a dynamically assigned IP address from the >wireless provider and setting up IPSEC tunneling associations >authenticated by user identity. In this way, a laptop can be mobile >throughout a large wireless service structure and maintain secure >connections without the necessity for level 3 handoffs. > >Hilarie > > > ========================== Stuart Jacobs CISSP Network Security GTE Laboratories 40 Sylvan Road Waltham, MA 02254 USA telephone: (781) 466-3076 fax: (781) 466-2838 ========================== From owner-ipsec Fri Feb 27 16:19:07 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA29266 for ipsec-outgoing; Fri, 27 Feb 1998 16:18:21 -0500 (EST) Message-Id: <3.0.5.32.19980227132943.00816660@diablo.cisco.com> X-Sender: stuphill@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 27 Feb 1998 13:29:43 -0800 To: ipsec@tis.com From: Stuart Phillips Subject: IPSec Conference Loaner Hardware Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Cisco has arranged for (5) SVGA PC monitors to be available as loaners for the conference. We will also have two IBM PC's setup as test machines for participants to use. We will also have a shared printer set up. All equipment is on a first come-first served basis. Several people asked about having Sun Stations with Solaris, but we currently have none available. If you need to rent PC hardware in Cary: MRC Computer Rentals 919.859.1199 These people seemed real helpful and competent. The price to rent a monitor for the week is only USD $50. Stuart ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | Stuart Phillips - Product Manager .|||. .|||. | IOS Security - Secondary Authentication ..:|||||||:...:||||||:..| VoiceMail ...: 408.527.7668 or x(7)7668 ------------------------| Fax .........: 408.526.4952 Cisco Systems, Inc. | E-mail ......: stuphill@cisco.com 170 West Tasman SJ-F | Pager E-Mail.: stuphill@airnote.net San Jose CA 95134-1706 | Pager........: 800.365.4578 http://www.cisco.com | Meeting Maker: Stuart Phillips ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "The greatest secrets are oft carried in the weakest cyphers" Sir Francis Bacon - 1609 AD ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-ipsec Fri Feb 27 18:04:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA00278 for ipsec-outgoing; Fri, 27 Feb 1998 18:03:21 -0500 (EST) Message-Id: <3.0.32.19980227151729.009f0ac0@192.43.161.2> X-Sender: jburke@192.43.161.2 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 27 Feb 1998 15:17:30 -0800 To: wdm@epoch.ncsc.mil From: John Burke Subject: Re: ISAKMP: Issues Cc: ipsec@tis.com, jburke@cylink.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk It's not clear to me that the mentioned items ALL have to be resolved for the draft to be adequate for approval. Let's avoid changing more than we have to (see interspersed comments). - John Burke At 02:38 PM 2/27/98 EST, wdm@epoch.ncsc.mil (W. Douglas Maughan) wrote: >---------- [ ... ] >Attached is a list of unresolved issues concerning ISAKMP-09. They are >in no particular order. > >I think the first 3 MUST be resolved before moving ahead. >The other 3 can be done later. > >Thanks, > >Doug [ ... ] >Unresolved Issues from ISAKMP-08 to ISAKMP-09 >--------------------------------------------- >1. ISAKMP Message Header Length field and data do not match > > (Matt Thomas - 29 Sep 97 e-mail) > What if the ISAKMP Message Header Length field indicates a > different length than the actual data? Length > Data = no > action?, but Data > Length = Data Ignored or Message Trashed? What is the argument for trashing the message? Leave it unless there is a strong such argument. >2. Resolution of the Certificate Request generation of continued exchange > > Even with all of the discussion that has gone on for the last couple > of days, I don't see anything "concrete". As I proposed on 24 Feb > 98, we can do one of the following: > > 1. Write text stating that the CertReq must be sent prior to > the last message of an exchange > > 2. Change ISAKMP to allow the extended exchange for CertReq > (and potentially other payloads?) > > 3. Something else - like saying that the Commit Bit of the > Flags field can be used to extend the CertReq continued > exchange More precisely, about the Commit option: Party A has to send a Commit bit, to give itself the opportunity to send more after Party B sends the final message of the exchange proper. Options 1 and 2 leave some of the stated problems unsolved. >3. Alignment of ISAKMP messages > > (Matt Thomas - 18 Feb 98 e-mail > Can't align message on 4-byte boundary > Align Attribute Tag fields of Transform payload > (John Burke - 19 Feb 98 e-mail) > Not possible for ISAKMP to demand alignment of a message. State > explicitly that any payload can be of arbitrary length, > depending on the content of previous payloads I hope we are not contemplating introducing alignments where none were before. >4. Negotiation of SA Response Attribute List - Should it be allowed? > > (John Burke - 1 Oct 97 e-mail) > Allow within context of DOI specific rules > > NOTE: Current method is send Info Exchange with Notify Payload I would rather rescind this suggestion at this late date. For IPSecond, yes, but now, no. The DOI's Lifetime Notification may seem a cumbersome alternative to this, but it has the benefit of working and having passed without objections from the list. By the way has anyone implemented sending this Notification? From owner-ipsec Fri Feb 27 18:31:09 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA00454 for ipsec-outgoing; Fri, 27 Feb 1998 18:30:20 -0500 (EST) Message-Id: <3.0.32.19980227154513.009f1be0@192.43.161.2> X-Sender: jburke@192.43.161.2 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 27 Feb 1998 15:45:14 -0800 To: wdm@epoch.ncsc.mil From: John Burke Subject: Re: ISAKMP Draft: Notifications about Phase II Cc: ipsec@tis.com, jburke@cylink.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Doug, The question of the use of the Message ID in a Notification is still not addressed, and I see it as still an opportunity for interoperation failure. The question is, does one ever use the Message ID to locate the SA which is being notified? I believe the answer is no; I think there was discussion on this subject some time ago and this was the concensus; but I'm not sure. What I think I remember people asking was this: if the Responder to QM cannot decode a good SPI from the message, is there any means to give notification at all? And people answered, no, because the Message ID does not identify the affected exchange. I'm not claiming precise memory; I'm asking others to weigh in on this. - John Burke At 01:48 PM 2/19/98 -0800, I wrote: >Doug, two suggestions for ISAKMP v-09 to bring it into line with the IP DOI >and what I believe to be implementors' current understanding and working code: > >Notification Codes > [ ... ] >The Phase II description asserts that Message ID identifies the session. > > Notification which occurs during, or is concerned with, a Phase 2 nego- > tiation is identified by the Initiator and Responder cookie pair in the > ISAKMP Header and the Message ID and SPI associated with the current nego- > tiation. > >This would require that the notification be sent as part of the Quick Mode >exchange; but between ISAKMP v-08 and IKE (was "Resolution"), I understand >that all Notifications are supposed to be sent as an Informational >Exchange; it is asserted that an exchange prescribes exactly what messages >and payloads are permissible, and no exchanges have a place for >Notifications, particularly, a Notification returned in reply to the final >message sent. An exception is that the IP DOI prescribes additional Status >Notifications and prescribes they get combined into the standard exchange >messages. > >My understanding, which I am not at all sure reflects current practice: > > Notification which occurs during, or is concerned with, a Phase 2 nego- > tiation is identified by a current Initiator and Responder cookie pair > in the ISAKMP Header, and the protocol and SPI associated with the > affected negotiation. The Message ID of the ISAKMP header DOES NOT > identify the negotiation targetted by the Notification. > >Other people may have different understandings of the above. If so, I hope >they'll speak now; we may all have to resolve differences where we are not >be interoperable. [wups! wool-gathering?] From owner-ipsec Fri Feb 27 18:34:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA00505 for ipsec-outgoing; Fri, 27 Feb 1998 18:34:21 -0500 (EST) Date: Fri, 27 Feb 1998 15:48:01 -0800 From: mark@mentat.com (Marc Hasson) Message-Id: <199802272348.PAA16420@orna.mentat.com> To: ipsec@tis.com Subject: ESP - authenticationless OR encryptionless? X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk smb@research.att.com wrote: > Let me be very precise here. In most cases, you will want to use > authentication with ESP -- so many that the authentication *field* is a > standard part of the ESP packet format. Use is optional; you could > negotiate not using it. The same applies to the anti-replay counter. > But both fields are always present. The paper of mine that I cited ???? The authentication data field is an optional field for ESP, the counter is mandatory. The text below is from the latest ESP concerning the authentication data field: 2.7 Authentication Data The Authentication Data is a variable-length field containing an Integrity Check Value (ICV) computed over the ESP packet minus the Authentication Data. The length of the field is specified by the authentication function selected. The Authentication Data field is optional, and is included only if the authentication service has been selected for the SA in question. The authentication algorithm specification MUST specify the length of the ICV and the comparison rules and processing steps for validation. Now that we've reestablished once again that authentication is optional for ESP whats the story with encryption? My reading of the latest ESP and architecture specifications was that an encryption algorithm was mandatory. But just noticed that in the latest DOI-07 (and earlier as well) the following: 4.4.4.1 ESP_NULL The ESP_NULL type specifies no confidentiality is to be provided by ESP. ESP_NULL is used when ESP is being used to tunnel packets which require only authentication and integrity protection. See the Auth Algorithm attribute description in Section 4.5 for additional requirements relating to the use of ESP_NULL. (And below in 4.5 the ESP_NULL reference has the following.) When negotiating ESP without authentication, the Auth Algorithm attribute MUST NOT be included in the proposal. When negotiating ESP without confidentiality, the Auth Algorithm attribute MUST be included in the proposal and the ESP transform ID must be ESP_NULL. So, are both the ESP and DOI documents correct? Is the DOI document merely anticipating the (future?) submission of a standard ESP NULL "encryption" transform? Has anyone submitted a draft for that yet? I assume no padding or IV is needed, the (unmodified) payload would be moved in following the ESP header, and the ESP header and trailer fields are otherwise present/used, as normal. It would be a pretty simple spec. though it may "break" statements we have in some docs such as "ESP always provides confidentiality for traffic". I also ask because apparently ESP_NULL has been mentioned for the IPSEC interop next week and I don't have any pointer to ESP_NULL, except the description above. Can someone confirm that what I wrote is what some folks plan on testing next week for ESP_NULL? Thanks... -- Marc -- From owner-ipsec Fri Feb 27 19:59:54 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA00987 for ipsec-outgoing; Fri, 27 Feb 1998 19:57:26 -0500 (EST) Message-ID: <34F763D1.167E@cs.umass.edu> Date: Fri, 27 Feb 1998 20:09:37 -0500 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V4.0 alpha) MIME-Version: 1.0 To: "D. Hugh Redelmeier" CC: IP Security List Subject: Re: comments on draft-ietf-ipsec-isakmp-oakley-06.txt References: <199802240334.WAA11835@mimosa.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk D. Hugh Redelmeier writes: > Section 5.5 describes how to cook up more keying material, if it is > needed: > > For situations where the amount of keying material desired is greater > than that supplied by the prf, KEYMAT is expanded by feeding the > results of the prf back into itself and concatenating results until > the required keying material has been reached. In other words, > > I'm not a cryptographer, but... This sounds like something for > nothing. What are the cryptographic implications of generating extra > keying material this way? I think that the document should address > this question. The expansion technique increases the _length_, not the _strength_, of the keying material. I'm inferring that you thought Sec. 5.5 purported to increase both, thus gaining "something for nothing". The feedback loop through the PRF is intended to spread the entropy of the seed keying material through the sequel. (I'm vigorously waving my hands here.) -- Lewis http://www.cs.umass.edu/~lmccarth/ "In our opinion provable security is nothing more than a phantom, similar to the perpetuum mobile in thermodynamics." -- Joan Daemen, 1995 From owner-ipsec Fri Feb 27 20:03:51 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA01048 for ipsec-outgoing; Fri, 27 Feb 1998 20:02:21 -0500 (EST) Message-Id: <199802280115.UAA09853@istari.sandelman.ottawa.on.ca> To: Stuart Jacobs CC: ipsec@tis.com Subject: Re: IPSEC tunnels and Mobile IP In-reply-to: Your message of "Fri, 27 Feb 1998 15:49:32 EST." <3.0.3.32.19980227154932.00a2d100@pophost.gte.com> Date: Fri, 27 Feb 1998 20:15:14 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Stuart" == Stuart Jacobs writes: Stuart> I would disagree on the point about not needing mobile IP in a Stuart> hotel room. There is a good reason why a hotel should offer Stuart> support for visiting laptop, $$$. Hotels are already providing Stuart> enhanced office services to their customers for a fee. Offering Stuart> Mobile IP would allow them to provide enhanced network access Stuart> (above dial-up modem speeds) to business meeting attendees, Stuart> conference gatherings in adition to guests. The point is that, given ubiquitus IPsec (which we all agree one needs to make mobile IP safe) mobile IP doesn't give a lot unless you move around a lot, and/or have some kind of long lived connections. IPsec with tunnel mode back to one's corporate firewall, with a private network address on the inside is very much like mobile IP. If you don't move too often, then DHCP or PPP address assignment (for a new site specific address), and a new ISAKMP negotiation is enough. Where mobile IP wins is when you are not wired and you are moving around a lot relative to the length of your sessions. I'm not sure that there are a lot of real life applications for this in 1998. However, digital cell technology is building smaller and lower power cells, and IP will go into phones, robot vacuum cleaners and public transit vehicles and airplanes, so the definition of "lot" will change. I find, without ubiquitous IPsec to give me that constant IP in the tunnel, that my NetBSD notebook is for all intensive purposes mobile: it does DHCP on any network I plug it into (or detects the default routers on networks that don't have DHCP), and my TCP sessions are generally short enough (POP over SSH, SMTP, HTTP) that I never worry about keeping the same IP address. :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON Michael Richardson |Network and security consulting and contract programming Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNPdlINiXVu0RiA21AQHgdAL7BjZAXwbLhIr/2j8/SoPpv02hnFyZ0Nfb ZufyW48r2AV4sFmK2SCgolUp5lMLb80P7hBxYOFvnTdmChSOcKwF+37o0i206+X0 XCFMPOtlDzZlD6tom78oJsiI0iAL+5lE =/SO8 -----END PGP SIGNATURE----- From owner-ipsec Fri Feb 27 20:43:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA01275 for ipsec-outgoing; Fri, 27 Feb 1998 20:41:20 -0500 (EST) Message-ID: <34F76E1D.2781@cs.umass.edu> Date: Fri, 27 Feb 1998 20:53:33 -0500 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V4.0 alpha) MIME-Version: 1.0 To: Alex Alten CC: IP Security List Subject: Re: IPSEC WORKING GROUP LAST CALL References: <3.0.3.32.19980222171305.0094a630@netcom.com> <199802202027.PAA03149@jekyll.piermont.com> <3.0.3.32.19980225222304.0092d480@netcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Alex Alten writes: > Here I think we differ on what the secure IP network model should be. > I believe that it should be a resource owned by an organization or a > company that wants to control access to it and protect their > communications. Hosts and routers are then allowed by the owner to > participate by giving them each a key. In this model PK has no > advantage and other algorithms outperform it. In addition to the comments already made by others: If keys are established over the public network, then AFAIK only PK methods can assure forward secrecy of prior established keys when the authenticating key is compromised. -Lewis From owner-ipsec Fri Feb 27 22:16:19 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA01739 for ipsec-outgoing; Fri, 27 Feb 1998 22:13:30 -0500 (EST) Message-Id: <199802280324.WAA24005@relay.hq.tis.com> To: John Burke cc: wdm@epoch.ncsc.mil, ipsec@tis.com Subject: Re: ISAKMP: Issues In-reply-to: Your message of "Fri, 27 Feb 1998 15:17:30 PST." <3.0.32.19980227151729.009f0ac0@192.43.161.2> Date: Fri, 27 Feb 1998 19:26:16 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk >What is the argument for trashing the message? Leave it unless there is a >strong such argument. It seems to me that if an Key Negotiation protocol that purports to be providing enhanced security receives a malformed message (i.e. the code on the other end "got it wrong"), that the prudent thing to do is to refuse the negotiation under the assumption that the other end probably got other things wrong too. If you can't figure out the size of the message you're sending, how are you ever going to parse the proposals? :-) That's one argument, the other is, perhaps, religious. Without stringent checking of MBZ and the like in wire protocols, it's that much harder to extend them in the future. Derrell From owner-ipsec Sat Feb 28 01:43:12 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA02786 for ipsec-outgoing; Sat, 28 Feb 1998 01:40:21 -0500 (EST) Message-Id: <3.0.3.32.19980227225721.00973710@netcom.com> X-Sender: andrade@netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Fri, 27 Feb 1998 22:57:21 -0800 To: Henry Spencer From: Alex Alten Subject: Re: IPSEC WORKING GROUP LAST CALL Cc: ipsec@tis.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:48 AM 2/26/98 -0500, Henry Spencer wrote: >>>>1. No data recovery of an encrypted IP datagram payload. >>>This is a feature, not a bug, by strong consensus... >> >>I understand this. I am certain that this requirement will not change for >>the forseeable future, regardless of our consensus. I am also certain that >>this requirement can be met, in a manner that would satisfy our community... > >A significant fraction of the community will not be satisfied by any >protocol which incorporates key recovery. The objection is not to the >technical details of key recovery, but to its presence in any form. > My view is that it's just another tool to be used to solve certain types of problems. Whether you realize it or not, we have been outmaneuvered by other communities with different desires. Their position is now being reinforced by members of the industry who are coming up with solutions meeting this requirement. >Key recovery is readily added by separate mechanisms, e.g. a separate >key-escrow system, but is not readily removed if it is present in the >central protocol. You are right, it has to be hooked somehow into each datagram. > >>>> C. The desire to use a public key algorithm. >>>Use of a public key algorithm is an engineering necessity, not a desire. >> >>Here I think we differ on what the secure IP network model should be. >>I believe that it should be a resource owned by an organization or a >>company that wants to control access to it and protect their >>communications... > >What of two organizations which wish to limit access to, and protect, >their inter-organization communications? This is not an imaginary >example: the auto industry has been pushing IPSEC, because the car >manufacturers want secure electronic communication with their part >suppliers. Note that the pattern of trust and non-trust here is complex, >and probably could not be satisfied by a single key authority or a small >number of them: many of the companies involved are competitors, and the >supplier relationship is a complex dynamic directed graph, not a simple >fixed tree. Any attempt to solve this with private keys ends up inventing >something vaguely analogous to a public-key system, but more complex and >with more vulnerabilities. > >IPSEC, like IP, is not just for single-organization private networks. >A *general-purpose* cryptographic security system must use public-key >technology. > Well, let's agree to disagree. My contention is that the establishment of this pattern of trust is equally difficult for PK and symmetric type of ciphers, regardless of whether we are talking about intra- or inter- organization communications. -- Alex Alten Andrade@Netcom.Com P.O. Box 11406 Pleasanton, CA 94588 USA (510) 417-0159 From owner-ipsec Sat Feb 28 01:43:57 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA02828 for ipsec-outgoing; Sat, 28 Feb 1998 01:42:22 -0500 (EST) Message-Id: <3.0.3.32.19980227230000.00977170@netcom.com> X-Sender: andrade@netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Fri, 27 Feb 1998 23:00:00 -0800 To: Lewis McCarthy From: Alex Alten Subject: Re: IPSEC WORKING GROUP LAST CALL Cc: IP Security List In-Reply-To: <34F76E1D.2781@cs.umass.edu> References: <3.0.3.32.19980222171305.0094a630@netcom.com> <199802202027.PAA03149@jekyll.piermont.com> <3.0.3.32.19980225222304.0092d480@netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 08:53 PM 2/27/98 -0500, Lewis McCarthy wrote: >Alex Alten writes: >> Here I think we differ on what the secure IP network model should be. >> I believe that it should be a resource owned by an organization or a >> company that wants to control access to it and protect their >> communications. Hosts and routers are then allowed by the owner to >> participate by giving them each a key. In this model PK has no >> advantage and other algorithms outperform it. > >In addition to the comments already made by others: > >If keys are established over the public network, then AFAIK >only PK methods can assure forward secrecy of prior established >keys when the authenticating key is compromised. True, this is a feature of PK that sets it apart from symmetric ciphers. However, as an engineer, you have to ask yourself, for a particular design is this feature needed? Is this feature more important than it's drawbacks in slow performance, data expansion, and slow key generation? My contention is that for model explained above that this feature is unnecessary. -- Alex Alten Andrade@Netcom.Com P.O. Box 11406 Pleasanton, CA 94588 USA (510) 417-0159 From owner-ipsec Sat Feb 28 01:56:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA02928 for ipsec-outgoing; Sat, 28 Feb 1998 01:55:21 -0500 (EST) Message-Id: <199802280707.XAA11273@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Alex Alten Cc: Henry Spencer , ipsec@tis.com Subject: Re: IPSEC WORKING GROUP LAST CALL In-Reply-To: Your message of "Fri, 27 Feb 1998 22:57:21 PST." <3.0.3.32.19980227225721.00973710@netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Feb 1998 23:07:45 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk > >>>>1. No data recovery of an encrypted IP datagram payload. > >>>This is a feature, not a bug, by strong consensus... > >> > >>I understand this. I am certain that this requirement will not change for > >>the forseeable future, regardless of our consensus. I am also certain that > >>this requirement can be met, in a manner that would satisfy our community... > > > >A significant fraction of the community will not be satisfied by any > >protocol which incorporates key recovery. The objection is not to the > >technical details of key recovery, but to its presence in any form. > > > > My view is that it's just another tool to be used to solve certain types of > problems. Whether you realize it or not, we have been outmaneuvered by other > communities with different desires. It's not really "outmaneuvered"; it's more like conceding the low-ground. The only justification for key recovery in a communications product (as opposed to a stored-data product) is to facillitate evesdropping. We don't want to "solve" that problem-- and in fact don't view lack of key recovery as a problem in the first place! Dan. From owner-ipsec Sat Feb 28 07:30:01 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA04561 for ipsec-outgoing; Sat, 28 Feb 1998 07:21:21 -0500 (EST) Message-Id: <199802281234.HAA07492@tecumseh.altavista-software.com> X-Sender: ljopop@ranier.altavista-software.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Sat, 28 Feb 1998 07:32:37 -0500 To: "Derrell D. Piper" From: Matt Thomas Subject: Re: ISAKMP: Issues Cc: wdm@epoch.ncsc.mil, ipsec@tis.com In-Reply-To: <199802280324.WAA24005@relay.hq.tis.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:26 PM 2/27/98 , Derrell D. Piper wrote: >>What is the argument for trashing the message? Leave it unless there is a >>strong such argument. > >It seems to me that if an Key Negotiation protocol that purports to be >providing enhanced security receives a malformed message (i.e. the code on the >other end "got it wrong"), that the prudent thing to do is to refuse the >negotiation under the assumption that the other end probably got other things >wrong too. If you can't figure out the size of the message you're sending, >how are you ever going to parse the proposals? :-) I think you need to be more careful than that (my vote is to discard the message). I assume that malformed packets are being sent by a malicious entity who doesn't want my key negotiation to succeed. So I drop them and hope to receive a good one in the future. -- Matt Thomas Internet: matt.thomas@altavista-software.com Internet Locksmith WWW URL: AltaVista Internet Software Disclaimer: This message reflects my own Littleton, MA warped views, etc. From owner-ipsec Sat Feb 28 07:51:44 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA04687 for ipsec-outgoing; Sat, 28 Feb 1998 07:48:23 -0500 (EST) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C011D5A91@wade.reo.dec.com> From: Stephen Waters To: Steve Bellovin Cc: ipsec@tis.com, Stephen Waters Subject: RE: IPSEC tunnels and Mobile IP Date: Sat, 28 Feb 1998 12:59:02 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk I agree, but that would need IPV6 to fix someday. I should explain the base meaning behind my original note: I was referring to the use that some have made of Mobile IP for Dial-access VPNs (looks like the L2TP ISP-based model, except both tunnel end-points are within the VPN carriers network). I am trying to settle (my mind) on just one tunneling technology, and my favorite is IPSEC tunnels at the moment. I do still have some reservations about IPSEC for tunneling that I'd like to kill-off, fix, or learn how to live with: 1) What is happening now. Client-based L2 tunnel (PPTP, L2TP soon) seem to rule the waves at the moment. No support is needed from the VPN carriers. I know there are problems with this model, but it is available and it is simple. IPSEC Clients are offered by some (NewOak, Ascend, others?), and I'm sure they are just as flexible, more scalable, and have less bandwidth overhead. I guess I've talked my self out of that one then! 2) ISP-based model for L2TP. This seems to offer some advantage over the client-based option. It 'hides' the client from non-tunnel traffic; the client does not have a global IP address (saving on addresses); the client does not need to know the tunnel-server address; Dial-media information present at the NAS/LAC can be forwarded to the LNS; and PPP is more suitable for multi-protocol support (e.g. bridged LANs). I can think of ways that all these services could be resolved for IPSEC (filtering, NAT, PPP IPCP, DNS), but what services are offered by VPN carriers? 3) General LAN-to-LAN problem. The L2TP spec spends a bit of time discussing the problems with protocols that dislike reordering (LAN-based protocols) and protocols that dislike packet loss (standard PPP compression/encryption) by suggesting that Reliable PPP and L2TP reordering could be used. IPSEC/IPCOMP fixes the packet-loss issue (although block-mode encryption and compression is more crackable/less efficient that history-mode), but what is the IPSEC response to encapsulating bridged traffic and insuring there is no reordering? The conclusion I have come to at the moment is that I either invent some way of injecting a reliable data-link into my IPSEC tunnel, or I just wait for the VPN carriers to offer me a better service for LAN-to-LAN requirements. 4) Throughput monitoring. While I'm waiting for VPN carriers to support an 'SVC' QOS, it is tempting to think of a high-speed Internet pipe (Cable Modem/xDSL) as a very good value for money LAN-to-LAN pipe WHEN I CAN GET GOOD QOS. As a remote worker (Home Office), I have tried to use the Internet to connect to work, but the performance can drop-off alarming at times, so instead, I dial direct with ISDN. What I really want is a smart SOHO router that can detect when things are going pair-shaped (big drop in QOS) on the VPN tunnel, shut the tunnel down for awhile, and dial direct - all without me lifting a finger. The base problem is knowing how much of the data you pump into the VPN tunnel actually gets to the peer tunnel end-point! If my SOHO router could monitor that dynamically with reference to some 'Minimum Throughput' setting, I'd be in with a shout. For Bridged LANs, the problem is worse - I need to know how much of the data got to the peer without getting reordered. The only way I can see to fix both of these problems is to either run RPPP (for L2TP case) or squeeze a TCP header into the IPSEC tunnel (not a popular concept, I know). Does anyone have such a device? If you've read all that, thanks. I hope it wasn't too irksome! Any pointer on 'real world' VPN carrier offerings appreciated - I looked on a dozen of the larger ISP sites for anything about VPNs, and got nothing. Cheers, Steve. -----Original Message----- From: Steve Bellovin [SMTP:smb@research.att.com] Sent: Friday, February 27, 1998 8:07 PM To: ho@earth.hpc.org Cc: rgm-sec@htt-consult.com; ipsec@tis.com Subject: Re: IPSEC tunnels and Mobile IP > IMNSHO, Mobile IP is for mobile units. ie cars, tanks, soldiers, and > pedestrians. A notebook I plug into a phone jack in a hotel, car de aler, > or conference LAN does not need Mobile IP, only IPsec. While not disagreeing in principle, I'd like to note that there is tremendous utility in using a dynamically assigned IP address from the wireless provider and setting up IPSEC tunneling associations authenticated by user identity. In this way, a laptop can be mobile throughout a large wireless service structure and maintain secure connections without the necessity for level 3 handoffs. Yes. IP addresses -- especially IP addresses of dial-up clients -- are transient and meaningless. The sooner we get away from them, the better. From owner-ipsec Sat Feb 28 10:06:40 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA05423 for ipsec-outgoing; Sat, 28 Feb 1998 10:02:22 -0500 (EST) X-Authentication-Warning: zoo.utoronto.ca: u_spsys set sender to spenford!henry using -f To: Alex Alten Cc: IP Security List Subject: Re: IPSEC WORKING GROUP LAST CALL In-Reply-To: <3.0.3.32.19980227230000.00977170@netcom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Henry Spencer Date: Sat, 28 Feb 1998 10:08:24 -0500 (EST) Message-ID: Sender: owner-ipsec@ex.tis.com Precedence: bulk > >> Here I think we differ on what the secure IP network model should be. > >> I believe that it should be a resource owned by an organization or a > >> company that wants to control access to it... > >If keys are established over the public network, then AFAIK > >only PK methods can assure forward secrecy of prior established > >keys when the authenticating key is compromised. > > ...My contention is that for > model explained above that this feature is unnecessary. Whether or not it is true, this statement is uninteresting, because many would-be users of IPSEC do not fit your model. I could, with equal validity, claim that IPSEC itself is unnecessary because a model in which the network is physically secure does not need encryption at all. Henry Spencer henry%spenford@zoo.toronto.edu From owner-ipsec Sat Feb 28 10:37:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA05554 for ipsec-outgoing; Sat, 28 Feb 1998 10:32:21 -0500 (EST) X-Authentication-Warning: zoo.utoronto.ca: u_spsys set sender to spenford!henry using -f To: Alex Alten Cc: ipsec@tis.com Subject: Re: IPSEC WORKING GROUP LAST CALL In-Reply-To: <3.0.3.32.19980227225721.00973710@netcom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Henry Spencer Date: Sat, 28 Feb 1998 10:31:16 -0500 (EST) Message-ID: Sender: owner-ipsec@ex.tis.com Precedence: bulk > >A significant fraction of the community will not be satisfied by any > >protocol which incorporates key recovery... > > ...Whether you realize it or not, we have been outmaneuvered by other > communities with different desires. Certain other communities have certainly been *attempting* that... and if we concede defeat, they will have succeeded. As you point out, most others involved will do their bidding without hesitation. They have not yet won this battle, unless we win it for them. Henry Spencer henry%spenford@zoo.toronto.edu From owner-ipsec Sat Feb 28 10:50:32 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA05634 for ipsec-outgoing; Sat, 28 Feb 1998 10:46:21 -0500 (EST) Date: Sat, 28 Feb 1998 10:57:41 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199802240331.WAA11793@mimosa.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: hugh@mimosa.com ("D. Hugh Redelmeier") From: Stephen Kent Subject: Re: Comments on draft-ietf-ipsec-arch-sec-02.txt Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Hugh, > >Section 3.2, has the sentence: > In transport mode the protocols provide protection primarily > for upper layer protocols; in tunnel mode, the protocols are applied > to tunneled IP packets. > >as a naive reader, I have no idea what this is trying to communicate >about tunnel mode. It sounds like a tautology. This is an intro section and it is providing a basic explanation of the differences between the two modes of use. The last sentence specifies what is tunneled, i.e., IP packets. Other protocols tunnel other packet formats, so this is a useful degree of specificity and is not tautological. >Section 4.3 states: > > o Transport adjacency refers to applying more than one security > protocol to the same IP datagram, without invoking tunneling. > This approach to combining AH and ESP allows for only one > level of combination; further nesting yields no added benefit > since the processing is performed at one IPsec instance the > (ultimate) destination. > >This statement must be assuming that two composed ESP transforms are >no more secure than a single one (otherwise the conclusion is false). >Similarly, it must assume that two AHs don't lead to more confidence. >I think that neither of these assumptions is true. On the other hand, >one approach available is to add a new AH or ESP that is equivalent to >the compositions of interest. > >I'm not quibbling with the decision to limit adjacency. I just think >that the quoted text isn't precisely correct. The notion than additional transport mode SA nesting offers no added benefits was not base on an assumtpion of use of inadequate encryption in any single SA. You're right that super encryption could yield added benefits under such circumstances. We will add a parenthetical note to clarify this. > >The first normal paragraph after this quoted text starts: > > These two approaches also can be combined, i.e., an SA bundle could > be constructed from one tunnel mode SA and one or two transport mode > SAs, applied in sequence. > >The use of "i.e." is incorrect; "eg." is meant; "for example" is >better. Right you are! We'll fix that. >Section 4.4.1, paragraph 3, sentence 2 states: > > This interface must allow the user (or system administrator) to > specify the security processing to be applied to each packet entering > or exiting the system, on a packet by packet basis. > >I don't think that the user/sysadmin would be willing to specify >security processing on a packet by packet basis. What exactly is >intended by this sentence? Sorry this was not clear, but others have responded and described what is meant. Specifically, every inbound or outbound packet is subject to processing by IPsec and the SPD must specify what action will be taked in each case. However, through the use of wildcards in various selector fields, and because all packets on a single UDP or TCP connection will tend tend to match a single SPD entry, this requirement does not imply an impossibly detailed level of SPD specification. The selectors are analogous to what one finds in typicaly stateless firewalls or filtering routers, so sys admins have experience in managing specification for this level of packet processing. I'll look to se if we can clarify the statement, but we've generally not had any confusion in this regard. >Section 4.5, near the end: > > The following combinations of AH and ESP MUST be supported in the > indicated contexts: > > - Cases 1, 3, 4 (between H1 and H2): > a. AH in transport mode > b. ESP in transport mode > b. AH followed by ESP in transport mode > d. any one of a, b, or c above AH or ESP in tunnel mode > - Cases 1, 2, 3, and 4 (all SAs shown): > e. AH in tunnel mode > f. ESP in tunnel mode > > As noted above, support for additional combinations of AH and ESP is > optional. Use of other, optional combinations may adversely affect > interoperability. > >I think that the second "b." ought to be "c.". Yes, right again! We'll fix that. >In "d.", what does "above" mean? I know, but am not sure that this >term is defined (certainly not in this section). Case "d" means that an iplementation must support an SA bundle which consists of an AH or ESP SA, or AH and ESP SAs, in transpport mode followed by a tunnel mode using AH or ESP. Thus packets processed via this bundle will have two (three in the case of AH+ESP transport mode) IPsec headers, as enumerated above. >I am uncomfortable with this apparently intricate and empirical >enumeration of possibilities. We used to allow more elaborate combinations, but the WG decided to limit the iteration and combinations as defined here, to make Ipsec implementation easier. Enumeration seems to be the best way to describe the allowed combinations, under these circumstances. >Section 5.1.2, first point: > > o The outer IP header Source Address and Destination Address > identify the "endpoints" of the tunnel (the encapsulator and > decapsulator). The inner IP header Source Address and > Destination Addresses identify the original sender and recipient > of the datagram, respectively. > >The word "original" is a little tricky. We might be dealing with >tunneling in tunneling. Although we don't support nested tunnels with common endpoints, you're right that this could be better worded. How about "The inner IP header Source Address and Destination Addresses identify the original sender and recipient of the datagram (from the perspective of this tunnel), respectively. >In Acknowledgements there is a comma preceded by a space. Yep, first line of the second paragraph. We'll fix it. >Appendix C > >Each occurrence of "1 << diff" should probably be "1ul << diff". > >I'm not sure that the test harness should be included. Not being a C programmer, I'll defer to others on these points. Steve From owner-ipsec Sat Feb 28 11:48:23 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA06035 for ipsec-outgoing; Sat, 28 Feb 1998 11:41:21 -0500 (EST) Date: Sat, 28 Feb 1998 11:53:17 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Patel, Baiju V" From: Stephen Kent Subject: RE: IPSEC WORKING GROUP LAST CALL Cc: "Patel, Baiju V" , "'ipsec'" Sender: owner-ipsec@ex.tis.com Precedence: bulk Baiju, >My comments: > >If I read above statements carefully, it seems that Steve Bellovin is >saying that authentication is >mandatory for ESP which is different from what Steve Kent says. In this case, Steve kent is right. I read Steve Bellovin's remarks to be emphasizing the importance of authentication in conjunction with encryption, and that it would be dangerous to employ one without the other. The ESP intro says excatly that, but because one could choose to achieve authentication by various combinations of the IPsec protocols, it is not mandated that ESP always enable authentication. >I have been reading documents to figure out how you >can specify not to use authentication with ESP In the ESP spec, the introduction clearly states that authentication is an optional feature, while confidentiality is mandatory. Section 2.7 goes on to state that the ICV is an optional field that is present only if authentication is selected for the SA. So, the issues seems to be whether the DOI provides the requisite "transform identifiers" for negotiating this combination of services. If not, then we have another mismatch between the documents, but it shouild be easy to fix. Steve From owner-ipsec Sat Feb 28 11:56:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA06102 for ipsec-outgoing; Sat, 28 Feb 1998 11:51:20 -0500 (EST) Date: Sat, 28 Feb 1998 11:53:22 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C011D5A8A@wade.reo.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Stephen Waters From: Stephen Kent Subject: Re: LAN-to-LAN IPSEC tunnels over the Internet Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, >I know that the recommendation is for 'block-mode' encryption so that >major-damage is not done to the data-stream when the odd packet goes >missing. But, for LAN-to-LAN, certain QOS is required anyway (and the >carriers and ISPs seem to be working towards offering better services >for LAN-to-LAN - i.e. less packet loss and no reordering), so, is there >a way of using IPSEC encryption in cipher-stream mode when the service >is good enough - I hear this makes the cipher harder to crack. Stream ciphers can be used with IPSEC. I would expect to carry crypto synch data as part of the payload, to allow for resynch in the event of packet loss. The comment re making the cipher "harder to crack" does not seem well founded. Steve