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 ret