From owner-ipsec Tue Nov 4 04:13:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA10943 for ipsec-outgoing; Tue, 4 Nov 1997 03:58:06 -0500 (EST) Message-Id: <199711040905.EAA09274@relay.rv.tis.com> Comments: Authenticated sender is From: "Elfed T. Weaver" Organization: DERA To: ipsec@tis.com Date: Tue, 4 Nov 1997 09:05:05 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: ignore - ping X-mailer: Pegasus Mail for Win32 (v2.54) Sender: owner-ipsec@ex.tis.com Precedence: bulk **************************************************** "The views expressed above are entirely those of the writer and do not represent the views, policy or understanding of any other person or official body." Elfed T. Weaver DERA Malvern UK weaver@hydra.dra.hmg.gb **************************************************** From owner-ipsec Fri Nov 7 02:25:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA06245 for ipsec-outgoing; Fri, 7 Nov 1997 02:19:18 -0500 (EST) From: Dan McDonald Message-Id: <199711070730.XAA18788@kebe.eng.sun.com> Subject: Updated MLS section - "5.4 bis" To: ipsec@tis.com Date: Thu, 6 Nov 1997 23:30:04 -0800 (PST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk IPsec folks, The following is: 1. A revised version of 5.4-bis that takes into account some comments from Steve Kent. 2. Steve's comments, with some responses that tie in the the revision. A reminder for those in the audience, the goal is to make sure that MLS vendors know that IPsec (in its base form) is there for them, and can be used w/o _too_much_ additional hassle. Dan ===================== (Cut up to and including here.) ===================== 5.4 Use in Compartmented or Multi-Level Networks A multi-level secure (MLS) network is one where a single network is used to communicate data with different sensitivity information labels (e.g., Unclassified, Company Proprietary, Secret) [DoD85] [DoD87]. The IP security mechanisms can easily support MLS networking. MLS networking requires the use of strong Mandatory Access Controls (MAC), which unprivileged users or unprivileged processes are incapable of controlling or violating [BL73]. This section pertains only to the use of these IP security mechanisms in MLS environments. Nothing in this section applies to systems not claiming to provide MLS. As used in this section, "sensitivity information" might include implementation-defined hierarchic levels, categories, and/or releasability information. The Authentication Header can be used to provide strong assurance for both mandatory access control decisions in multi-level networks and discretionary access control decisions in all kinds of networks. If explicit IP sensitivity information (e.g., IPSO [Ken91]) is used and confidentiality is not considered necessary within the particular operational environment, the Authentication Header can be used to provide authentication for the entire packet, including cryptographic binding of the sensitivity information to the IP header and user data. This is a significant improvement over labeled IPv4 networks where the sensitivity information is trusted even though there is no authentication or cryptographic binding of the information to the IP header and user data. IPv4 networks might or might not use explicit labelling. IPv6 will normally use implicit sensitivity information that is part of the IPsec Security Association but not transmitted with each packet instead of using explicit sensitivity information. All explicit IP sensitivity information MUST be authenticated using either ESP, AH, or both. Encryption is useful and can be desirable even when all of the hosts are within a protected environment, for example, behind a firewall or disjoint from any external connectivity. The Internet-standard encryption algorithm could be used, in conjunction with appropriate key management, to provide strong Discretionary Access Controls (DAC). Key management could use sensitivity information to provide Mandatory Access Controls (MAC). Some environments, depending on their local policy, might consider the Internet-standard encryption algorithm sufficiently strong to provide MAC. IPsec implementations on systems claiming to provide MLS SHOULD be capable of using IPsec to provide MAC for IP-based communications. 5.4.1 Relationship Between Security Associations and Data Sensitivity Both the Encapsulating Security Payload and the Authentication Header could be combined with appropriate Security Association policies to provide multi-level secure networking. In this case each SA (or SA bundle) is normally used for only a single instance of sensitivity information. For example, "PROPRIETARY - Internet Engineering" must be associated with a different SA (or SA bundle) from "PROPRIETARY - Finance". 5.4.2 Sensitivity Consistency Checking An MLS implementation (both host and router) MAY associate sensitivity information, or a range of sensitivity information with an interface, or a configured IP address with its associated prefix (the latter is sometimes referred to as a logical interface, or an interface alias). If such properties exist, an implementation SHOULD compare the sensitivity information associated with the packet against the sensitivity information associated with the interface or address/prefix from which the packet will arrive, or to which the packet will depart. This check will either verify that the sensitivities match, or that the packet's sensitivity falls within the range of the interface or address/prefix. The checking SHOULD be done on both inbound and outbound processing. 5.4.3 Additional MLS Attributes for Security Association Databases Section 4.4 details three Security Association databases. The first two, the Security Policy Database (SPD) and the Security Association Map (SAM), are used primarily for outbound traffic, though the SPD is also consulted after IPsec inbound processing, but before the IP datagram is passed to an application or forwarding engine. Both the SPD and the SAM use common selectors. MLS networking introduces an additional selector: - Sensitivity information. The Sensitivity information aids in selecting the appropriate algorithms and key strength, so that the traffic gets a level of protection appropriate to its importance or sensitivity as described in section 5.4.1. The exact syntax of the sensitivity information is implementation defined. The third database is the Security Association Database (SAD). One additional SAD attribute is: - Sensitivity information. Sensitivity information is needed in the model shown in [BL73]. 5.4.4 Additional Inbound Processing Steps for MLS Networking After an inbound packet has passed through IPsec processing, an MLS implementation SHOULD first check the packet's sensitivity (as defined by the SA (or SA bundle) used for the packet) with the interface or address/prefix as described in section 5.4.2 before delivering the datagram to an upper-layer protocol. The MLS system MUST retain the binding between the data received in an IPsec protected packet and the sensitivity information in the SA or SAs used for processing, so appropriate policy decisions can be made when delivering the datagram to an application or forwarding engine. The means for maintaining this binding are implementation specific. 5.4.5 Additional Outbound Processing Steps for MLS Networking An MLS implementation of IPsec MUST perform two additional checks besides the normal steps detailed in section X.Y.Z. When consulting the SPD or the SAM to find an outbound security association, the MLS implementation MUST use the sensitivity of the data to select an appropriate outbound SA or SA bundle. The second check comes before forwarding the packet out to its destination, and is the sensitivity consistency checking described in section 5.4.2. 5.4.6 Additional MLS Processing for Security Gateways An MLS security gateway MUST follow the previously mentioned inbound and outbound processing rules as well as perform some additional processing specific to the intermediate protection of packets in an MLS environment. A security gateway MAY act as an outbound proxy for creating SAs for MLS systems that originate packets forwarded by the gateway. These MLS systems may explicitly label the packets to be forwarded, or the whole originating network may have sensitivity characteristics associated with it. The security gateway MUST create and use appropriate SAs for AH, ESP, or both, to protect such traffic it forwards. Similarly such a gateway SHOULD accept and process inbound AH and or ESP packets and forward appropriately, using explicit packet labeling, or relying on the sensitivity characteristics of the destination network. REFERENCES [BL73] Bell, D.E. & LaPadula, L.J., "Secure Computer Systems: Mathematical Foundations and Model", Technical Report M74-244, The MITRE Corporation, Bedford, MA, May 1973. [Ken91] Kent, S., "US DoD Security Options for the Internet Protocol", RFC 1108, BBN Communications, November 1991. ===================== (Cut up to and including here.) ===================== And now, for Steve's comments (> IN CAPS AND QUOTED WITH '>') and Dan's replies ( Tabbed in): 5.4 Use in Compartmented or Multi-Level Networks > MAKES IT SOUND LIKE SUCH CONTROLS ARE UNMANAGEABLE! REWORD TO BETTER > EXPRESS THE NOTION THAT MAC PREVENTS TROJAN HORSES FROM VIOLATING THE > CONTROLS .... I think I just fixed this by mentioning that _unprivileged_ users/processes are denied access. > The Authentication Header can be used to provide strong authentication > among hosts (OR NETS) in a single-level network. (TRUE, BUT NOT SO > RELEVANT TO THIS DISCUSSION, RIGHGT? Removed. > BE MORE EXPLICIT ABOUT THE DAC TIE-IN, I.E., AH AUTHENTICATES THE SENDER ID > AND THUS SUPPORTS DAC. ALSO, THE MAC SUPPORT ARISES ONLY IN CONJUNCTION > WITH THE USE OF LABELS, RIGHT? THE COMMENT ABOUT "STRONG ASSURANCE" IS NOT > JUSTIFIED HERE; JUST USING AH DOES NOT SAY ANYTHING ABOUT THE LEVEL OF > ASSURANCE. MAC support can be implicit with the Security Association information itself. > Some environments might > consider the Internet-standard encryption algorithm sufficiently > strong to provide Mandatory Access Controls (MAC). (THIS SORT OF > STATEMENT IS OUTSIDE THE SCOPE OF IPSEC; IT IS A DECISION FOR DOD > POLICY MAKERS, NOT AN IETF WG.) Put in "dependent on their local policy". This is also for the word "might". You're right, we don't dictate policy. By the way, MLS =!=> DoD. MLS boxes are used by commercial customers too. 5.4.1 Relationship Between Security Associations and Data Sensitivity > Both the Encapsulating Security Payload and the Authentication Header > can be combined with appropriate Security Association policies to > provide full multi-level secure networking. (WELL, WE CAN MAP SAs > WELL, WE CAN MAP SAs > APPROPRIATELY IN AN MLS NETWORK ENVIRONMENT, BUT IT IS NOT AT ALL > CLEAR THAT COST IPSEC IMPLEMENTATIONS ARE SUITABLE FOR ENFORCING MLS. We weakened "can" to "could". And any COTS OS needs _some_ modifications to fully enforce MLS, same applies to IPsec. > For example, "PROPRIETARY - Internet Engineering" must > be associated with a different SA (or SA bundle) from "PROPRIETARY - > Finance". (ALTHOUGH THIS IS A REASONABLE MAPPING IT MAY NOT BE > SUFFICIENT NOR NECESSARY IN ALL INSTANCES.) That's why it's an example. 5.4.2 Sensitivity Consistency Checking > (IF THIS APPLIES TO HOSTS AND GATEWAYS, LETS SAY SO EXPLICITLY) Done. > The checking SHOULD be done on both inbound and outbound processing. > (WHY ONLY A SHOULD, INSTEAD OF A MUST? CAN THIS BE TRANALATED INTO A > CHECK FOR SA LABELS WHEN THEY ARE CREATED, BOUND TO A SPECIFIC > INTERFACE OR SET OF INTERFACES?) Because, as you pointed out in a previous bullet, it could be a matter of local policy. 5.4.3 Additional MLS Attributes for Security Association Databases > Sensitivity information is needed in the model shown in [BL73]. > (I AGREE WITH THIS TEXT, BUT WE ALSO NEED TO STANDARDIZE THIS INFO AND > MATCH IT TO THE DATA SENT VIA ISAKMP, SO THAT BOTH ENDS AGREE ON THE > LABELS USED TO MAP TO THE SA. WHAT HAS BEEN NAILED DOWN FOR ISAKMP?) Because ISAKMP isn't the only Key Mgmt. out there, we avoided these questions. Especially in a DoD environment, they may have rolled something better. This is the IPsec architecture document, which is deliberately decoupled from Key Mgmt. 5.4.4 Additional Inbound Processing Steps for MLS Networking > (BUT THE MEANS FOR MAINTAING THIS BINDING ARE OS-SPECIFIC, RIGHT?) Yep. And it's now noted as such. 5.4.6 Additional MLS Processing for Security Gateways > ("PERHAPS" SEEMS VAGUE. ... Yep. We've snipped it out. From owner-ipsec Fri Nov 7 10:39:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA09108 for ipsec-outgoing; Fri, 7 Nov 1997 10:37:53 -0500 (EST) Message-Id: <199711071453.JAA21612@ghostwheel.ncsl.nist.gov> Date: Fri, 7 Nov 1997 09:53:16 -0500 (EST) To: ipsec@tis.com From: rob.glenn@nist.gov Subject: new hmac drafts submitted 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-01.txt and draft-ietf-ipsec-auth-hmac-sha-1-96-01.txt should be availble in your favorite ID site in the next couple of days. The changes were mostly editorial in nature, below is a summary. 1. Used RFC2119 boilerplate paragraph. 2. Cleaned up and updated the references section. 3. Replaced the key lifetimes recommendation with a statement that such recommendations are not available at this time. 4. Better explanation of how algorithm specific padding works 5. Now that the ID database can take longer file names, the draft filenames should be more consistent. Rob G. From owner-ipsec Fri Nov 7 18:26:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA12038 for ipsec-outgoing; Fri, 7 Nov 1997 18:23:33 -0500 (EST) Message-Id: <199711072339.SAA04618@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Windows 3.1 IPsec Date: Fri, 07 Nov 1997 18:39:18 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Are there any Windows 3.1 stack vendors that have been working on IPsec for their stack? I know about FTP Software, and their apparently illfated stack. Or there others? Rodney confirms that his web pages are void of any Windows 3.1 entries. :!mcr!: | Network and security consulting/contract programming Michael Richardson | I do IPsec policy code for SSH 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 iQB1AwUBNGOmpKZpLyXYhL+BAQFYPQL/QvGcFTx1jbsXsdVs21qfA7YhUOqrHVeg Uo885jIITSW1YVuTVidFNM07aiiDxE4fRI2n/z5ZfxhJyXei04WQK2IIxymcZj2R +D0NbvU+E890K3LVhBoQxe+iM/EpE7f0 =wxgL -----END PGP SIGNATURE----- From owner-ipsec Mon Nov 10 18:45:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA10582 for ipsec-outgoing; Mon, 10 Nov 1997 18:39:21 -0500 (EST) Message-ID: From: Roy Pereira To: "'Michael C. Richardson'" , "'ipsec@tis.com'" Subject: RE: Windows 3.1 IPsec Date: Mon, 10 Nov 1997 16:41:13 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk There's a untapped IPSec market ! ;-) Anyone writing a PalmPilot IPSec stack? On Friday, November 07, 1997 6:39 PM, Michael C. Richardson [SMTP:mcr@sandelman.ottawa.on.ca] wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > > Are there any Windows 3.1 stack vendors that have been working on > IPsec for their stack? > > I know about FTP Software, and their apparently illfated stack. > Or there others? > > Rodney confirms that his web pages are void of any Windows 3.1 entries. > > :!mcr!: | Network and security consulting/contract programming > Michael Richardson | I do IPsec policy code for SSH > 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 > > iQB1AwUBNGOmpKZpLyXYhL+BAQFYPQL/QvGcFTx1jbsXsdVs21qfA7YhUOqrHVeg > Uo885jIITSW1YVuTVidFNM07aiiDxE4fRI2n/z5ZfxhJyXei04WQK2IIxymcZj2R > +D0NbvU+E890K3LVhBoQxe+iM/EpE7f0 > =wxgL > -----END PGP SIGNATURE----- From owner-ipsec Mon Nov 10 21:46:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA14159 for ipsec-outgoing; Mon, 10 Nov 1997 21:44:55 -0500 (EST) Message-Id: <199711110250.CAA08973@orchard.arlington.ma.us> To: Roy Pereira cc: "'Michael C. Richardson'" , "'ipsec@tis.com'" Subject: Re: Windows 3.1 IPsec In-reply-to: Your message of "Mon, 10 Nov 1997 16:41:13 -0500 ." Date: Mon, 10 Nov 1997 21:50:03 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > Anyone writing a PalmPilot IPSec stack? Given that the palmPilot Pro has ip and ppp in ROM, and someone else has ported ssh and ssl clients to the pilot, it's not as outrageous as it sounds... From owner-ipsec Tue Nov 11 09:43:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA02463 for ipsec-outgoing; Tue, 11 Nov 1997 09:38:54 -0500 (EST) Message-Id: <199711111357.IAA00510@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-auth-hmac-sha196-01.txt Date: Tue, 11 Nov 1997 08:57:49 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Use of HMAC-SHA-1-96 within ESP and AH Author(s) : C. Madson, R. Glenn Filename : draft-ietf-ipsec-auth-hmac-sha196-01.txt Pages : 5 Date : 07-Nov-97 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 wih 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-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-auth-hmac-sha196-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-auth-hmac-sha196-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971107145536.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-auth-hmac-sha196-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-auth-hmac-sha196-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971107145536.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Nov 11 09:44:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA02448 for ipsec-outgoing; Tue, 11 Nov 1997 09:38:24 -0500 (EST) Message-Id: <199711111356.IAA00440@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-auth-hmac-md5-96-01.txt Date: Tue, 11 Nov 1997 08:55: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 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-01.txt Pages : 5 Date : 07-Nov-97 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-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-auth-hmac-md5-96-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-auth-hmac-md5-96-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971107144128.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-auth-hmac-md5-96-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-auth-hmac-md5-96-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971107144128.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Nov 11 10:45:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA03410 for ipsec-outgoing; Tue, 11 Nov 1997 10:39:56 -0500 (EST) Message-Id: <3.0.3.32.19971111104511.00b82470@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 11 Nov 1997 10:45:11 -0500 To: Roy Pereira , "'Michael C. Richardson'" , "'ipsec@tis.com'" From: Robert Moskowitz Subject: RE: Windows 3.1 IPsec In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 04:41 PM 11/10/97 -0500, Roy Pereira wrote: >There's a untapped IPSec market ! ;-) > >Anyone writing a PalmPilot IPSec stack? > Well TimeStep had a 'pre' IPsec product for WinFW 3.1 (to get the NDIS drivers). They even tried out an ODI driver version for a company I know, but did have some problems with it. DOn't know if they have any current plans for these platforms/drivers. I recall one other vendor talking to me about it, but they should speak for themselves. Finally, one vendor and a modem vendor have teamed up to put IPsec in the modem for those systems that have PPP, but are unlikely to get an IPsec implementation. Hope to hear about this work soon. This vendor had a 'pre IPsec' product that ran on their own modem, so they know how to do this, the modem vendor is one of the big ones. In fact, I think this partnership is public knowledge, I will check for the press release if there is interest. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Tue Nov 11 12:21:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA05849 for ipsec-outgoing; Tue, 11 Nov 1997 12:19:27 -0500 (EST) From: "John F. Moehrke" To: , "Roy Pereira" , "'Michael C. Richardson'" , Subject: Re: Windows 3.1 IPsec Date: Tue, 11 Nov 1997 11:34:22 -0600 Message-ID: <01bceec8$0bf09f80$652068c0@rock101.frontiertech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ipsec@ex.tis.com Precedence: bulk Frontier does not have "scheduled" plans to produce the 3x version of IPSec, but given the "right" reasons, we can be persuaded. -----Original Message----- From: Robert Moskowitz To: Roy Pereira ; 'Michael C. Richardson' ; 'ipsec@tis.com' Date: Tuesday, November 11, 1997 11:02 AM Subject: RE: Windows 3.1 IPsec >At 04:41 PM 11/10/97 -0500, Roy Pereira wrote: >>There's a untapped IPSec market ! ;-) >> >>Anyone writing a PalmPilot IPSec stack? >> >Well TimeStep had a 'pre' IPsec product for WinFW 3.1 (to get the NDIS >drivers). They even tried out an ODI driver version for a company I know, >but did have some problems with it. DOn't know if they have any current >plans for these platforms/drivers. > >I recall one other vendor talking to me about it, but they should speak for >themselves. Finally, one vendor and a modem vendor have teamed up to put >IPsec in the modem for those systems that have PPP, but are unlikely to get >an IPsec implementation. Hope to hear about this work soon. This vendor >had a 'pre IPsec' product that ran on their own modem, so they know how to >do this, the modem vendor is one of the big ones. In fact, I think this >partnership is public knowledge, I will check for the press release if >there is interest. > > > > > >Robert Moskowitz >Chrysler Corporation >(810) 758-8212 > From owner-ipsec Tue Nov 11 12:48:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA06568 for ipsec-outgoing; Tue, 11 Nov 1997 12:46:58 -0500 (EST) Message-ID: From: Roy Pereira To: "'rgm3@chrysler.com'" , "'Michael C. Richardson'" , "'ipsec@tis.com'" Subject: RE: Windows 3.1 IPsec Date: Tue, 11 Nov 1997 11:41:04 -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 TimeStep did have a secure VPN client for WFW 3.11, but it did not use IPSec technology. It predated IPSec, and thus used TimeStep's proprietary SAP/NLSP protocols for securing the conection. On Tuesday, November 11, 1997 10:45 AM, Robert Moskowitz [SMTP:rgm3@chrysler.com] wrote: > At 04:41 PM 11/10/97 -0500, Roy Pereira wrote: > >There's a untapped IPSec market ! ;-) > > > >Anyone writing a PalmPilot IPSec stack? > > > Well TimeStep had a 'pre' IPsec product for WinFW 3.1 (to get the NDIS > drivers). They even tried out an ODI driver version for a company I know, > but did have some problems with it. DOn't know if they have any current > plans for these platforms/drivers. > > I recall one other vendor talking to me about it, but they should speak for > themselves. Finally, one vendor and a modem vendor have teamed up to put > IPsec in the modem for those systems that have PPP, but are unlikely to get > an IPsec implementation. Hope to hear about this work soon. This vendor > had a 'pre IPsec' product that ran on their own modem, so they know how to > do this, the modem vendor is one of the big ones. In fact, I think this > partnership is public knowledge, I will check for the press release if > there is interest. > > > > > > Robert Moskowitz > Chrysler Corporation > (810) 758-8212 From owner-ipsec Fri Nov 14 06:42:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA20505 for ipsec-outgoing; Fri, 14 Nov 1997 06:29:29 -0500 (EST) Message-Id: <199711141136.GAA15213@relay.rv.tis.com> Date: Fri, 14 Nov 97 6:32:50 EST From: Karen Seo To: ipsec@tis.com cc: kseo@bbn.com Subject: IPsec Architecture -- List of changes Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, At the direction of the working group chairs, we're posting the IPsec Architecture draft directly to the mailing list to minimize delays. (It is also being sent to the secretariat.) The chairs ask everyone to please review and comment as quickly as possible. This draft has been significantly changed from the previous draft. The following list summarizes some of the changes. Please note that we did not always use the exact edit/text proposed in the 10/7 email. We also made edits, corrections, and clarifications which are not on this list. Thank you, Karen ============================================================================= 1. Which documents should contain references to current default algorithms (mandatory-to-implement)? We currently have: - AH mandatories in AH, Arch (and DOI). - ESP mandatories in ESP, Arch (and DOI). ** The references were left in the AH, ESP, and Architecture documents. ============================================================================= 2. How should we handle the security gateway problem -- discovery of the security gateway, verification of its authenticity and authorization, etc.? ** We shortened the problem description in Section 4.6.3 "Locating a Security Gateway" and added text stating that "a host or security gateway MUST have an administrative interface that allows the user/administrator to configure the address of a security gateway for any sets of destination addresses that require its use....." And that "This document does not address the issue of how to automate the discovery/verification of security gateways." ============================================================================= 3. How should we handle MLS issues? ** We have inserted the MLS text supplied on 11/6 by Dan McDonald et al. It is now section 8 and has been re-titled "Use in Systems Supporting Information Flow Security". A few minor edits were made to reflect changes to other parts of the document. ============================================================================= 4. Clarification about using a different SPI when a new SA is created because of rekeying... ** We have replaced the phrase "rekey" with "replace" or otherwise clarified the text. ============================================================================= 5. Should the IPsec architecture enable an application, which is using a single socket to communicate with multiple peers, to use different security policies for different peers? ** We have added the following text to section 4.4.1, "Security Policy Database", paragraph 3, after sentence 1. "This interface must allow the user/application to specify a set of policies that can be invoked on a packet by packet basis for a single socket, e.g., for UDP traffic. Also, the system administrator MUST be able to specify whether or not a user/application can circumvent system policies." ============================================================================= 6. Should AH/ESP be a selector? What should this selector be called? ** A new selector paragraph has been added to section 4.4.3 "Selectors": for "IPsec protocol (AH or ESP or AH/ESP)" ============================================================================= 7. Should the "Transport Protocol" selector be required only for systems supporting IPv6, and be optional for IPv4? ** We have modified the Transport Protocol paragraphs of section 4.4.3 "Selectors" to be "[REQUIRED for IPv6 implementations, MAY be supported in IPv4 implementations]" ============================================================================= 8. Additional selector changes -- adding TOS and renaming IPv6 "Priority" to "Class". ** Added the text: IPv4 Type of Service (TOS): Obtained from the IPv4 header. This may be expressed as a wildcard or an explicit value. [REQUIRED for all systems that implement IPv4] ** Changed "IPv6 Priority..." to "IPv6 Class..." ============================================================================= 9. Additional warnings that certain selectors may not always be accessible.... ** We added text to section 4.4.3 "Selectors" indicating that "in the case of receipt of a packet with an ESP header....the transport layer protocol and source/destination ports may be opaque, thus making them unavailable for use as selectors." ============================================================================= 10. How should we handle header copying in tunnel mode? ** We have modified the text to more closely follow the model used in RFC 2003 "IP Encapsulation with IP". This RFC minimizes the complexity of this problem by generally not copying options, e.g., source routing. The TTL is also no longer being copied. ============================================================================= 11. Multicast clarification. ** Clarified Section 4.7 "Security Associations and Multicast" ============================================================================= 12. How should we ensure interoperable mapping of key material to keys? ** Text has been added to Section 4.6.2 "Automatic Techniques -- Key Mgt Protocol Requirements" to clarify how key material is to be mapped to keys to ensure interoperability. ============================================================================= 13. In *TRANSPORT MODE*, allowing arbitrary ordering of IPsec headers? ** The draft has been altered to support: 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] and any one of 1, 2, 3, above 4 or 5. ============================================================================= 14. Revision of Section 4. "Security Associations" ** Section 4, 5, 6 have been revised: o removed the Security Association Map (section 4.4.2 "Security Association Outbound Processing) from the design because of problems identified by several people on the list. o added the following attributes to the Security Association Database: - Anti-replay window size - Largest valid (has passed ICV check) sequence number seen (receiver only) - Path MTU information o added IPsec protocol mode (transport or tunnel or wildcard) to the Security Policy Database (SPD). o enabled an SA to be used by more than one policy o enabled specification of which of the following values should used for each selector in the SA: (a) the value in the packet, (b) the value associated with the policy, or (c) a wildcard. o clarified the details of mapping and checking between packet, SPD, and SAD. o added to Section 6 (ICMP) We did not remove the IPsec protocol mode (transport, tunnel or wildcard) as an SA attribute from Section 4.4.4 "Security Association Database (SAD)". If an SA is to be used for both modes, the SA "mode" selector can be set to wildcard. ============================================================================= 15. Per email from Dan McDonald 9/21... ** We added GKMP as an example of work in progress for multicast key distribution in section 4.7. ============================================================================= 16. Per email from Dan McDonald 9/21... ** We added a note to the appendix on PMTU/DF processing: "If a bump-in-the-stack implementation of IPsec attempts to apply different IPsec algorithms based on source/destination ports, it will be difficult to apply Path MTU adjustments." ============================================================================= 17. Per Dan McDonald 9/21... ** Text was added to section 9. "Performance Issues": "The initial SA establishment overhead will be felt in the first packet. This delay could impact the transport layer and application. For example, it could cause TCP to retransmit the SYN before the ISAKMP exchange is done. The effect of the delay would be different on UDP than TCP because TCP shouldn't transmit anything other than the SYN until the connection is set up whereas UDP will go ahead and transmit data beyond the first packet." ============================================================================= 18. Should the IPsec architecture support checking of the selectors by the receiver and the enforcement of receiver-specified security policies? ** Modified Section 4 "Security Associations" and Section 5.2 "Processing Inbound Traffic" to support checking of the selectors by the receiver and the enforcement of receiver-specified security policies? ============================================================================= 19. SPI ranges -- need to think more about reserved range for multicast ** NO changes made; a reserved range does not appear to provide much benefit. ============================================================================= 20. ICMPs -- entering ends of tunnels ** Modified section 4 and 5 to enable better handling of ICMPs from beyond the end of a tunnel. ============================================================================= 21. Unneeded sections ** Removed the following sections: 7. Algorithm Descriptions 8. Usage Scenarios.. ============================================================================= 22. ICMP processing ** Modified Section 6 to provide direction on handling ICMP messages besides ICMP PMTU. From owner-ipsec Fri Nov 14 07:37:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA23771 for ipsec-outgoing; Fri, 14 Nov 1997 07:33:27 -0500 (EST) Message-Id: <199711141136.GAA15215@relay.rv.tis.com> Date: Fri, 14 Nov 97 6:36:58 EST From: Karen Seo To: internet-drafts@ietf.org cc: ipsec@tis.com Subject: Internet Draft -- IPsec Architecture Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, Please find attached the latest IPsec Architecture draft. I wasn't sure what the filename version was going to be and have left it unspecified (draft-ietf-ipsec-arch-sec-??.txt). Thank you, Karen Network Working Group Stephen Kent, BBN Corp draft-ietf-ipsec-arch-sec-??.txt Randall Atkinson, @Home Network Obsoletes RFC 1825 November 1997 Security Architecture for the Internet Protocol Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of 6 months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as "work in progress". Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. This particular Internet Draft is a product of the IETF's IP Security (IPsec) working group. It is intended that a future version of this draft be submitted to the IESG for publication as a Draft Standard RFC. Comments about this draft may be sent to the authors or to the IPsec WG mailing list . Distribution of this document is unlimited. Copyright (C) The Internet Society (November 1997). All Rights Reserved. Kent, Atkinson [Page 1] Internet Draft Security Architecture for IP November 1997 Table of Contents 1. Introduction............................................................4 1.1 Summary of Contents of Document.....................................4 1.2 Audience............................................................4 1.3 Related Documents...................................................5 2. Design Objectives.......................................................5 2.1 Goals/Objectives/Requirements/Problem Description...................5 2.2 Caveats and Assumptions.............................................6 3. System Overview ........................................................6 3.1 What IPsec Does.....................................................7 3.2 How IPsec Works.....................................................7 3.3 Where IPsec May Be Implemented......................................8 4. Security Associations...................................................9 4.1 Definition and Scope................................................9 4.2 Security Association Functionality.................................11 4.3 Combining Security Associations....................................12 4.4 Security Association Databases.....................................13 4.4.1 The Security Policy Database (SPD)............................13 4.4.2 Selectors.....................................................16 4.4.3 Security Association Database (SAD)...........................19 4.5 Basic Combinations of Security Associations........................21 4.6 SA and Key Management..............................................23 4.6.1 Manual Techniques.............................................24 4.6.2 Automated SA and Key Management...............................24 4.6.3 Locating a Security Gateway...................................25 4.7 Security Associations and Multicast................................26 5. IPsec Traffic Processing...............................................27 5.1 Outbound IPsec Traffic Processing..................................27 5.1.1 Selecting and Using an SA or SA Bundle........................27 5.1.2 Header Construction for Tunnel Mode...........................28 5.1.2.1 IPv4 -- Header Construction for Tunnel Mode..............29 5.1.2.2 IPv6 -- Header Construction for Tunnel Mode..............30 5.2 Processing Inbound IPsec Traffic...................................30 5.2.1 Selecting and Using an SA or SA Bundle...........................30 5.2.2 Handling of AH and ESP tunnels...................................31 6. ICMP Processing (relevant to IPsec)....................................31 6.1 PMTU/DF Processing.................................................32 6.1.1 DF Bit........................................................32 6.1.2 Path MTU Discovery (PMTU).....................................32 6.1.2.1 Propagation of PMTU......................................33 6.1.2.2 Calculation of PMTU......................................34 6.1.2.3 Granularity of PMTU Processing...........................34 6.1.2.4 PMTU Aging...............................................34 7. Auditing...............................................................35 8. Use in Systems Supporting Information Flow Security....................35 8.1 Relationship Between Security Associations and Data Sensitivity....36 8.2 Sensitivity Consistency Checking...................................36 Kent, Atkinson [Page 2] Internet Draft Security Architecture for IP November 1997 8.3 Additional MLS Attributes for Security Association Databases.......37 8.4 Additional Inbound Processing Steps for MLS Networking.............37 8.5 Additional Outbound Processing Steps for MLS Networking............37 8.6 Additional MLS Processing for Security Gateways....................38 9. Performance Issues.....................................................38 10. Conformance Requirements..............................................39 11. Security Considerations...............................................39 12. Differences from RFC 1825.............................................39 Acknowledgements..........................................................39 Appendix A -- Glossary....................................................40 Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues.........44 B.1 DF bit.............................................................44 B.2 Fragmentation......................................................44 B.3 Path MTU Discovery.................................................48 B.3.1 Identifying the Originating Host(s)...........................49 B.3.2 Calculation of PMTU...........................................51 B.3.3 Granularity of Maintaining PMTU Data..........................51 B.3.4 Per Socket Maintenance of PMTU Data...........................53 B.3.5 Delivery of PMTU Data to the Transport Layer..................53 B.3.6 Aging of PMTU Data............................................53 Appendix C -- Sequence Space Window Code Example..........................54 Appendix D -- Categorization of ICMP messages.............................56 References................................................................59 Disclaimer................................................................62 Author Information........................................................62 Kent, Atkinson [Page 3] Internet Draft Security Architecture for IP November 1997 1. Introduction 1.1 Summary of Contents of Document This memo specifies the base architecture for IPsec compliant systems. The goal of the architecture is to provide various security services for traffic at the IP layer, in both the IPv4 and IPv6 environments. This document describes the goals of such systems, their components and how they fit together with each other and into the IP environment. It also describes the security services offered by the IPsec protocols, and how these services can be employed in the IP environment. This document does not address all aspects of IPsec architecture. Subsequent documents will address additional architectural details of a more advanced nature, e.g., use of IPsec in NAT environments and more complete support for IP multicast. The following fundamental components of the IPsec security architecture are discussed in terms of their underlying, required functionality. Additional RFCs (see Section 1.3 for pointers to other documents) define the protocols in (a), (c), and (d). a. Security Protocols -- Authentication Header (AH) and Encapsulating Security Payload (ESP) b. Security Associations -- what they are and how they work, how they are managed, associated processing c. Key Management -- manual and automatic (ISAKMP/Oakley) d. Algorithms for authentication and encryption This document is not an overall Security Architecture for the Internet; it addresses security only at the IP layer, provided through the use of a combination of cryptographic and protocol security mechanisms. The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [Bra97]. 1.2 Audience The target audience for this document includes implementers of this IP security technology and others interested in gaining a general background understanding of this system. In particular, prospective users of this technology (end users or system administrators) are part of the target audience. A glossary is provided as an appendix to help fill in gaps in background/vocabulary. This document assumes that the reader is familiar with the Internet Protocol, related networking technology, and general security terms and concepts. Kent, Atkinson [Page 4] Internet Draft Security Architecture for IP November 1997 1.3 Related Documents As mentioned above, other documents provide detailed definitions of some of the components of IPsec and of their inter-relationship. They include RFCs on the following topics: a. "IP Security Document Roadmap" [TDG97] -- a document providing guidelines for specifications describing encryption and authentication algorithms used in this system. b. security protocols -- RFCs describing the Authentication Header (AH) [KA97a] and Encapsulating Security Payload (ESP) [KA97b] protocols. c. algorithms for authentication and encryption -- a separate RFC for each algorithm. d. automatic key management, e.g., an RFC on ISAKMP/Oakley and "The Internet IP Security Domain of Interpretation for ISAKMP" [Pip97]. 2. Design Objectives 2.1 Goals/Objectives/Requirements/Problem Description IPsec is designed to provide interoperable, high quality, cryptographically-based security for IPv4 and IPv6. The set of security services offered includes access control, connectionless integrity, data origin authentication, protection against replays (a form of partial sequence integrity), confidentiality (encryption), and limited traffic flow confidentiality. These services are provided at the IP layer, offering protection for IP and/or upper layer protocols. These objectives are met through the use of two traffic security protocols, the Authentication Header (AH) and the Encapsulating Security Payload (ESP), and through the use of cryptographic key management procedures and protocols. The set of IPsec protocols employed in any context, and the ways in which they are employed, will be determined by the security and system requirements of users, applications, and/or sites/organizations. When these mechanisms are correctly implemented and deployed, they ought not to adversely affect users, hosts, and other Internet components that do not employ these security mechanisms for protection of their traffic. These mechanisms also are designed to be algorithm-independent. This modularity permits selection of different sets of algorithms without affecting the other parts of the implementation. For example, different user communities may select different sets of algorithms (creating cliques) if required. Kent, Atkinson [Page 5] Internet Draft Security Architecture for IP November 1997 A standard set of default algorithms is specified to facilitate interoperability in the global Internet. The use of these algorithms, in conjunction with IPsec traffic protection and key management protocols, is intended to permit system and application developers to deploy high quality, Internet layer, cryptographic security technology. 2.2 Caveats and Assumptions The suite of IPsec protocols and associated default algorithms are designed to provide high quality security for Internet traffic. However, the security offered by use of these protocols ultimately depends on the quality of the their implementation, which is outside the scope of this set of standards. Moreover, the security of a computer system or network is a function of many factors, including personnel, physical, procedural, compromising emanations, and computer security practices. Thus IPsec is only one part of an overall system security architecture. Finally, the security afforded by the use of IPsec is critically dependent on many aspects of the operating environment in which the IPsec implementation executes. For example, defects in OS security, poor quality of random number sources, sloppy system management protocols and practices, etc. can all degrade the security provided by IPsec. As above, none of these environmental attributes are within the scope of this or other IPsec standards. 3. System Overview This section provides a high level description of how IPsec works, the components of the system, and how they fit together to provide the security services noted above. The goal of this description is to enable the reader to "picture" the overall process/system, see how it fits into the IP environment, and to provide context for later sections of this document, which describe each of the components in more detail. An IPsec implementation operates in a host or a security gateway environment, affording protection to IP traffic. The protection offered is based on requirements defined by a Security Policy Database (SPD) established and maintained by a user or system administrator, or by an application operating within constraints established by either of the above. In general, packets are selected for one of three processing modes based on IP and transport layer header information (Selectors, Section 4.4.2) matched against entries in the database (SPD). Each packet is either afforded IPsec security Kent, Atkinson [Page 6] Internet Draft Security Architecture for IP November 1997 services, discarded, or allowed to bypass IPsec, based on the applicable database policies identified by the Selectors. 3.1 What IPsec Does IPsec provides security services at the IP layer by enabling a system to select required security protocols, determine the algorithm(s) to use for the service(s), and put in place any cryptographic keys required to provide the requested services. IPsec can be used to protect one or more "paths" between a pair of hosts, between a pair of security gateways, or between a security gateway and a host. (The term "security gateway" is used throughout the IPsec documents to refer to an intermediate system that implements IPsec protocols. For example, a router or a firewall implementing IPsec is a security gateway.) The set of security services that IPsec can provide includes access control, connectionless integrity, data origin authentication, rejection of replayed packets (a form of partial sequence integrity), confidentiality (encryption), and limited traffic flow confidentiality. Because these services are provided at the IP layer, they can be used by any higher layer protocol, e.g., TCP, UDP, ICMP, BGP, etc. NOTE: When encryption is employed within IPsec, it prevents effective compression by lower protocol layers. However, IPsec does not provide its own compression services. Such services may be provided by existing higher layer protocols, or, in the future, in IP itself. The IETF working group, "IP Payload Compression Protocol (ippcp)" has the charter to "develop protocol specifications that make it possible to perform lossless compression on individual payloads before the payload is processed by a protocol that encrypts it. These specifications will allow for compression operations to be performed prior to the encryption of a payload by such protocols as IPsec." 3.2 How IPsec Works IPsec uses two protocols to provide traffic security -- Authentication Header (AH) and Encapsulating Security Payload (ESP). Both protocols are described in more detail in their respective RFCs [KA97a, KA97b]. o The IP Authentication Header (AH) [KA97a] provides connectionless integrity, data origin authentication, and an optional anti-replay service. o The Encapsulating Security Payload (ESP) protocol [KA97b] provides confidentiality (encryption), and limited traffic flow confidentiality. It also may provide connectionless Kent, Atkinson [Page 7] Internet Draft Security Architecture for IP November 1997 integrity, data origin authentication, and an anti-replay service. o Both AH and ESP are vehicles for access control, based on the distribution of cryptographic keys and the management of traffic flows relative to these security protocols. These protocols may be applied alone or in combination with each other to provide a desired set of security services in IPv4 and IPv6. Each protocol supports two modes of use: transport mode and tunnel mode. In transport mode the protocols provide protection primarily for upper layer protocols; in tunnel mode, the protocols are applied to tunneled IP packets. The differences between the two modes are discussed in Section 4. IPsec allows the user (or system administrator) to control the granularity at which a security service is offered. For example, one can create a single encrypted tunnel to carry all the traffic between two security gateways or a separate encrypted tunnel can be created for each TCP connection between each pair of hosts communicating across these gateways. IPsec management must incorporate facilities for specifying: o which security services to use and in what combinations o the granularity at which a given security protection should be applied o the algorithms used to effect cryptographic-based security Because these security services use shared secret values (cryptographic keys), IPsec relies on a separate set of mechanisms for putting these keys in place. (The keys are used for authentication/integrity and encryption services.) This document requires support for both manual and automatic distribution of keys. It specifies a specific public-key based approach (ISAKMP/Oakley -- [MSST97, Orm97, HC97]) for automatic key management, but other automated key distribution techniques MAY be used. For example, KDC-based systems such as Kerberos and other public-key systems such as SKIP could be employed. 3.3 Where IPsec May Be Implemented There are several ways in which IPsec may be implemented in a host or in conjunction with a router or firewall (to create a security gateway). Several common examples are provided below: a. Integration of IPsec into the native IP implementation. This requires access to the IP source code and is applicable to both hosts and security gateways. Kent, Atkinson [Page 8] Internet Draft Security Architecture for IP November 1997 b. "Bump-in-the-stack" (BITS) implementations, where IPsec is implemented "underneath" an existing implementation of an IP protocol stack, between the native IP and the local network drivers. Source code access for the IP stack is not required in this context, making this implementation approach appropriate for use with legacy systems. This approach, when it is adopted, is usually employed in hosts. c. The use of an outboard crypto processor is a common design feature of network security systems used by the military, and of some commercial systems as well. It is sometimes referred to as a "Bump-in-the-wire" (BITW) implementation. Such implementations may be designed to serve either a host or a gateway (or both). Usually the BITW device is IP addressable. When supporting a single host, it may be quite analogous to a BITS implementation, but in supporting a router or firewall, it must operate like a security gateway. 4. Security Associations This section defines Security Association management requirements for all IPv6 implementations and for those IPv4 implementations that implement AH, ESP, or both. The concept of a "Security Association" (SA) is fundamental to IPsec. Both AH and ESP make use of SAs and a major function of ISAKMP/Oakley is the establishment and maintenance of Security Associations. All implementations of AH or ESP MUST support the concept of a Security Association as described below. The remainder of this section describes various aspects of Security Association management, defining required characteristics for SA policy management, traffic processing, and SA management techniques. 4.1 Definition and Scope A Security Association (SA) is a simplex "connection" that affords security services to the traffic carried by it. Security services are afforded to an SA by the use of AH, or ESP, but not both. If both AH and ESP protection is applied to a traffic stream, then two (or more) SAs are created to afford protection to the traffic stream. To secure typical, bi-directional communication between two hosts, or between two security gateways, two Security Associations (one in each direction) are required. A security association is uniquely identified by a triple consisting of a Security Parameter Index (SPI), an IP Destination Address, and a security protocol (AH or ESP) identifier. In principle, the Destination Address may be a unicast address, an IP broadcast address, or a multicast group address. However, IPsec SA management Kent, Atkinson [Page 9] Internet Draft Security Architecture for IP November 1997 mechanisms currently are defined only for unicast SAs. Hence, in the discussions that follow, SAs will be described in the context of point-to-point communication, even though the concept is applicable in the point-to-multipoint case as well. As noted above, two types of SAs are defined: transport mode and tunnel mode. A transport mode SA is a security association between two hosts. In IPv4, a transport mode security protocol header appears immediately after the IP header and any options, and before any higher layer protocols (e.g., TCP or UDP). In IPv6, the security protocol header appears after the base IP header and extensions, but may appear before or after destination options, and before higher layer protocols. In the case of ESP, a transport mode SA provides security services only for these higher layer protocols, not for the IP header or any extension headers preceding the ESP header. In the case of AH, the protection is also extended to selected portions of the IP header (and options). For more details on the coverage afforded by AH, see the AH specification [KA97b]. A tunnel mode SA is essentially an SA applied to an IP tunnel. Whenever either end of a security association is a security gateway, the SA MUST be tunnel mode. Thus an SA between two security gateways is always a tunnel mode SA, as is an SA between a host and a security gateway. Note that for the case where traffic is destined for a security gateway, e.g., SNMP commands, the security gateway is acting as a host and transport mode is allowed. But in that case, the security gateway is not acting as a gateway, i.e., not transiting traffic. Two hosts MAY establish a tunnel mode SA between themselves. The requirement for any (transit traffic) SA involving a security gateway to be a tunnel SA arises due to the need to avoid potential problems with regard to fragmentation and reassembly of IPsec packets, and in circumstances where multiple paths (e.g., via different security gateways) exist to the same destination behind the security gateways. For a tunnel mode SA, there is an "outer" IP header that specifies the IPsec processing destination, plus an "inner" IP header that specifies the (apparently) ultimate destination for the packet. The security protocol header appears after the outer IP header, and before the inner IP header. If AH is employed in tunnel mode, portions of the outer IP header are afforded protection (as above), as well as all of the tunneled IP packet (i.e., all of the inner IP header is protected, as well as higher layer protocols). If ESP is employed, the protection is afforded only to the tunneled packet, not to the outer header. Kent, Atkinson [Page 10] Internet Draft Security Architecture for IP November 1997 4.2 Security Association Functionality The set of security services offered by an SA depends on the security protocol selected, the SA mode, the endpoints of the SA, and on the election of optional services within the protocol. For example, AH provides data origin authentication and connectionless integrity for IP datagrams (hereafter referred to as just "authentication"). The "precision" of the authentication service is a function of the granularity of the security association with which AH is employed, as discussed in Section 4.4.2, "Selectors". AH also offers an anti-replay (partial sequence integrity) service at the discretion of the receiver, to help counter denial of service attacks. AH is an appropriate protocol to employ when confidentiality is not required (or is not permitted, e.g , due to government restrictions on use of encryption). AH also provides authentication for selected portions of the IP header, which may be necessary in some contexts. For example, if the integrity of an IPv4 option or IPv6 extension header must be protected en route between sender and receiver, AH can provide this service (except for the non-predictable but mutable parts of the IP header.) ESP always provides confidentiality for traffic. (However, the strength of the confidentiality service will depend, in part, on the encryption algorithm employed.) ESP also may optionally provide authentication (as defined above). If authentication is negotiated for an ESP SA, the receiver also may elect to enforce an anti-replay service with the same features as the AH anti-replay service. The scope of the authentication offered by ESP is narrower than for AH, i.e., the IP header(s) "below" the ESP header is not protected. If only the upper layer protocols need to be authenticated, then ESP authentication is an appropriate choice and is more space efficient than use of AH encapsulating ESP. An ESP (tunnel mode) SA between two security gateways can offer partial traffic flow confidentiality. The use of tunnel mode allows the inner IP headers to be encrypted, concealing the identities of the (ultimate) traffic source and destination. Moreover, ESP payload padding also can be invoked to hide the size of the packets, further concealing the external characteristics of the traffic. Similar traffic flow confidentiality services may be offered when a mobile user is assigned a dynamic IP address in a dialup context, and establishes a (tunnel mode) ESP SA to a corporate firewall (acting as a security gateway). Kent, Atkinson [Page 11] Internet Draft Security Architecture for IP November 1997 4.3 Combining Security Associations The IP datagrams transmitted over an individual SA are afforded protection by exactly one security protocol, either AH or ESP, but not both. Sometimes a security policy may call for a combination of services for a particular traffic flow that is not achievable with a single SA. In such instances it will be necessary to employ multiple SAs to implement the required security policy. The term "security association bundle" or "SA bundle" is applied to a sequence of SAs through which traffic must be processed to satisfy a security policy. The order of the sequence is defined by the policy. (Note that the SAs that comprise a bundle may terminate at different endpoints. For example, one SA may extend between a mobile host and a security gateway and a second, nested SA may extend to a host behind the gateway.) Security associations may be combined into bundles in two ways: transport adjacency and iterated tunneling. o Transport adjacency refers to applying more than one security protocol to the same IP datagram, without invoking tunneling. This approach to combining AH and ESP allows for only one level of combination; further nesting yields no added benefit since the processing is performed at one IPsec instance the (ultimate) destination. o Iterated tunneling refers to the application of multiple layers of security protocols effected through IP tunneling. This approach allows for multiple levels of nesting, since each tunnel can originate or terminate at a different IPsec site along the path. These two approaches also can be combined, i.e., an SA bundle could be constructed from one tunnel mode SA and one or two transport mode SAs, applied in sequence. Note that nested tunnels can also occur where neither the source nor the destination endpoints of any of the tunnels are the same. In that case, there would be no host or security gateway with a bundle corresponding to the nested tunnels. For transport mode SAs, only one ordering of security protocols seems appropriate. AH is applied to both the upper layer protocols and (parts of) the IP header. Thus if AH is used in a transport mode, in conjunction with ESP, AH SHOULD appear as the first header after IP, prior to the appearance of ESP. In that context, AH is applied to the ciphertext output of ESP. In contrast, for tunnel mode SAs, one can imagine uses for various orderings of AH and ESP. The required set of SA bundle types that MUST be supported by a compliant IPsec implementation is described in Section 4.5. Kent, Atkinson [Page 12] Internet Draft Security Architecture for IP November 1997 4.4 Security Association Databases Many of the details associated with processing IP traffic in an IPsec implementation are largely a local matter, not subject to standardization. However, some external aspects of the processing must be standardized, to ensure interoperability and to provide a minimum management capability that is essential for productive use of IPsec. This section describes a general model for processing IP traffic relative to security associations, in support of these interoperability and functionality goals. The model described below is nominal; compliant implementations need not match details of this model as presented, but the external behavior of such implementations must be mappable to the externally observable characteristics of this model. There are two nominal databases in this model: the Security Policy Database and the Security Association Database. The former specifies the policies that determine the disposition of all IP traffic inbound or outbound from a host, security gateway, or BITS or BITW IPsec implementation. The latter database contains parameters that are associated with each (active) security association. This section also defines the concept of a Selector, a set of IP and upper layer protocol field values that is used by the Security Policy Database to map traffic to a policy, i.e., an SA (or SA bundle). 4.4.1 The Security Policy Database (SPD) Ultimately, a security association is a management construct used to enforce a security policy in the IPsec environment. Thus an essential element of SA processing is an underlying Security Policy Database (SPD) that specifies what services are to be offered to IP datagrams and in what fashion. The form of the database and its interface are outside the scope of this specification. However, this section does specify certain minimum management functionality that must be provided, to allow a user or system administrator to control how IPsec is applied to traffic transmitted or received by a host or transiting a security gateway. An SPD must discriminate among traffic that is afforded IPsec protection and traffic that is allowed to bypass IPsec. This applies to the IPsec protection to be applied by a sender and to the IPsec protection that must be present at the receiver. For any outbound or inbound datagram, three processing choices are possible: discard, bypass IPsec, or apply IPsec. The first choice refers to traffic that is not allowed to exit the host, traverse the security gateway, or be delivered to an application at all. The second choice refers to traffic that is allowed to pass without additional IPsec protection. The third choice refers to traffic that is afforded Kent, Atkinson [Page 13] Internet Draft Security Architecture for IP November 1997 IPsec protection, and for such traffic the SPD must specify the security services to be provided, protocols to be employed, algorithms to be used, etc. For every IPsec implementation, there MUST be an administrative interface that allows a user or system administrator to manage the SPD. This interface must allow the user (or system administrator) to specify the security processing to be applied to each packet entering or exiting the system, on a packet by packet basis. (In a host IPsec implementation making use of a socket interface, the SPD may not need to be consulted on a per packet basis, but the effect is still the same.) The management interface for the SPD MUST allow creation of entries consistent with the selectors defined in Section 4.4.2, and MUST support ordering of these entries. In host systems, applications MAY be allowed to select what security processing is to be applied to the traffic they generate and consume. (Means of signalling such requests to the IPsec implementation are outside the scope of this standard.) However, the system administrator MUST be able to specify whether or not a user or application can override (default) system policies. Note that application specified policies may satisfy system requirements, so that the system may not need to do additional IPsec processing beyond that needed to meet an application's requirements. The form of the management interface is not specified by this document and may differ for hosts vs. security gateways, and within hosts the interface may differ for socket-based vs. BITS implementations. However, this document does specify a standard set of SPD elements that all IPsec implementations MUST support. The SPD contains an ordered list of policy entries. Each policy entry is keyed by one or more selectors that define the set of IP traffic encompassed by this policy entry. (The required selector types are defined in Section 4.4.2.) These define the granularity of policies or SAs. Each entry includes an indication of whether traffic matching this policy will be bypassed, discarded, or subject to IPsec processing. If IPsec processing is to be applied, the entry includes an SA (or SA bundle) specification, listing the IPsec protocols, modes, and algorithms to be employed, including any nesting requirements. For example, an entry may call for all matching traffic to be protected by ESP in transport mode using 3DES-CBC with an explicit IV, nested inside of AH in tunnel mode using HMAC/SHA-1. For each selector, the policy entry specifies which of the following values should used in the SA: (a) the value in the packet, (b) the value associated with the policy, or (c) a wildcard. Case (c) permits the sharing of an SA (or SA bundle) by multiple SPD Kent, Atkinson [Page 14] Internet Draft Security Architecture for IP November 1997 entries. Case (a) can be used to prohibit sharing, even among packets that match the same SPD entry. As described below in Section 4.4.3, selectors may include "wildcard" entries and hence the selectors for two entries may overlap. (This is analogous to the overlap that arises with ACLs or filter entries in routers or packet filtering firewalls.) Thus, to ensure consistent, predictable processing, SPD entries MUST be ordered and the SPD MUST always be searched in the same order, so that the first matching entry is consistently selected. (This requirement is necessary as the effect of processing traffic against SPD entries must be deterministic, but there is no way to canonicalize SPD entries given the use of wildcards and enumerated lists for some selectors.) More detail on matching of packets against SPD entries is provided in Section 5. The SPD can be used to map traffic to specific SAs or SA bundles. Thus it can function both as the reference database for security policy and as the map to existing SAs (or SA bundles). (To accommodate the bypass and discard policies cited above, the SPD also MUST provide a means of mapping traffic to these functions, even though they are not, per se, IPsec processing.) The way in which the SPD operates is different for inbound vs. outbound traffic and it also may differ for host vs. security gateway, BITS, and BITW implementations. Sections 5.1 and 5.2 describe the use of the SPD for outbound and inbound processing, respectively. Because a security policy may require that more than one SA be applied to a specified set of traffic, in a specific order, the policy entry in the SPD must preserve these ordering requirements, when present. Thus, it must be possible for an IPsec implementation to determine that an outbound or inbound packet must be processed thorough a sequence of SAs. Conceptually, for outbound processing, one might imagine links (to the SAD) from an SPD entry for which there are active SAs, and each entry would consist of either a single SA or an ordered list of SAs that comprise an SA bundle. When a packet is matched against an SPD entry and there is an existing SA or SA bundle that can be used to carry the traffic, the processing of the packet is controlled by the SA or SA bundle entry on the list. For an inbound IPsec packet for which multiple IPsec SAs are to be applied, the lookup based on destination address, IPsec protocol, and SPI should identify a single SA. To allow minimization of the number of SAs, the linkage between the SPD and the SAD (at both the sender and the receiver) MUST allow an SA to be used in more than one bundle. The SPD also will be consulted when any IPsec implementation is the target of an SA establishment request from another IPsec Kent, Atkinson [Page 15] Internet Draft Security Architecture for IP November 1997 implementation, e.g., using ISAKMP/Oakley. 4.4.2 Selectors An SA (or SA bundle) may be fine-grained or coarse-grained, depending on the selectors used to define the set of traffic for the SA. For example, all traffic between two hosts may be carried via a single SA, and afforded a uniform set of security services. Alternatively, traffic between a pair of hosts might be spread over multiple SAs, depending on the applications being used (as defined by the Next Protocol and Port fields), with different security services offered by different SAs. Similarly, all traffic between a pair of security gateways could be carried on a single SA, or one SA could be assigned for each communicating host pair. The following selector parameters MUST be supported for SA management to facilitate control of SA granularity. Note that in the case of receipt of a packet with an ESP header, e.g., at an encapsulating security gateway or BITW implementation, the transport layer protocol, source/destination ports, and UserID (if present) may be opaque. - Destination IP Address (IPv4 or IPv6): this may be a single IP address (unicast, broadcast, or multicast group), an enumerated list or range of addresses, or a wildcard (mask) address. The latter two are required to support more than one destination system sharing the same SA (e.g., behind a security gateway). Note that this selector is conceptually different from the "Destination IP Address" field in the used to uniquely identify an SA. It could have the same value. [REQUIRED for all implementations] - Source IP Address(es) (IPv4 or IPv6): this may be a single IP address, an enumerated list or range of addresses, or a wildcard (mask) address. The latter two are required to support more than one source system sharing the same SA (e.g., behind a security gateway or in a multihomed host). [REQUIRED for all implementations] - UserID: a user identifier from the operating system. Note that one of the possible values of this selector is "OPAQUE". (The use of a User ID as an SA selector is sometimes referred to as "user-oriented keying.") [REQUIRED for host implementations, unless the layering of the implementation precludes access to this information, e.g., a BITS implementation need not support this selector.] - Data sensitivity level: (IPSO/CIPSO labels) [REQUIRED for all systems providing information flow security as Kent, Atkinson [Page 16] Internet Draft Security Architecture for IP November 1997 per Section 8, OPTIONAL for all other systems.] - Transport Layer Protocol: Obtained from the IPv4 "Protocol" or the IPv6 "Next Header" fields. This may be an individual protocol number, a list of protocol numbers, or a range of protocol numbers. These packet fields may not contain the Transport Protocol due to the presence of IP extension headers, e.g., a Routing Header, AH, ESP, Fragmentation Header, Destination Options, Hop-by-hop options, etc. Note that the Transport Protocol may not be available in the case of receipt of a packet with an ESP header, thus a value of "OPAQUE" SHOULD be supported. [REQUIRED for IPv6 implementations, MAY be supported in IPv4 implementations] NOTE: To locate the transport protocol, a system has to chain through the packet headers checking the "Protocol" or "Next Header" field until it encounters either one it recognizes as a transport protocol, or until it reaches one that isn't on its list of extension headers, or until it encounters an ESP header that renders the transport protocol opaque. - IPsec protocol (AH or ESP or AH/ESP): If present, this is obtained from the IPv4 "Protocol" field or the IPv6 "Next Header" field. [REQUIRED for all implementations] NOTE: The "Protocol" or "Next Header" field could contain a Transport Protocol, Routing Header, AH, ESP, Fragmentation Header, Destination Options, Hop-by-hop options, etc. Although IPv6 recommends a particular order for extension headers, it also specifies that the implementation must be prepared to accept them in any order. So to check for the existence of an IPsec header, a system has to chain through the packet headers checking the Protocol/Next Header field until it has checked all that are not opaque. - Source and Destination (e.g., TCP/UDP) Ports: These may be individual UDP or TCP port values, an enumerated list of ports, or a wildcard port. (The use of the Next Protocol field and the Source and/or Destination Port fields (in conjunction with the Source and/or Destination Address fields), as an SA selector is sometimes referred to as "session-oriented keying."). Note that the source and destination ports may not be available in the case of receipt of a packet with an ESP header, thus a value of "OPAQUE" SHOULD be supported. [REQUIRED for all implementations] Kent, Atkinson [Page 17] Internet Draft Security Architecture for IP November 1997 - IPv6 Class (from IP header): This may be expressed as a wildcard value or a specific IPv6 Class value. [REQUIRED for all systems that implement IPv6] - IPv6 Flow Label (from IP header): This may be expressed as a wildcard value or a specific Flow Label. The IPv6 spec (RFC 1883) calls for all datagrams for a given IPv6 Flow Label to have the same Source Address, Destination Address, Hop-by-hop Options header, and Routing Header. The Flow Label may be assigned on a per socket basis. It would then be correlated with the Source/Destination and could be used to provide finer granularity selection of security association(s). [REQUIRED for all systems that implement IPv6] - IPv4 Type of Service (TOS): Obtained from the IPv4 header. This may be expressed as a wildcard or an explicit value. [REQUIRED for all IPv4 systems that implement IPsec] The IPsec implementation context determines how selectors are used. For example, a host implementation integrated into the stack may make use of a socket interface. When a new connection is established the SPD can be consulted and an SA (or SA bundle) bound to the socket. Thus traffic sent via that socket need not result in additional lookups to the SPD/SAD. In contrast, a BITS, BITW, or security gateway implementation needs to look at each packet and perform an SPD/SAD lookup based on the selectors. The allowable values for the selector fields differ between the traffic flow, the security association, and the security policy. The following table summarizes the kinds of entries that one needs to be able to express in the SPD and SAD. It shows how they relate to the fields in data traffic being subjected to IPsec screening. (Note: the "wild" or "wildcard" entry for src and dst addresses includes a mask, list, etc.) Kent, Atkinson [Page 18] Internet Draft Security Architecture for IP November 1997 Field Traffic Value SAD Entry SPD Entry -------- ------------- ---------------- -------------------- src addr single IP addr single,list,wild single,list,wildcard dst addr single IP addr single IP addr single,list,wildcard xpt protocol* xpt protocol single,list,wild single,list,wildcard src port* single src port single,list,wild single,list,wildcard dst port* single dst port single,list,wild single,list,wildcard user id* single user id single,list,wild single,list,wildcard IPsec prot AH,ESP,AH/ESP single or wild single or wildcard IPv6 class IPv6 class single,list,wild single,list,wildcard IPv6 flow IPv6 flow single,list,wild single,list,wildcard IPv4 TOS IPv4 TOS single,list,wild single,list,wildcard sec. labels single value single,list,wild single,list,wildcard * The SAD and SPD entries for these fields could be "OPAQUE" because the traffic value is encrypted. 4.4.3 Security Association Database (SAD) In each IPsec implementation there is a nominal Security Association Database, in which each entry defines the parameters associated with one SA. Each SA has an entry in the SAD. For outbound processing, entries are pointed to by entries in the SPD. Note that if an SPD entry does not currently point to an SA that is appropriate for the packet, before it creates an SA, the implementation should check to see if the SAD already has an appropriate SA (created by some other SPD entry). For inbound processing, each entry in the SAD is indexed by a destination IP address, IPsec protocol type, and SPI. The following parameters are associated with each entry in the SAD. This description does not purport to be a MIB, but only a specification of the minimal data items required to support an SA in an IPsec implementation. For inbound processing: The following packet fields are used to look up the SA in the SAD: o Outer Header's Destination IP address: the IPv4 or IPv6 Destination address. [REQUIRED for all implementations] o IPsec Protocol: AH or ESP, used as an index for SA lookup in this database. Specifies the IPsec protocol to be applied to the traffic on this SA. [REQUIRED for all implementations] o SPI: the 32-bit value used to distinguish among different SAs terminating at the same destination and using the same IPsec protocol. [REQUIRED for all implementations] Kent, Atkinson [Page 19] Internet Draft Security Architecture for IP November 1997 For each of the selectors defined in Section 4.4.2, the SA entry in the SAD MUST contain the value or values which were negotiated at the time the SA was created. For the sender, these values are used to decide whether a given SA is appropriate for use with an outbound packet. This is part of checking to see if there is an existing SA that can be used. For the receiver, these values are used to check that the selector values in an inbound packet match those for the SA (and thus indirectly those for the matching policy). For the receiver, this is part of verifying that the SA was appropriate for this packet. (See Section 6 for rules for ICMP messages.) These fields can have the form of specific values, lists, ranges, wildcards, or "OPAQUE" as described in section 4.4.2, "Selectors". The following SAD fields are used in doing IPsec processing: o Sequence Number Counter: a 32-bit value used to generate the Sequence Number field in AH or ESP headers. [REQUIRED for all implementations, but used only for outbound traffic.] o Sequence Counter Overflow: a flag indicating whether overflow of the Sequence Number Counter should generate an auditable event and prevent transmission of additional packets on the SA. [REQUIRED for all implementations, but used only for outbound traffic.] o Anti-Replay Window: a 32-bit counter and a bit-map (or equivalent) used to determine whether an inbound AH or ESP packet is a replay. [REQUIRED for all implementations but used only for inbound traffic.] o AH Authentication algorithm, keys, etc. [REQUIRED for AH implementations] o ESP Encryption algorithm, keys, IV mode, IV, etc. [REQUIRED for ESP implementations] o ESP authentication algorithm, keys, etc. If the authentication service is not selected, this field will be null. [REQUIRED for ESP implementations] o Lifetime of this Security Association: a time interval after which an SA must be replaced with a new SA (and new SPI) or terminated, plus an indication of which of these actions should occur. This may be expressed as a time or byte count. [REQUIRED for all implementations] o IPsec protocol mode: tunnel, transport or wildcard. Indicates which mode of AH or ESP is applied to traffic on this SA. [REQUIRED for all implementations, unless implicitly defined by context] o Path MTU: any observed path MTU and aging variables. See Kent, Atkinson [Page 20] Internet Draft Security Architecture for IP November 1997 Section 6.1.2.4 [REQUIRED for all implementations but used only for outbound traffic] 4.5 Basic Combinations of Security Associations This section describes four examples of combinations of security associations that MUST be supported by compliant IPsec hosts or security gateways. Additional combinations of AH and/or ESP in tunnel and/or transport modes MAY be supported at the discretion of the implementor. Compliant implementations MUST be capable of generating these four combinations and on receipt, of processing them, but SHOULD be able to receive and process any combination. The diagrams and text below describe the basic cases. The legend for the diagrams is: ==== = one or more security associations (AH or ESP, transport or tunnel) ---- = connectivity (or if so labelled, administrative boundary) Hx = host x SGx = security gateway x X* = X supports IPsec NOTE: The security associations below can be either AH or ESP. The mode (tunnel vs transport) is determined by the nature of the endpoints. For host-to-host SAs, the mode can be either transport or tunnel. Case 1. The case of providing end-to-end security between 2 hosts across the Internet (or an Intranet). ==================================== | | H1* ------ (Inter/Intranet) ------ H2* Note that either transport or tunnel mode can be selected by the hosts. Also, in transport mode at the sender, first ESP, then AH can be applied to the packet. So the headers in a packet between H1 and H2 could look like any of the following: Transport Tunnel ----------------- --------------------- 1. [IP1][AH][upper] 4. [IP2][AH][IP1][upper] 2. [IP1][ESP][upper] 5. [IP2][ESP][IP1][upper] 3. [IP1][AH][ESP][upper] Kent, Atkinson [Page 21] Internet Draft Security Architecture for IP November 1997 Case 2. This case illustrates simple virtual private networks support. =========================== | | ---------------------|---- ---|----------------------- | | | | | | | H1 -- (Local --- SG1* |--- (Internet) ---| SG2* --- (Local --- H2 | | Intranet) | | Intranet) | -------------------------- --------------------------- admin. boundary admin. boundary Only tunnel mode is required here. So the headers in a packet between SG1 and SG2 could look like either of the following: Tunnel --------------------- 4. [IP2][AH][IP1][upper] 5. [IP2][ESP][IP1][upper] Case 3. This case builds on case 2, adding end-to-end security between the sending and receiving hosts. It imposes no new requirements on the hosts or security gateways, other than a requirement for a security gateway to be configurable to pass IPsec traffic (including ISAKMP traffic) for hosts behind it. =============================================================== | | | ========================= | | | | | ---|-----------------|---- ---|-------------------|--- | | | | | | | | | H1* -- (Local --- SG1* |-- (Internet) --| SG2* --- (Local --- H2* | | Intranet) | | Intranet) | -------------------------- --------------------------- admin. boundary admin. boundary Kent, Atkinson [Page 22] Internet Draft Security Architecture for IP November 1997 Case 4. This covers the situation where a remote host (H1) uses the Internet to reach an organization's firewall (SG2) and to then gain access to some server or other machine (H2). The remote host could be a mobile host (H1) dialing up to a local PPP/ARA server (not shown) on the Internet and then crossing the Internet to the home organization's firewall (SG2), etc. The details of support for this case, (how H1 locates SG2, authenticates it, and verifies its authorization to represent H2) are discussed in Section 4.4.3, "Locating a Security Gateway". ====================================================== | | |============================== | || | | || ---|----------------------|--- || | | | | H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* | ^ | Intranet) | | ------------------------------ could be dialup admin. boundary (optional) to PPP/ARA server Only tunnel mode is required between H1 and SG2. So the headers in a packet between H1 and SG2 would look like one of the ones in case 2. The following combinations of AH and ESP MUST be supported in the indicated contexts: - Cases 1, 3, 4 (between H1 and H2): a. AH in transport mode b. ESP in transport mode b. AH followed by ESP in transport mode d. any one of a, b, or c above AH or ESP in tunnel mode - Cases 1, 2, 3, and 4 (all SAs shown): e. AH in tunnel mode f. ESP in tunnel mode As noted above, support for additional combinations of AH and ESP is optional. Use of other, optional combinations may adversely affect interoperability. 4.6 SA and Key Management IPsec mandates support for both manual and automated SA and cryptographic key management. The IPsec protocols, AH and ESP, are largely independent of the associated SA management techniques, Kent, Atkinson [Page 23] Internet Draft Security Architecture for IP November 1997 although the techniques involved do affect some of the security services offered by the protocols. For example, the optional anti- replay services available for AH and ESP require automated SA management. Moreover, the granularity of key distribution employed with IPsec determines the granularity of authentication provided. (See also a discussion of this issue in Section 4.7.) In general, data origin authentication in AH and ESP is limited by the extent to which secrets used with the authentication algorithm (or with a key management protocol that creates such secrets) are shared among multiple possible sources. The following text describes the minimum requirements for both types of SA management. 4.6.1 Manual Techniques The simplest form of management is manual management, in which a person manually configures each system with keying material and security association management data relevant to secure communication with other systems. Manual techniques are practical in small, static environments but they do not scale well. For example, a company could create a Virtual Private Network (VPN) using IPsec in security gateways at several sites. If the number of sites is small, and since all the sites come under the purview of a single administrative domain, this is likely to be a feasible context for manual management techniques. In this case, the security gateway might selectively protect traffic to and from other sites within the organization using a manually configured key, while not protecting traffic for other destinations. It also might be appropriate when only selected communications need to be secured. A similar argument might apply to use of IPsec entirely within an organization for a small number of hosts and/or gateways. Manual management techniques often employ statically configured, symmetric keys, though other options also exist. 4.6.2 Automated SA and Key Management Widespread deployment and use of IPsec requires an Internet-standard, scalable, automated, SA management protocol. Such support is required to facilitate use of the anti-replay features of AH and ESP, and to accommodate on-demand creation of SAs, e.g., for user- and session-oriented keying. (Note that the notion of "rekeying" an SA actually implies creation of a new SA with a new SPI, a process that generally implies use of an automated SA/key management protocol.) The default automated key management protocol selected for use with IPsec is ISAKMP/Oakley [MSST97, Orm97, HC97] under the IPsec domain of interpretation [Pip97]. Other automated SA management protocols Kent, Atkinson [Page 24] Internet Draft Security Architecture for IP November 1997 MAY be employed. When an automated SA/key management protocol is employed, the output from this protocol may be used to generate multiple keys, e.g., for a single ESP SA. This may arise because: o the encryption algorithm uses multiple keys (e.g., triple DES) o the authentication algorithm uses multiple keys o both encryption and authentication algorithms are employed The Key Management System may provide a separate string of bits for each key or it may generate one string of bits from which all of them are extracted. If a single string of bits is provided, care needs to be taken to ensure that the parts of the system that map the string of bits to the required keys do so in the same fashion at both ends of the SA. To ensure that the IPsec implementations at each end of the SA use the same bits for the same keys, and irrespective of which part of the system divides the string of bits into individual keys, the encryption key(s) MUST be taken from the first (left-most, high- order) bits and the authentication key(s) MUST be taken from the remaining bits. The number of bits for each key is defined in the relevant algorithm specification RFC. In the case of multiple encryption keys or multiple authentication keys, the specification for the algorithm must specify the order in which they are to be selected from a single string of bits provided to the algorithm. 4.6.3 Locating a Security Gateway This section discusses issues relating to how a host learns about the existence of relevant security gateways and once a host has contacted these security gateways, how it knows that these are the correct security gateways. The details of where the required information is stored is a local matter. Consider a situation in which a remote host (H1) is using the Internet to gain access to a server or other machine (H2) and there is a security gateway (SG2), e.g., a firewall, through which H1's traffic must pass. An example of this situation would be a mobile host (Road Warrior) crossing the Internet to the home organization's firewall (SG2). (See Case 4 in the section 4.5 Basic Combinations of Security Associations.) This situation raises several issues: Kent, Atkinson [Page 25] Internet Draft Security Architecture for IP November 1997 1. How does H1 know/learn about the existence of the security gateway SG2? 2. How does it authenticate SG2, and once it has authenticated SG2, how does it confirm that SG2 has been authorized to represent H2? 3. How does SG2 authenticate H1 and verify that H1 is authorized to contact H2? 4. How does H1 know/learn about backup gateways which provide alternate paths to H2? To address these problems, a host or security gateway MUST have an administrative interface that allows the user/administrator to configure the address of a security gateway for any sets of destination addresses that require its use. This includes the ability to configure: o the requisite information for locating and authenticating the security gateway and verifying its authorization to represent the destination host. o the requisite information for locating and authenticating any backup gateways and verifying their authorization to represent the destination host. It is assumed that the SPD is also configured with policy information that covers any other IPsec requirements for the path to the security gateway and the destination hos. This document does not address the issue of how to automate the discovery/verification of security gateways. 4.7 Security Associations and Multicast The receiver-orientation of the Security Association implies that, in the case of unicast traffic, the destination system will normally select the SPI value. By having the destination select the SPI value, there is no potential for manually configured Security Associations to conflict with automatically configured (e.g., via a key management protocol) Security Associations or for Security Associations from multiple sources to conflict with each other. For multicast traffic, there are multiple destination systems per multicast group. So some system or person will need to coordinate among all multicast groups to select an SPI or SPIs on behalf of each multicast group and then communicate the group's IPsec information to all of the legitimate members of that multicast group via mechanisms not defined here. Multiple senders to a multicast group SHOULD use a single Security Association (and hence Security Parameter Index) for all traffic to Kent, Atkinson [Page 26] Internet Draft Security Architecture for IP November 1997 that group when a symmetric key encryption or authentication algorithm is employed. In such circumstances, the receiver knows only that the message came from a system possessing the key for that multicast group. In such circumstances, a receiver generally will not be able to authenticate which system sent the multicast traffic. Specifications for other, more general multicast cases are deferred to later IPsec documents. At the time this specification was published, automated protocols for multicast key distribution were not considered adequately mature for standardization. For multicast groups having relatively few members, manual key distribution or multiple use of existing unicast key distribution algorithms such as modified Diffie-Hellman appears feasible. For very large groups, new scalable techniques will be needed. An example of current work in this area is the Group Key Management Protocol (GKMP) [HM97]. 5. IPsec Traffic Processing 5.1 Outbound IPsec Traffic Processing 5.1.1 Selecting and Using an SA or SA Bundle In a security gateway or BITW implementation (and in many BITS implementations), each outbound packet is compared against the SPD to determine what processing is required for the packet. If the packet is to be discarded, this is an auditable event. If the traffic is allowed to bypass IPsec processing, the packet continues through "normal" processing for the environment in which the IPsec processing is taking place. If IPsec processing is required, the packet is either mapped to an existing SA (or SA bundle), or a new SA (or SA bundle) is created for the packet. Since a packet's selectors might match multiple policies or multiple extant SAs and since the SPD is ordered, but the SAD is not, IPsec MUST: 1. Match the packet's selector fields against the outbound policies in the SPD to locate the first appropriate policy, which will point to zero or more SA bundles in the SAD. 2. Match the packet's selector fields against those in the SA bundles found in (1) to locate the first SA bundle that matches. If no SAs were found or none match, search the SAD for an SA (created by other SPD entries) that matches. If none exist, create an appropriate SA bundle. 3. Use the SA bundle found/created in (2) to do the required IPsec processing, e.g., authenticate and encrypt. Kent, Atkinson [Page 27] Internet Draft Security Architecture for IP November 1997 In a host IPsec implementation based on sockets, the SPD will be consulted whenever a new socket is created, to determine what, if any, IPsec processing will be applied to the traffic that will flow on that socket. 5.1.2 Header Construction for Tunnel Mode This section describes the handling of the inner and outer IP headers, extension headers, and options for AH and ESP tunnels. This includes how to construct the encapsulating (outer) IP header, how to handle fields in the inner IP header, and what other actions should be taken. The general idea is modeled after the one used in RFC 2003, "IP Encapsulation with IP": o The outer IP header Source Address and Destination Address identify the "endpoints" of the tunnel (the encapsulator and decapsulator). The inner IP header Source Address and Destination Addresses identify the original sender and recipient of the datagram, respectively. o The inner IP header is not changed except to decrement the TTL as noted below, and remains unchanged during its delivery to the tunnel exit point. o No change to IP options or extension headers in the inner header occurs during delivery of the encapsulated datagram through the tunnel. o If need be, other protocol headers such as the IP Authentication header may be inserted between the outer IP header and the inner IP header. The tables in the following sub-sections show the handling for the different header/option fields (constructed = the value in the outer field is constructed independently of the value in the inner). Kent, Atkinson [Page 28] Internet Draft Security Architecture for IP November 1997 5.1.2.1 IPv4 -- Header Construction for Tunnel Mode <-- How Outer Hdr Relates Inner Hdr --> Outer Hdr at Inner Hdr at IPv4 Encapsulator Decapsulator Header fields: -------------------- ------------ version 4 (1) no change header length constructed no change TOS copied from inner hdr (5) no change total length constructed no change ID constructed no change flags (DF,MF) constructed, DF (4) no change fragmt offset constructed no change TTL constructed (2) decrement (2) protocol AH, ESP, routing hdr no change checksum constructed no change src address constructed (3) no change dest address constructed (3) no change Options never copied no change 1. The IP version in the encapsulating header can be different from the value in the inner header. 2. The TTL in the inner header is decremented by the encapsulator prior to forwarding and by the decapsulator if it forwards the packet. 3. src and dest addresses depend on the SA, which is used to determine the dest address which in turn determines which src address (net interface) is used to forward the packet. 4. configuration determines whether to copy from the inner header (IPv4 only), clear or set the DF. 5. If Inner Hdr is IPv4, copy the TOS. If Inner Hdr is IPv6, map the Class to TOS. Kent, Atkinson [Page 29] Internet Draft Security Architecture for IP November 1997 5.1.2.2 IPv6 -- Header Construction for Tunnel Mode See previous section 5.1.2 for notes 1-5 indicated by (footnote number). <-- How Outer Hdr Relates Inner Hdr ---> Outer Hdr at Inner Hdr at IPv6 Encapsulator Decapsulator Header fields: -------------------- ------------ version 6 (1) no change class copied or configured (6) no change flow id copied or configured no change len constructed no change next header AH,ESP,routing hdr no change hop count constructed (2) decrement (2) src address constructed (3) no change dest address constructed (3) no change Extension headers never copied no change 6. If Inner Hdr is IPv6, copy the Class. If Inner Hdr IPv4, map the TOS to Class. 5.2 Processing Inbound IPsec Traffic Prior to performing AH or ESP processing, any IP fragments are reassembled. Each inbound IP datagram to which IPsec processing will be applied is identified by the appearance of the AH or ESP values in the IP Next Protocol field (or of AH or ESP as an extension header in the IPv6 context). Note: Appendix C contains sample code for a bitmask check for a 32 packet window that can be used for implementing anti-replay service. 5.2.1 Selecting and Using an SA or SA Bundle Mapping the IP datagram to the appropriate SA is simplified because of the presence of the SPI in the AH or ESP header. Note that the selector checks are made on the inner headers not the outer (tunnel) headers. The steps followed are: 1. Use the packet's destination address (outer IP header), IPsec protocol, and SPI to look up the SA in the SAD. 2. Use the SA found in (1) to do the IPsec processing, e.g., authenticate and decrypt. This step includes matching the packet's (Inner Header if tunneled) selectors to the selectors in the SA. Local policy determines the specificity of the SA selectors (single value, list, range, wildcard). In general, a packet's source address SHOULD match the SA Kent, Atkinson [Page 30] Internet Draft Security Architecture for IP November 1997 selector value. (However, an AH or ESP-protected ICMP packet from a gateway may legitimately appear in a tunnel mode SA with a source IP address other than that bound to the SA, and thus such packets should be permitted as exceptions to this check. See Section 6.) Other packet fields MAY match the SA selector values as required by local policy. Do (1) and (2) for every IPsec header until a Transport Protocol Header or an IP header that is NOT for this system is encountered. Keep track of what SAs have been used and their order of application. 3. Find an incoming policy in the SPD that matches the packet. This could be done, for example, by use of backpointers from the SAs to the SPD or by matching the packet's selectors (Inner Header if tunneled) against those of the policy entries in the SPD. 4. Check whether the required IPsec processing has been applied, i.e., verify that the SA's found in (1) and (2) match the kind and order of SAs required by the policy found in (3). NOTE: The correct "matching" policy will not necessarily be the first inbound policy found. If the check in (4) fails, steps (3) and (4) are repeated until all policy entries have been checked or until the check succeeds. At the end of these steps, pass the resulting packet to the Transport Layer or forward the packet. Note that any IPsec headers processed in these steps may have been removed, but that this information, i.e., what SAs were used and the order of their application, may be needed for subsequent IPsec or firewall processing. 5.2.2 Handling of AH and ESP tunnels The handling of the inner and outer IP headers, extension headers, and options for AH and ESP tunnels should be performed as described in the tables in Section 5.1. 6. ICMP Processing (relevant to IPsec) An ICMP message protected by AH or ESP and generated by a router SHOULD be processed and forwarded in a tunnel mode SA, and MUST NOT be subjected to source address checks. An ICMP message protected by AH or ESP and generated by a router MUST NOT be forwarded on a transport mode SA (unless the SA has been established to the router acting as a host, e.g., a Telnet connection used to manage a router). An ICMP message generated by a host SHOULD be checked against the Kent, Atkinson [Page 31] Internet Draft Security Architecture for IP November 1997 source IP address selectors bound to the SA in which the message arrives. The table in Appendix D characterize ICMP messages as being either host generated, router generated, both, unknown/unassigned. ICMP messages falling into the last two categories should be handled as determined by the receiver's policy. An ICMP message not protected by AH or ESP is unauthenticated and its processing and/or forwarding may result in denial of service. This suggests that, in general, it would be desirable to ignore such messages. However, it is expected that many routers (vs. security gateways) will not implement IPsec for transit traffic and thus strict adherence to this rule would cause many ICMP messages to be discarded. The result is that some critical IP functions would be lost, e.g., redirection and PMTU processing. Thus it MUST be possible to configure an IPsec implementation to accept or reject (router) ICMP traffic as per local security policy. The remainder of this section addresses how PMTU processing MUST be performed at hosts and security gateways. It addresses processing of both authenticated and unauthenticated ICMP PMTU messages. However, as noted above, unauthenticated ICMP messages MAY be discarded based on local policy. 6.1 PMTU/DF Processing 6.1.1 DF Bit In cases where a system (host or gateway) adds an encapsulating header (ESP tunnel or AH tunnel), it MUST support the option of copying the DF bit from the original packet to the encapsulating header (and processing ICMP PMTU messages). This means that it MUST be possible to configure the system's treatment of the DF bit (set, clear, copy from encapsulated header) for each interface. (See Appendix B for rationale.) 6.1.2 Path MTU Discovery (PMTU) This section discusses IPsec handling for Path MTU Discovery messages. ICMP PMTU is used here to refer to an ICMP message for: IPv4 (RFC 792): - Type = 3 (Destination Unreachable) - Code = 4 (Fragmentation needed and DF set) - Next-Hop MTU in the low-order 16 bits of the second word of the ICMP header (labelled "unused" in RFC 792), with high-order 16 bits set to zero Kent, Atkinson [Page 32] Internet Draft Security Architecture for IP November 1997 IPv6 (RFC 1885): - Type = 2 (Packet Too Big) - Code = 0 (Fragmentation needed and DF set) - Next-Hop MTU in the 32 bit MTU field of the ICMP6 message 6.1.2.1 Propagation of PMTU The amount of information returned with the ICMP PMTU message (IPv4 or IPv6) is limited and this affects what selectors are available for use in further propagating the PMTU information. (See Appendix B for more detailed discussion of this topic.) o PMTU message with 64 bits of IPsec header -- If the ICMP PMTU message contains only 64 bits of the IPsec header (minimum for IPv4), then a security gateway MUST support the following options on a per SPI/SA basis: a. if the originating host can be determined (or the possible sources narrowed down to a manageable number), send the PMTU information to all the possible originating hosts. b. if the originating host cannot be determined, store the PMTU with the SA and wait until the next packet(s) arrive from the originating host for the relevant security association. If the packet(s) are bigger than the PMTU, drop the packet(s), and compose ICMP PMTU message(s) with the new packet(s) and the updated PMTU, and send the ICMP message(s) about the problem to the originating host. Retain the PMTU information for any message that might arrive subsequently (see Section 6.1.2.4, "PMTU Aging"). o PMTU message with >64 bits of IPsec header -- If the ICMP message contains more information from the original packet, e.g., the 576 byte minimum for IPv6, then there MAY be enough non-opaque information to immediately determine to which host to propagate the ICMP/PMTU message and to provide that system with the 5 fields (source address, destination address, source port, destination port, transport protocol) needed to determine where to store/update the PMTU. Under such circumstances, a security gateway MUST generate an ICMP PMTU message immediately upon receipt of an ICMP PMTU from further down the path. o Distributing the PMTU to the Transport Layer -- The host mechanism for getting the updated PMTU to the transport layer is unchanged, as specified in RFC 1191 (Path MTU Discovery). Kent, Atkinson [Page 33] Internet Draft Security Architecture for IP November 1997 6.1.2.2 Calculation of PMTU The calculation of PMTU from an ICMP PMTU MUST take into account the addition of any IPsec header -- AH transport, ESP transport, AH/ESP transport, ESP tunnel, AH tunnel. (See Appendix B for discussion of implementation issues.) 6.1.2.3 Granularity of PMTU Processing In hosts, the granularity with which ICMP PMTU processing can be done differs depending on the implementation situation. Looking at a host, there are 3 situations that are of interest with respect to PMTU issues (See Appendix B for additional details on this topic.): a. Integration of IPsec into the native IP implementation b. Bump-in-the-stack implementations, where IPsec is implemented "underneath" an existing implementation of a TCP/IP protocol stack, between the native IP and the local network drivers c. No IPsec implementation -- This case is included because it is relevant in cases where a security gateway is sending PMTU information back to a host. Only in case (a) can the PMTU data be maintained at the same granularity as communication associations. In (b) and (c), the IP layer will only be able to maintain PMTU data at the granularity of source and destination IP addresses (and optionally ToS), as described in RFC 1191. This is an important difference, because more than one communication association may map to the same source and destination IP addresses, and each communication association may have a different amount of IPsec header overhead (e.g., due to use of different transforms or different algorithms). Implementation of the calculation of PMTU and support for PMTUs at the granularity of individual communication associations is a local matter. However, a socket-based implementation of IPsec in a host SHOULD maintain the information on a per socket basis. Bump in the stack systems MUST pass an ICMP PMTU to the host IP implementation, after adjusting it for any IPsec header overhead added by these systems. The calculation of the overhead SHOULD be determined by analysis of the SPI and any other selector information present in a returned ICMP PMTU message. 6.1.2.4 PMTU Aging In all systems (host or gateway) implementing IPsec and maintaining PMTU information, the PMTU associated with a security association (transport or tunnel) MUST be "aged" and some mechanism put in place for updating the PMTU in a timely manner, especially for discovering Kent, Atkinson [Page 34] Internet Draft Security Architecture for IP November 1997 if the PMTU is smaller than it needs to be. A given PMTU has to remain in place long enough for a packet to get from the source end of the security association to the system at the other end of the security association and propagate back an ICMP error message if the current PMTU is too big. Note that if there are nested tunnels, multiple packets and round trip times might be required to get an ICMP message back to an encapsulator or originating host. Systems SHOULD use the approach described in the Path MTU Discovery document (RFC 1191, Section 6.3), which suggests periodically resetting the PMTU to the first-hop data-link MTU and then letting the normal PMTU Discovery processes update the PMTU as necessary. The period SHOULD be configurable. 7. Auditing Not all systems that implement IPsec will implement auditing. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in the AH and ESP specifications and for each of these events a minimum set of information that SHOULD be included in an audit log is defined. Additional information also MAY be included in the audit log for each of these events, and additional events, not explicitly called out in this specification, also MAY result in audit log entries. There is no requirement for the receiver to transmit any message to the purported transmitter in response to the detection of an auditable event, because of the potential to induce denial of service via such action. 8. Use in Systems Supporting Information Flow Security A multi-level secure (MLS) network is one where a single network is used to communicate data with different sensitivity information labels (e.g., Unclassified, Company Proprietary, Secret) [DoD85, DoD87]. The IP security mechanisms can easily support MLS networking. MLS networking requires the use of strong Mandatory Access Controls (MAC), which unprivileged users or unprivileged processes are incapable of controlling or violating [BL73]. This section pertains only to the use of these IP security mechanisms in MLS environments. Nothing in this section applies to systems not claiming to provide MLS. As used in this section, "sensitivity information" might include implementation-defined hierarchic levels, categories, and/or releasability information. The Authentication Header can be used to provide strong assurance for both mandatory access control decisions in multi-level networks and Kent, Atkinson [Page 35] Internet Draft Security Architecture for IP November 1997 discretionary access control decisions in all kinds of networks. If explicit IP sensitivity information (e.g., IPSO [Ken91]) is used and confidentiality is not considered necessary within the particular operational environment, the Authentication Header can be used to provide authentication for the entire packet, including cryptographic binding of the sensitivity information to the IP header and user data. This is a significant improvement over labeled IPv4 networks where the sensitivity information is trusted even though there is no authentication or cryptographic binding of the information to the IP header and user data. IPv4 networks might or might not use explicit labelling. IPv6 will normally use implicit sensitivity information that is part of the IPsec Security Association but not transmitted with each packet instead of using explicit sensitivity information. All explicit IP sensitivity information MUST be authenticated using either ESP, AH, or both. Encryption is useful and can be desirable even when all of the hosts are within a protected environment, for example, behind a firewall or disjoint from any external connectivity. The Internet-standard encryption algorithm could be used, in conjunction with appropriate key management, to provide strong Discretionary Access Controls (DAC). Key management could use sensitivity information to provide Mandatory Access Controls (MAC). Some environments, depending on their local policy, might consider the Internet-standard encryption algorithm sufficiently strong to provide MAC. IPsec implementations on systems claiming to provide MLS SHOULD be capable of using IPsec to provide MAC for IP-based communications. 8.1 Relationship Between Security Associations and Data Sensitivity Both the Encapsulating Security Payload and the Authentication Header could be combined with appropriate Security Association policies to provide multi-level secure networking. In this case each SA (or SA bundle) is normally used for only a single instance of sensitivity information. For example, "PROPRIETARY - Internet Engineering" must be associated with a different SA (or SA bundle) from "PROPRIETARY - Finance". 8.2 Sensitivity Consistency Checking An MLS implementation (both host and router) MAY associate sensitivity information, or a range of sensitivity information with an interface, or a configured IP address with its associated prefix (the latter is sometimes referred to as a logical interface, or an interface alias). If such properties exist, an implementation SHOULD compare the sensitivity information associated with the packet against the sensitivity information associated with the interface or address/prefix from which the packet arrived, or through which the Kent, Atkinson [Page 36] Internet Draft Security Architecture for IP November 1997 packet will depart. This check will either verify that the sensitivities match, or that the packet's sensitivity falls within the range of the interface or address/prefix. The checking SHOULD be done on both inbound and outbound processing. 8.3 Additional MLS Attributes for Security Association Databases Section 4.4 discussed two Security Association databases (the Security Policy Database (SPD) and the Security Association Database (SAD)) and the associated policy selectors and SA attributes. MLS networking introduces an additional selector/attribute: - Sensitivity information. The Sensitivity information aids in selecting the appropriate algorithms and key strength, so that the traffic gets a level of protection appropriate to its importance or sensitivity as described in section 8.1. The exact syntax of the sensitivity information is implementation defined. Sensitivity information is needed in the model shown in [BL73]. 8.4 Additional Inbound Processing Steps for MLS Networking After an inbound packet has passed through IPsec processing, an MLS implementation SHOULD first check the packet's sensitivity (as defined by the SA (or SA bundle) used for the packet) with the interface or address/prefix as described in section 8.2 before delivering the datagram to an upper-layer protocol or forwarding it. The MLS system MUST retain the binding between the data received in an IPsec protected packet and the sensitivity information in the SA or SAs used for processing, so appropriate policy decisions can be made when delivering the datagram to an application or forwarding engine. The means for maintaining this binding are implementation specific. 8.5 Additional Outbound Processing Steps for MLS Networking An MLS implementation of IPsec MUST perform two additional checks besides the normal steps detailed in section 5.1.1. When consulting the SPD or the SAD to find an outbound security association, the MLS implementation MUST use the sensitivity of the data to select an appropriate outbound SA or SA bundle. The second check comes before forwarding the packet out to its destination, and is the sensitivity consistency checking described in section 8.2. Kent, Atkinson [Page 37] Internet Draft Security Architecture for IP November 1997 8.6 Additional MLS Processing for Security Gateways An MLS security gateway MUST follow the previously mentioned inbound and outbound processing rules as well as perform some additional processing specific to the intermediate protection of packets in an MLS environment. A security gateway MAY act as an outbound proxy for creating SAs for MLS systems that originate packets forwarded by the gateway. These MLS systems may explicitly label the packets to be forwarded, or the whole originating network may have sensitivity characteristics associated with it. The security gateway MUST create and use appropriate SAs for AH, ESP, or both, to protect such traffic it forwards. Similarly such a gateway SHOULD accept and process inbound AH and/or ESP packets and forward appropriately, using explicit packet labeling, or relying on the sensitivity characteristics of the destination network. 9. Performance Issues The use of IPsec imposes computational performance costs on the hosts or security gateways that implement these protocols. These costs are associated with the memory needed for IPsec code and data structures, and the computation of integrity check values, encryption and decryption, and added per-packet handling. The per-packet computational costs will be manifested by increased latency and, possibly, reduced throughout. Use of SA/key management protocols, especially ones that employ public key cryptography, also adds computational performance costs to use of IPsec. These per- association computational costs will be manifested in terms of increased latency in association establishment. For many hosts, it is anticipated that software-based cryptography will not appreciably reduce throughput, but hardware may be required for security gateways (since they represent aggregation points), and for some hosts. The use of IPsec also imposes bandwidth utilization costs on transmission, switching, and routing components of the Internet infrastructure, components not implementing IPsec. This is due to the increase in the packet size resulting from the addition of AH and/or ESP headers, AH and ESP tunneling (which adds a second IP header), and the increased packet traffic associated with key management protocols. It is anticipated that, in most instances, this increased bandwidth demand will not noticeably affect the Internet infrastructure. However, in some instances, the effects may be significant, e.g., transmission of ESP encrypted traffic over a dialup link that otherwise would have compressed the traffic. Kent, Atkinson [Page 38] Internet Draft Security Architecture for IP November 1997 Note: The initial SA establishment overhead will be felt in the first packet. This delay could impact the transport layer and application. For example, it could cause TCP to retransmit the SYN before the ISAKMP exchange is done. The effect of the delay would be different on UDP than TCP because TCP shouldn't transmit anything other than the SYN until the connection is set up whereas UDP will go ahead and transmit data beyond the first packet. Note: As discussed earlier, compression can still be employed at layers above IP. There is an IETF working group (IP Payload Compression Protocol (ippcp)) working on "protocol specifications that make it possible to perform lossless compression on individual payloads before the payload is processed by a protocol that encrypts it. These specifications will allow for compression operations to be performed prior to the encryption of a payload by IPsec protocols." 10. Conformance Requirements All IPv4 systems that claim to implement IPsec MUST comply with all requirements of the Security Architecture document. All IPv6 systems MUST comply with all requirements of the Security Architecture document. 11. Security Considerations The focus of this document is security; hence security considerations permeate this specification. 12. Differences from RFC 1825 This architecture document differs substantially from RFC 1825 in detail and in organization, but the fundamental notions are unchanged. This document provides considerable additional detail in terms of compliance specifications. It introduces the SPD and SAD, and the notion of SA selectors. It is aligned with the new versions of AH and ESP, which also differ from their predecessors. Specific requirements for supported combinations of AH and ESP are newly added, as are details of PMTU management. Acknowledgements Many of the concepts embodied in this specification were derived from or influenced by the US Government's SP3 security protocol, ISO/IEC's NLSP, the proposed swIPe security protocol [SDNS, ISO, IB93, IBK93], and the work done for SNMP Security and SNMPv2 Security. Kent, Atkinson [Page 39] Internet Draft Security Architecture for IP November 1997 For over 2 years (although it sometimes seems *much* longer) , this document has evolved through multiple versions and iterations. During this time, many people have contributed significant ideas and energy to the process and the documents themselves. The authors would like to thank Karen Seo for providing extensive help in the review, editing, background research, and coordination for this version of the specification. The authors would also like to thank the members of the IPsec and IPng working groups, with special mention of the efforts of (in alphabetic order): Steve Bellovin, Steve Deering, James Hughes, Phil Karn, Frank Kastenholz, Perry Metzger, David Mihelcic, Hilarie Orman, Norman Shulman, William Simpson, Harry Varnis, and Nina Yuan. Kent, Atkinson [Page 40] Internet Draft Security Architecture for IP November 1997 Appendix A -- Glossary This section provides definitions for several key terms that are employed in this document. Other documents provide additional definitions and background information relevant to this technology, e.g., [VK83, HA94]. Included in this glossary are generic security service and security mechanism terms, plus IPsec-specific terms. Access Control Access control is a security service that prevents unauthorized use of a resource, including the prevention of use of a resource in an unauthorized manner. In the IPsec context, the resource to which access is being controlled is often: o for a host, computing cycles or data o for a security gateway, a network behind the gateway or bandwidth on that network. Anti-replay [See "Integrity" below] Authentication This term is used informally to refer to the combination of two nominally distinct security services, data origin authentication and connectionless integrity. See the definitions below for each of these services. Availability Availability, when viewed as a security service, addresses the security concerns engendered by attacks against networks that deny or degrade service. For example, in the IPsec context, the use of anti-replay mechanisms in AH and ESP support availability. Confidentiality Confidentiality is the security service that protects data from unauthorized disclosure. The primary confidentiality concern in most instances is unauthorized disclosure of application level data, but disclosure of the external characteristics of communication also can be a concern in some circumstances. Traffic flow confidentiality is the service that addresses this latter concern by concealing source and destination addresses, message length, or frequency of communication. In the IPsec context, using ESP in tunnel mode, especially at a security gateway, can provide some level of traffic flow confidentiality. (See also traffic analysis, below.) Kent, Atkinson [Page 41] Internet Draft Security Architecture for IP November 1997 Encryption Encryption is a security mechanism used to transform data from an intelligible form (plaintext) into an unintelligible form (ciphertext), to provide confidentiality. The inverse transformation process is designated "decryption". Oftimes the term "encryption" is used to generically refer to both processes. Data Origin Authentication Data origin authentication is a security service that verifies the identity of the claimed source of data. This service is usually bundled with connectionless integrity service. Integrity Integrity is a security service that ensures that modifications to data are detectable. Integrity comes in various flavors to match application requirements. IPsec supports two forms of integrity: connectionless and a form of partial sequence integrity. Connectionless integrity is a service that detects modification of an individual IP datagram, without regard to the ordering of the datagram in a stream of traffic. The form of partial sequence integrity offered in IPsec is referred to as anti-replay integrity, and it detects arrival of duplicate IP datagrams (within a constrained window). This is in contrast to connection-oriented integrity, which imposes more stringent sequencing requirements on traffic, e.g., to be able to detect lost or re-ordered messages. Although authentication and integrity services often are cited separately, in practice they are intimately connected and almost always offered in tandem. Security Association (SA) A simplex (uni-directional) logical connection, created for security purposes. All traffic traversing an SA is provided the same security processing. In IPsec, an SA is an internet layer abstraction implemented through the use of AH or ESP. Security Gateway A security gateway is an intermediate system that acts as the communications interface between two networks. The set of hosts (and networks) on the external side of the security gateway is viewed as untrusted (or less trusted), while the networks and hosts and on the internal side are viewed as trusted (or more trusted). The internal subnets and hosts served by a security gateway are presumed to be trusted by virtue of sharing a common, local, security administration. (See "Trusted Subnetwork" below.) In the IPsec context, a security gateway is a point at which AH and/or ESP is implemented in order to serve a set of internal hosts, providing security services for these hosts when they communicate with external hosts also employing IPsec (either Kent, Atkinson [Page 42] Internet Draft Security Architecture for IP November 1997 directly or via another security gateway). SPI Acronym for "Security Parameters Index". The combination of a destination address, a security protocol, and an SPI uniquely identifies a security association (SA, see above). The SPI is carried in AH and ESP protocols to enable the receiving system to select the SA under which a received packet will be processed. An SPI has only local significance, as defined by the creator of the SA (usually the receiver of the packet carrying the SPI); thus an SPI is generally viewed as an opaque bit string. However, the creator of an SA may choose to interpret the bits in an SPI to facilitate local processing. Traffic Analysis The analysis of network traffic flow for the purpose of deducing information that is useful to an adversary. Examples of such information are frequency of transmission, the identities of the conversing parties, sizes of packets, flow identifiers, etc. [Sch94] Trusted Subnetwork A subnetwork containing hosts and routers that trust each other not to engage in active or passive attacks. There also is an assumption that the underlying communications channel (e.g., a LAN or CAN) isn't being attacked by other means. Kent, Atkinson [Page 43] Internet Draft Security Architecture for IP November 1997 Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues B.1 DF bit In cases where a system (host or gateway) adds an encapsulating header (e.g., ESP tunnel), should/must the DF bit in the original packet be copied to the encapsulating header? Fragmenting seems correct for some situations, e.g., it might be appropriate to fragment packets over a network with a very small MTU, e.g., a packet radio network, or a cellular phone hop to mobile node, rather than propagate back a very small PMTU for use over the rest of the path. In other situations, it might be appropriate to set the DF bit in order to get feedback from later routers about PMTU constraints which require fragmentation. The existence of both of these situations argues for enabling a system to decide whether or not to fragment over a particular network "link", i.e., for requiring an implementation to be able to copy the DF bit (and to process ICMP PMTU messages), but making it an option to be selected on a per interface basis. In other words, an administrator should be able to configure the router's treatment of the DF bit (set, clear, copy from encapsulated header) for each interface. Note: If a bump-in-the-stack implementation of IPsec attempts to apply different IPsec algorithms based on source/destination ports, it will be difficult to apply Path MTU adjustments. B.2 Fragmentation Fragmentation MUST be done after outbound IPsec processing. Reassembly MUST be done before inbound IPsec processing. The general reasoning is shown below (delimited by the ****'s). NOTE: IPsec always has to figure out what the encapsulating IP header fields are. This is independent of where you insert IPsec and is intrinsic to the definition of IPsec. Therefore any IPsec implementation that is not integrated into an IP implementation must include code to construct the necessary IP headers (e.g., IP2): o AH-tunnel --> IP2-AH-IP1-Transport-Data o ESP-tunnel --> IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer ********************************************************************** Overall, the fragmentation/reassembly approach described above works for all cases examined. Kent, Atkinson [Page 44] Internet Draft Security Architecture for IP November 1997 AH Xport AH Tunnel ESP Xport ESP Tunnel Implementation approach IPv4 IPv6 IPv4 IPv6 IPv4 IPv6 IPv4 IPv6 ----------------------- ---- ---- ---- ---- ---- ---- ---- ---- Hosts (integr w/ IP stack) Y Y Y Y Y Y Y Y Hosts (betw/ IP and drivers) Y Y Y Y Y Y Y Y S. Gwy (integr w/ IP stack) Y Y Y Y Outboard crypto processor * * If the crypto processor system has its own IP address, then it is covered by the security gateway case. This box receives the packet from the host and performs IPsec processing. It has to be able to handle the same AH, ESP, and related IPv4/IPv6 tunnel processing that a security gateway would have to handle. If it doesn't have it's own address, then it is similar to the bump-in-the stack implementation between IP and the network drivers. The following analysis assumes that: 1. There is only one IPsec module in a given system's stack. There isn't an IPsec module A (adding ESP/encryption and thus) hiding the transport protocol, SRC port, and DEST port from IPsec module B. 2. There are several places where IPsec could be implemented (as shown in the table above). a. Hosts with integration of IPsec into the native IP implementation. Implementer has access to the source for the stack. b. Hosts with bump-in-the-stack implementations, where IPsec is implemented between IP and the local network drivers. Source access for stack is not available; but there are well-defined interfaces that allows the IPsec code to be incorporated into the system. c. Security gateways and outboard crypto processors with integration of IPsec into the stack. 3. Not all of the above approaches are feasible in all hosts. But it was assumed that for each approach, there are some hosts for whom the approach is feasible. For each of the above 3 categories, there are IPv4 and IPv6, AH transport and tunnel modes, and ESP transport and tunnel modes -- for a total of 24 cases (3 x 2 x 4). Some header fields and interface fields are listed here for ease of reference -- they're not in the header order, but instead listed to allow comparison between the columns. (* = not covered by AH authentication. ESP authentication doesn't cover any headers that precede it.) Kent, Atkinson [Page 45] Internet Draft Security Architecture for IP November 1997 IP/Transport Interface IPv4 IPv6 (RFC 1122 -- Sec 3.4) ---- ---- ---------------------- Version = 4 Version = 6 Header Len *TOS Class,Flow Lbl TOS Packet Len Payload Len Len ID ID (optional) *Flags DF *Offset *TTL *Hop Limit TTL Protocol Next Header *Checksum Src Address Src Address Src Address Dst Address Dst Address Dst Address Options? Options? Opt ? = AH covers Option-Type and Option-Length, but might not cover Option-Data. The results for each of the 24 cases is shown below ("works" = will work if system fragments after outbound IPsec processing, reassembles before inbound IPsec processing). Notes indicate implementation issues. a. Hosts (integrated into IP stack) o AH-transport --> (IP1-AH-Transport-Data) - IPv4 -- works - IPv6 -- works o AH-tunnel --> (IP2-AH-IP1-Transport-Data) - IPv4 -- works - IPv6 -- works o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works b. Hosts (Bump-in-the-stack) -- put IPsec between IP layer and network drivers. In this case, the IPsec module would have to do something like one of the following for fragmentation and reassembly. - do the fragmentation/reassembly work itself and send/receive the packet directly to/from the network layer. In AH or ESP transport mode, this is fine. In AH or ESP tunnel mode where the tunnel is to the ultimate destination, this is fine. But in AH or ESP tunnel modes Kent, Atkinson [Page 46] Internet Draft Security Architecture for IP November 1997 where the tunnel end is different from the ultimate destination and where the source host is multi-homed, this approach could result in sub-optimal routing because the IPsec module may be unable to obtain the information needed (LAN interface and next-hop gateway) to direct the packet to the appropriate network interface. This is not a problem if the interface and next-hop gateway are the same for the ultimate destination and for the tunnel end. But if they are different, then IPsec would need to know the LAN interface and the next-hop gateway for the tunnel end. (Note: The tunnel end (security gateway) is highly likely to be on the regular path to the ultimate destination. But there could also be more than one path to the destination, e.g., the host could be at an organization with 2 firewalls. And the path being used could involve the less commonly chosen firewall.) OR - pass the IPsec'd packet back to the IP layer where an extra IP header would end up being pre-pended and the IPsec module would have to check and let IPsec'd fragments go by. OR - pass the packet contents to the IP layer in a form such that the IP layer recreates an appropriate IP header At the network layer, the IPsec module will have access to the following selectors from the packet -- SRC address, DST address, TOS, Next Protocol, and if there's a transport layer header --> SRC port and DST port. One cannot assume IPsec has access to the User ID. It is assumed that the available selector information is sufficient to figure out the relevant Security Association(s). o AH-transport --> (IP1-AH-Transport-Data) - IPv4 -- works - IPv6 -- works o AH-tunnel --> (IP2-AH-IP1-Transport-Data) - IPv4 -- works - IPv6 -- works o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works c. Security gateways -- integrate IPsec into the IP stack NOTE: The IPsec module will have access to the following Kent, Atkinson [Page 47] Internet Draft Security Architecture for IP November 1997 selectors from the packet -- SRC address, DST address, TOS/Class, Next Protocol, and if there's a transport layer header --> SRC port and DST port. It won't have access to the User ID (only Hosts have access to User ID information.) It also won't have access to the transport layer information if there is an ESP header, or if it's not the first fragment of a fragmented message. It is assumed that the available selector information is sufficient to figure out the relevant Security Association(s). o AH-tunnel --> (IP2-AH-IP1-Transport-Data) - IPv4 -- works - IPv6 -- works o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works ********************************************************************** B.3 Path MTU Discovery As mentioned earlier, "ICMP PMTU" refers to an ICMP message used for Path MTU Discovery. The legend for the diagrams below in B.3.1 and B.3.3 (but not B.3.2) is: ==== = security association (AH or ESP, transport or tunnel) ---- = connectivity (or if so labelled, administrative boundary) .... = ICMP message (hereafter referred to as ICMP PMTU) for IPv4: - Type = 3 (Destination Unreachable) - Code = 4 (Fragmentation needed and DF set) - Next-Hop MTU in the low-order 16 bits of the second word of the ICMP header (labelled unused in RFC 792), with high-order 16 bits set to zero IPv6 (RFC 1885): - Type = 2 (Packet Too Big) - Code = 0 (Fragmentation needed and DF set) - Next-Hop MTU in the 32 bit MTU field of the ICMP6 Hx = host x Rx = router x SGx = security gateway x X* = X supports IPsec Kent, Atkinson [Page 48] Internet Draft Security Architecture for IP November 1997 B.3.1 Identifying the Originating Host(s) The amount of information returned with the ICMP message is limited and this affects what selectors are available to identify security associations, originating hosts, etc. for use in further propagating the PMTU information. In brief... An ICMP message must contain the following information from the "offending" packet: - IPv4 (RFC 792) -- IP header plus a minimum of 64 bits - IPv6 (RFC 1885) -- IP header plus a minimum of 576 bytes Accordingly, in the IPv4 context, an ICMP PMTU may identify only the first (outermost) security association. This is because the ICMP PMTU may contain only 64 bits of the "offending" packet beyond the IP header, which would capture only the first SPI from AH or ESP. In the IPv6 context, an ICMP PMTU will probably provide all the SPIs and the selectors in the IP header, but maybe not the SRC/DST ports (in the transport header) or the encapsulated (TCP, UDP, etc.) protocol. Moreover, if ESP is used, the transport ports and protocol selectors may be encrypted. Looking at the diagram below of a security gateway tunnel (as mentioned elsewhere, security gateways do not use transport mode)... H1 =================== H3 \ | | / H0 -- SG1* ---- R1 ---- SG2* ---- R2 -- H5 / ^ | \ H2 |........| H4 Suppose that the security policy for SG1 is to use a single SA to SG2 for all the traffic between hosts H0, H1, and H2 and hosts H3, H4, and H5. And suppose H0 sends a data packet to H5 which causes R1 to send an ICMP PMTU message to SG1. If the PMTU message has only the SPI, SG1 will be able to look up the SA and find the list of possible hosts (H0, H1, H2, wildcard); but SG1 will have no way to figure out that H0 sent the traffic that triggered the ICMP PMTU message. Kent, Atkinson [Page 49] Internet Draft Security Architecture for IP November 1997 original after IPsec ICMP packet processing packet -------- ----------- ------ IP-3 header (S = R1, D = SG1) ICMP header (includes PMTU) IP-2 header IP-2 header (S = SG1, D = SG2) ESP header minimum of 64 bits of ESP hdr (*) IP-1 header IP-1 header TCP header TCP header TCP data TCP data ESP trailer (*) The 64 bits will include enough of the ESP (or AH) header to include the SPI. - ESP -- SPI (32 bits), Seq number (32 bits) - AH -- Next header (8 bits), Payload Len (8 bits), Reserved (16 bits), SPI (32 bits) This limitation on the amount of information returned with an ICMP message creates a problem in identifying the originating hosts for the packet (so as to know where to further propagate the ICMP PMTU information). If the ICMP message contains only 64 bits of the IPsec header (minimum for IPv4), then the IPsec selectors (e.g., Source and Destination addresses, Next Protocol, Source and Destination ports, etc.) will have been lost. But the ICMP error message will still provide SG1 with the SPI, the PMTU information and the source and destination gateways for the relevant security association. The destination security gateway and SPI uniquely define a security association which in turn defines a set of possible originating hosts. At this point, SG1 could: a. send the PMTU information to all the possible originating hosts. This would not work well if the host list is a wild card or if many/most of the hosts weren't sending to SG1; but it might work if the SPI/destination/etc mapped to just one or a small number of hosts. b. store the PMTU with the SPI/etc and wait until the next packet(s) arrive from the originating host(s) for the relevant security association. If it/they are bigger than the PMTU, drop the packet(s), and compose ICMP PMTU message(s) with the new packet(s) and the updated PMTU, and send the originating host(s) the ICMP message(s) about the problem. This involves a delay in notifying the originating host(s), but avoids the problems of (a). Since only the latter approach is feasible in all instances, a security gateway MUST provide such support, as an option. However, Kent, Atkinson [Page 50] Internet Draft Security Architecture for IP November 1997 if the ICMP message contains more information from the original packet, e.g., the 576 byte minimum for IPv6, then there MAY be enough information to immediately determine to which host to propagate the ICMP/PMTU message and to provide that system with the 5 fields (source address, destination address, source port, destination port, and transport protocol) needed to determine where to store/update the PMTU. Under such circumstances, a security gateway MUST generate an ICMP PMTU message immediately upon receipt of an ICMP PMTU from further down the path. NOTE: The Next Protocol field MAY not be contained in the 576 bytes and the use of ESP encryption MAY hide the selector fields that have been encrypted. B.3.2 Calculation of PMTU The calculation of PMTU from an ICMP PMTU has to take into account the addition of any IPsec header by H1 -- AH and/or ESP transport, or ESP or AH tunnel. Within a single host, multiple applications may share an SPI and nesting of security associations may occur. The diagram below illustrates several possible combinations of security associations between a pair of hosts (as viewed from the perspective of one of the hosts.) (ESPt or AHt = tunnel mode; ESPx or AHx = transport mode) Socket 1 ----------------------------------------------- I | n Socket 2 (ESPt/SPI-A) ------------------------------- | t | | e Socket 3 (AHx/SPI-B, ESPt/SPI-C) --- AHx (SPI-D) --- ESPt (SPI-E)--r | n Socket 4 (ESPx/SPI-F, ESPt/SPI-G) -- ESPx (SPI-H) --- e t In order to figure out the PMTU for each socket that maps to SPI-E, it will be necessary to have backpointers from SPI-E to each of the four paths that lead to it -- Socket 1, SPI-A, SPI-D, and SPI-H. B.3.3 Granularity of Maintaining PMTU Data In hosts, the granularity with which PMTU ICMP processing can be done differs depending on the implementation situation. Looking at a host, there are three situations that are of interest with respect to PMTU issues: Kent, Atkinson [Page 51] Internet Draft Security Architecture for IP November 1997 a. Integration of IPsec into the native IP implementation b. Bump-in-the-stack implementations, where IPsec is implemented "underneath" an existing implementation of a TCP/IP protocol stack, between the native IP and the local network drivers c. No IPsec implementation -- This case is included because it is relevant in cases where a security gateway is sending PMTU information back to a host. Only in case (a) can the PMTU data be maintained at the same granularity as communication associations. In the other cases, the IP layer will maintain PMTU data at the granularity of Source and Destination IP addresses (and optionally TOS/Class), as described in RFC 1191. This is an important difference, because more than one communication association may map to the same source and destination IP addresses, and each communication association may have a different amount of IPsec header overhead (e.g., due to use of different transforms or different algorithms). The examples below illustrate this. In cases (a) and (b)... Suppose you have the following situation. H1 is sending to H2 and the packet to be sent from R1 to R2 exceeds the PMTU of the network hop between them. ================================== | | H1* --- R1 ----- R2 ---- R3 ---- H2* ^ | |.......| If R1 is configured to not fragment subscriber traffic, then R1 sends an ICMP PMTU message with the appropriate PMTU to H1. H1's processing would vary with the nature of the implementation. In case (a) (native IP), the security services are bound to sockets or the equivalent. Here the IP/IPsec implementation in H1 can store/update the PMTU for the associated socket. In case (b), the IP layer in H1 can store/update the PMTU but only at the granularity of Source and Destination addresses and possibly TOS/Class, as noted above. So the result may be sub-optimal, since the PMTU for a given SRC/DST/TOS/Class will be the subtraction of the largest amount of IPsec header used for any communication association between a given source and destination. In case (c), there has to be a security gateway to have any IPsec processing. So suppose you have the following situation. H1 is sending to H2 and the packet to be sent from SG1 to R exceeds the PMTU of the network hop between them. Kent, Atkinson [Page 52] Internet Draft Security Architecture for IP November 1997 ================ | | H1 ---- SG1* --- R --- SG2* ---- H2 ^ | |.......| As described above for case (b), the IP layer in H1 can store/update the PMTU but only at the granularity of Source and Destination addresses, and possibly TOS/Class. So the result may be sub-optimal, since the PMTU for a given SRC/DST/TOS/Class will be the subtraction of the largest amount of IPsec header used for any communication association between a given source and destination. B.3.4 Per Socket Maintenance of PMTU Data Implementation of the calculation of PMTU (Section B.2.2) and support for PMTUs at the granularity of individual "communication associations" (Section B.2.3) is a local matter. However, a socket- based implementation of IPsec in a host SHOULD maintain the information on a per socket basis. Bump in the stack systems MUST pass an ICMP PMTU to the host IP implementation, after adjusting it for any IPsec header overhead added by these systems. The determination of the overhead SHOULD be determined by analysis of the SPI and any other selector information present in a returned ICMP PMTU message. B.3.5 Delivery of PMTU Data to the Transport Layer The host mechanism for getting the updated PMTU to the transport layer is unchanged, as specified in RFC 1191 (Path MTU Discovery). B.3.6 Aging of PMTU Data This topic is covered in Section 6.1.2.4. Kent, Atkinson [Page 53] Internet Draft Security Architecture for IP November 1997 Appendix C -- Sequence Space Window Code Example This appendix contains a routine that implements a bitmask check for a 32 packet window. It was provided by James Hughes (jim_hughes@stortek.com) and Harry Varnis (hgv@anubis.network.com) and is intended as an implementation example. Note that this code both checks for a replay and updates the window. Thus the algorithm, as shown, should only be called AFTER the packet has been authenticated. Implementers might wish to consider splitting the code to do the check for replays before computing the ICV. If the packet is not a replay, the code would then compute the ICV, (discard any bad packets), and if the packet is OK, update the window. #include #include typedef unsigned long u_long; enum { ReplayWindowSize = 32 }; u_long bitmap = 0; /* session state - must be 32 bits */ u_long lastSeq = 0; /* session state */ /* Returns 0 if packet disallowed, 1 if packet permitted */ int ChkReplayWindow(u_long seq); int ChkReplayWindow(u_long seq) { u_long diff; if (seq == 0) return 0; /* first == 0 or wrapped */ if (seq > lastSeq) { /* new larger sequence number */ diff = seq - lastSeq; if (diff < ReplayWindowSize) { /* In window */ bitmap <<= diff; bitmap |= 1; /* set bit for this packet */ } else bitmap = 1; /* This packet has a "way larger" */ lastSeq = seq; return 1; /* larger is good */ } diff = lastSeq - seq; if (diff >= ReplayWindowSize) return 0; /* too old or wrapped */ if (bitmap & (1 << diff)) return 0; /* this packet already seen */ bitmap |= (1 << diff); /* mark as seen */ return 1; /* out of order but good */ } char string_buffer[512]; Kent, Atkinson [Page 54] Internet Draft Security Architecture for IP November 1997 #define STRING_BUFFER_SIZE sizeof(string_buffer) int main() { int result; u_long last, current, bits; printf("Input initial state (bits in hex, last msgnum):\n"); if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) exit(0); sscanf(string_buffer, "%lx %lu", &bits, &last); if (last != 0) bits |= 1; bitmap = bits; lastSeq = last; printf("bits:%08lx last:%lu\n", bitmap, lastSeq); printf("Input value to test (current):\n"); while (1) { if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) break; sscanf(string_buffer, "%lu", ¤t); result = ChkReplayWindow(current); printf("%-3s", result ? "OK" : "BAD"); printf(" bits:%08lx last:%lu\n", bitmap, lastSeq); } return 0; } Kent, Atkinson [Page 55] Internet Draft Security Architecture for IP November 1997 Appendix D -- Categorization of ICMP messages The tables below characterize ICMP messages as being either host generated, router generated, both, unassigned/unknown. The first set are IPv4. The second set are IPv6. [Please let us know if any of these should re-categorized.] IPv4 Type Name/Codes Reference ========================================================================= HOST GENERATED: 3 Destination Unreachable 2 Protocol Unreachable [RFC792] 3 Port Unreachable [RFC792] 8 Source Host Isolated [RFC792] 14 Host Precedence Violation [RFC1812] 10 Router Selection [RFC1256] Type Name/Codes Reference ========================================================================= ROUTER GENERATED: 3 Destination Unreachable 0 Net Unreachable [RFC792] 4 Fragmentation Needed, Don't Fragment was Set [RFC792] 5 Source Route Failed [RFC792] 6 Destination Network Unknown [RFC792] 7 Destination Host Unknown [RFC792] 9 Comm. w/Dest. Net. is Administratively Prohibited [RFC792] 11 Destination Network Unreachable for Type of Service [RFC792] 5 Redirect 0 Redirect Datagram for the Network (or subnet) [RFC792] 2 Redirect Datagram for the Type of Service & Network [RFC792] 9 Router Advertisement [RFC1256] 18 Address Mask Reply [RFC950] Kent, Atkinson [Page 56] Internet Draft Security Architecture for IP November 1997 IPv4 Type Name/Codes Reference ========================================================================= BOTH ROUTER AND HOST GENERATED: 0 Echo Reply [RFC792] 3 Destination Unreachable 1 Host Unreachable [RFC792] 10 Comm. w/Dest. Host is Administratively Prohibited [RFC792] 12 Destination Host Unreachable for Type of Service [RFC792] 13 Communication Administratively Prohibited [RFC1812] 15 Precedence cutoff in effect [RFC1812] 4 Source Quench [RFC792] 5 Redirect 1 Redirect Datagram for the Host [RFC792] 3 Redirect Datagram for the Type of Service and Host [RFC792] 6 Alternate Host Address [JBP] 8 Echo [RFC792] 11 Time Exceeded [RFC792] 12 Parameter Problem [RFC792,RFC1108] 13 Timestamp [RFC792] 14 Timestamp Reply [RFC792] 15 Information Request [RFC792] 16 Information Reply [RFC792] 17 Address Mask Request [RFC950] 30 Traceroute [RFC1393] 31 Datagram Conversion Error [RFC1475] 32 Mobile Host Redirect [Johnson] 39 SKIP [Markson] 40 Photuris [Simpson] Type Name/Codes Reference ========================================================================= UNASSIGNED TYPE OR UNKNOWN GENERATOR: 1 Unassigned [JBP] 2 Unassigned [JBP] 7 Unassigned [JBP] 19 Reserved (for Security) [Solo] 20-29 Reserved (for Robustness Experiment) [ZSu] 33 IPv6 Where-Are-You [Simpson] 34 IPv6 I-Am-Here [Simpson] 35 Mobile Registration Request [Simpson] 36 Mobile Registration Reply [Simpson] 37 Domain Name Request [Simpson] 38 Domain Name Reply [Simpson] 41-255 Reserved [JBP] Kent, Atkinson [Page 57] Internet Draft Security Architecture for IP November 1997 IPv6 Type Name/Codes Reference ========================================================================= HOST GENERATED: 1 Destination Unreachable [RFC 1885] 4 Port Unreachable Type Name/Codes Reference ========================================================================= ROUTER GENERATED: 1 Destination Unreachable [RFC1885] 0 No Route to Destination 1 Comm. w/Destination is Administratively Prohibited 2 Not a Neighbor 3 Address Unreachable 2 Packet Too Big [RFC1885] 0 3 Time Exceeded [RFC1885] 0 Hop Limit Exceeded in Transit 1 Fragment reassembly time exceeded Type Name/Codes Reference ========================================================================= BOTH ROUTER AND HOST GENERATED: 4 Parameter Problem [RFC1885] 0 Erroneous Header Field Encountered 1 Unrecognized Next Header Type Encountered 2 Unrecognized IPv6 Option Encountered Kent, Atkinson [Page 58] Internet Draft Security Architecture for IP November 1997 References [BCCH94] R. Braden, D. Clark, S. Crocker, & C. Huitema, "Report of IAB Workshop on Security in the Internet Architecture", RFC-1636, DDN Network Information Center, June 1994. [Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, No. 2, March 1989. [Bel95] Steven M. Bellovin, Presentation at IP Security Working Group Meeting, Proceedings of the 32nd Internet Engineering Task Force, March 1995, Internet Engineering Task Force, Danvers, MA. [Bel96] Steven M. Bellovin, "Problem Areas for the IP Security Protocols", Proceedings of the Sixth Usenix Unix Security Symposium, July, 1996. [BL73] Bell, D.E. & LaPadula, L.J., "Secure Computer Systems: Mathematical Foundations and Model", Technical Report M74- 244, The MITRE Corporation, Bedford, MA, May 1973. [CB94] William R. Cheswick & Steven M. Bellovin, Firewalls & Internet Security, Addison-Wesley, Reading, MA, 1994. [CG96] Shu-jen Chang & Rob Glenn, "HMAC-SHA IP Authentication with Replay Prevention", Internet Draft, 1 May 1996. [DIA] US Defense Intelligence Agency, "Compartmented Mode Workstation Specification", Technical Report DDS-2600- 6243-87. [DoD85] US National Computer Security Center, "Department of Defense Trusted Computer System Evaluation Criteria", DoD 5200.28-STD, US Department of Defense, Ft. Meade, MD., December 1985. [DoD87] US National Computer Security Center, "Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria", NCSC-TG-005, Version 1, US Department of Defense, Ft. Meade, MD., 31 July 1987. [DH76] W. Diffie & M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory, Vol. IT-22, No. 6, November 1976, pp. 644-654. Kent, Atkinson [Page 59] Internet Draft Security Architecture for IP November 1997 [DH95] Steve Deering & Bob Hinden, Internet Protocol version 6 (IPv6) Specification, RFC-1883, December 1995. [EK96] D. Eastlake III & C. Kaufman, "Domain Name System Protocol Security Extensions", Internet Draft, 30 January 1996. [GM93] J. Galvin & K. McCloghrie, "Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC-1446, DDN Network Information Center, April 1993. [HA94] N. Haller & R. Atkinson, "On Internet Authentication", RFC-1704, DDN Network Information Center, October 1994. [HC97] D. Harkins & D. Carrel, "The resolution of ISAKMP with Oakley", Internet Draft, February 1997. [HM97] H. Harney, C. Muckenhirn, "Group Key Management Protocol (GKMP) Architecture", RFC 2094, July 1997. [Hugh96] J. Hughes (Editor), "Combined DES-CBC, HMAC, and Replay Prevention Security Transform", Internet Draft, June 1996. [ISO] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, International Standards Organisation, Geneva, Switzerland, 29 November 1992. [IB93] John Ioannidis and Matt Blaze, "Architecture and Implementation of Network-layer Security Under Unix", Proceedings of USENIX Security Symposium, Santa Clara, CA, October 1993. [IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network- Layer Security for IP", presentation at the Spring 1993 IETF Meeting, Columbus, Ohio [KA97a] Steve Kent, Randall Atkinson, "IP Authentication Header", Internet Draft, October 1997. [KA97b] Steve Kent, Randall Atkinson, "IP Encapsulating Security Payload (ESP)", Internet Draft, October 1997. [Ken91] Steve Kent, "US DoD Security Options for the Internet Protocol", RFC-1108, DDN Network Information Center, November 1991. [Ken93] Steve Kent, Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management, RFC-1422, DDN Network Information Center, 10 February 1993. Kent, Atkinson [Page 60] Internet Draft Security Architecture for IP November 1997 [KB93] J. Kohl & B. Neuman, The Kerberos Network Authentication Service (V5), RFC-1510, DDN Network Information Center, 10 September 1993. [MSST97] D Maughan, M. Schertler, M. Schneider, & J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP", Internet Draft, July 26, 1997. [NS78] R.M. Needham & M.D. Schroeder, "Using Encryption for Authentication in Large Networks of Computers", Communications of the ACM, Vol. 21, No. 12, December 1978, pp. 993-999. [NS81] R.M. Needham & M.D. Schroeder, "Authentication Revisited", ACM Operating Systems Review, Vol. 21, No. 1., 1981. [OG96] Mike Oehler & Rob Glenn, "HMAC-MD5 IP Authentication with Replay Prevention", Internet Draft, 1 May 1996. [Orm97] H. K. Orman, "The OAKLEY Key Determination Protocol", Internet Draft, July 25, 1997. [OTA94] US Congress, Office of Technology Assessment, "Information Security & Privacy in Network Environments", OTA-TCT-606, Government Printing Office, Washington, DC, September 1994. [Pip97] D. Piper, "The Internet IP Security Domain of Interpretation for ISAKMP", Internet Draft, October 1997. [Sch94] Bruce Schneier, Applied Cryptography, Section 8.6, John Wiley & Sons, New York, NY, 1994. [SDNS] SDNS Secure Data Network System, Security Protocol 3, SP3, Document SDN.301, Revision 1.5, 15 May 1989, published in NIST Publication NIST-IR-90-4250, February 1990. [STD-1] J. Postel, "Internet Official Protocol Standards", STD-1, March 1996. [TDG97] R. Thayer, N. Doraswamy, R. Glenn, "IP Security Document Roadmap", Internet Draft, July 1997. [VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High- level Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983. [ZDESZ93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and Zappala, D., "RSVP: A New Resource ReSerVation Protocol", Kent, Atkinson [Page 61] Internet Draft Security Architecture for IP November 1997 IEEE Network magazine, September 1993. Disclaimer The views and specification expressed in this document are those of the authors and are not necessarily those of their employers. The authors and their employers specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this design. 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 (November 1997). 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. Kent, Atkinson [Page 62] Internet Draft Security Architecture for IP November 1997 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 63] From owner-ipsec Fri Nov 14 12:31:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA06942 for ipsec-outgoing; Fri, 14 Nov 1997 12:26:26 -0500 (EST) Message-Id: <199711141651.LAA25874@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-mode-cfg-01.txt Date: Fri, 14 Nov 1997 11:51:01 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The ISAKMP Configuration Method Author(s) : R. Pereira, S. Anand Filename : draft-ietf-ipsec-isakmp-mode-cfg-01.txt Pages : 6 Date : 13-Nov-97 This document describes a new ISAKMP method that allows configuration items to be set by using both push/acknowledge and request/reply paradigms. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-isakmp-mode-cfg-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-mode-cfg-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-mode-cfg-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971113161533.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-mode-cfg-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-mode-cfg-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971113161533.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Sun Nov 16 20:31:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA07855 for ipsec-outgoing; Sun, 16 Nov 1997 20:23:26 -0500 (EST) Date: Sun, 16 Nov 1997 20:33:58 -0500 Message-Id: <199711170133.UAA25845@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: Final changes for AH/ESP documents Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk As you may know, there was some last-minute controversy over the AH/ESP results, specifically over the Sequence Number and Anti-replay Server issue, with a number of people requesting that we use option (C) instead of option (B). After discussing the issues with the document editor and the various involved parties, we've agreed to indeed use option (C). The document editors asked me to send a message to the list reflecting the final editing directions for these documents, which follow below. My personal thanks for all of the work that people have placed into editing, reviewing, and implementing these documents. - Ted 1. Sequence Number and Anti-replay Service -- 3 options have been proposed over the past several months. (B) was chosen over (A) back about 2 months ago. (B) is what's in the text at present. (B) is a perhaps bit better than (C) but both are pretty similar. It seems simplest at present to stick with (B). S = Sender AR = anti-replay R = Receiver Seq# = sequence number Sender Default To initiate AR Pro Con ------- ------------------ ----------------------- ----------------------- A) AR OFF S negotiates AR ON, - Deterministic, reli- Have to change Oakley/ R accepts/rejects able way for S & R to ISAKMP know AR status - Handles manual keying B) AR OFF R SHOULD notify S - Handles manual keying - NOTIFY is unreliable, that AR is ON - No changes to Oakley/ so S may continue to ISAKMP send while R rejects C) AR ON R MAY notify S that - No changes to Oakley/ - NOTIFY is unreliable, AR is ON or OFF ISAKMP so S may stop sending - Does not rely on when didn't need to unreliable NOTIFY to - Requires special case get S to monitor Seq# for manual keying RESOLUTION: Use option (C) and specifying a special case for manual keying (where anti-reply is off) 2. Nesting of IPsec headers -- several issues have been raised during working group last call. A) How does OAKLEY/ISAKMP support specification of the ordering of nested IPsec headers, e.g., AH + ESP vs ESP + AH? B) Should IPsec support arbitrary nesting or a limited set of ordered combinations of AH and ESP, in tunnel and transport modes? If not, - how do we propose to support the IPv6's requirement that systems accept arbitrary combinations of extension headers? - how do we propose to handle the situation of a BITW implementation adding additional IPsec headers after the host implementation (native or BITS) has added IPsec headers? - should we address arbitrary nesting in IPsecond? C) Do we need to add text clarifying how to handle nested headers by iteratively processing them -- discarding consumed headers, adjusting the mutable fields of the outer header, etc. NOTE: The following text is in the Architecture document not in the AH/ESP document. It was included as a warning to the reader in the AH/ESP draft announcement, but not in the drafts. Support for arbitrary nesting requires that implementations ensure that any mutable "AH protected" fields outside/above the AH header, i.e., IP length, IP Next Protocol and any IPsec headers, are appropriately handled by Outbound and Inbound processing as the headers are nested and unnested. To ensure interoperability, the implementation should ignore the existence (i.e., neither zero the contents nor try to predict the contents) of IPsec headers to be applied later when o constructing an IPsec header o adjusting the IP length and IP Next Protocol in the IP header or immediately preceding IP extension header This will apply to: [IP][ESP or AH][ESP or AH]...[ESP or AH] [AH][upper] Nesting involving only ESP headers should not be problematic: [IP][ESP][ESP]...[ESP][upper] D) Do we need to add text clarifying that these issues apply to multiple nested headers for a single tunnel? RESOLUTION: i. Define a small set of mandatory cases that must be supported. Starting with a packet [IP1][upper].... 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] Plus any combination of one of the above Tunnel cases followed by one the above Transport cases, i.e., 4 then 1, 4 then 2, 4 then 3, 5 then 1, 5 then 2, 5 then 3. ii. Postpone figuring out how to handle other cases (mods to Oakley/ISAKMP, clarifications for processing, etc.) to IPsecond: iii. Address (C), and (D) above as appropriate given this resolution. 3. HMAC-MD5 and HMAC-SHA --- which is mandatory, and which is strongly suggested. There is a discrepancy between the various drafts as to which the above two algorithms are mandotory, and which are "strongly suggested". A) The DOI lists 1 mandatory authentication algorithm: - HMAC with MD5 and 1 "strongly encouraged" authentication algorithm: - HMAC with SHA-1 B) The AH and ESP specs list 2 mandatory authentication algorithms: - HMAC with MD5 - HMAC with SHA-1 There was quite a bit of discussion of this on the list, with the last message coming from Hugo who stated that he felt that HMAC-SHA *was* stronger than HMAC-MD5, and that while the current (partial) attacks on MD5 do not affect HMAC-MD5, HMAC-SHA was definitely stronger, and he only felt comfortable suggesting the use of HMAC-MD5 if it was also possible to "quickly switch" to HMAC-SHA if further cryptographic advances made this advisable. Given that nearly all the vendors had implemented both in their implementations, either choice did not appear to make much real difference to implementors. RESOLUTION: That the AH and ESP specs require both HMAC-MD5 and HMAC-SHA to be required, and that the DOI be changed to also state that both algorithms are required. From owner-ipsec Sun Nov 16 20:36:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA08675 for ipsec-outgoing; Sun, 16 Nov 1997 20:36:26 -0500 (EST) Date: Sun, 16 Nov 1997 20:35:14 -0500 Message-Id: <199711170135.UAA25850@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: WG Last Call Results Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk We have reviewed the last call process and here is where we are: draft-ietf-ipsec-arch-sec-01.txt Open Items draft-ietf-ipsec-arch-sec-02.txt TBP (to be published and reviewed) draft-ietf-ipsec-isakmp-08.txt DONE draft-ietf-ipsec-oakley-02.txt DONE draft-ietf-ipsec-isakmp-oakley-05.txt Open Items draft-ietf-ipsec-isakmp-oakley-06.txt TBP/D (to be published and DONE) draft-ietf-ipsec-ipsec-doi-06.txt DONE draft-ietf-ipsec-doc-roadmap-01.txt DONE draft-ietf-ipsec-esp-v2-01.txt Open Items draft-ietf-ipsec-esp-v2-02.txt TBP/D (to be published and DONE) draft-ietf-ipsec-auth-header-02.txt Open Items draft-ietf-ipsec-auth-header-03.txt TBP/D (to be published and DONE) draft-ietf-ipsec-auth-hmac-md5-96-01.txt DONE draft-ietf-ipsec-auth-hmac-sha196-01.txt DONE draft-ietf-ipsec-ciph-des-expiv-00.txt DONE Unfortunately changes on the last few documents have dragged on. Look carefully on Karen's comments and be ready with any last editorial changes. Document deadline is 11/21. We need to have all of these documents flagged as done by 11/21! Robert Moskowitz Chrysler Corporation (810) 758-8212 Theodore Ts'o MIT (617) 253-8091 From owner-ipsec Mon Nov 17 08:19:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA26225 for ipsec-outgoing; Mon, 17 Nov 1997 08:14:26 -0500 (EST) Message-Id: <3.0.3.32.19971117082425.0094d680@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 17 Nov 1997 08:24:25 -0500 To: ipsec@tis.com From: Robert Moskowitz Subject: cipher-cbc-00.txt last call Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk draft-ietf-ipsec-cipher-cbc-00.txt is now in last call as an Informational RFC. The author reports that he has not received any changes, only positive comments concerning it. We wish to get this ID moving forward immediately behind the core documents, as many vendors wish to have an RFC to refer to for other transforms. This ID replaces the following drafts: draft-ietf-ipsec-ciph-3des-expiv-00.txt draft-ietf-ipsec-ciph-rc5-cbc-00.txt draft-ietf-ipsec-ciph-cast128-cbc-00.txt draft-ietf-ipsec-ciph-blowfish-cbc-00.txt draft-ietf-ipsec-ciph-idea-cbc-00.txt The following drafts are not covered by this ID, and are still under wg consideration. draft-ietf-ipsec-ciph-des-xex-00.txt draft-ietf-ipsec-ciph-arcfour-00.txt Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Mon Nov 17 10:57:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA04405 for ipsec-outgoing; Mon, 17 Nov 1997 10:55:30 -0500 (EST) Message-Id: <199711171605.LAA15981@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-arch-sec-02.txt Date: Mon, 17 Nov 1997 11:05:17 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Security Architecture for the Internet Protocol Author(s) : R. Atkinson Filename : draft-ietf-ipsec-arch-sec-02.txt Pages : 63 Date : 14-Nov-97 This memo specifies the base architecture for IPsec compliant systems. The goal of the architecture is to provide various security services for traffic at the IP layer, in both the IPv4 and IPv6 environments. This document describes the goals of such systems, their components and how they fit together with each other and into the IP environment. It also describes the security services offered by the IPsec protocols, and how these services can be employed in the IP environment. This document does not address all aspects of IPsec architecture. Subsequent documents will address additional architectural details of a more advanced nature, e.g., use of IPsec in NAT environments and more complete support for IP multicast. The following fundamental components of the IPsec security architecture are discussed in terms of their underlying, required functionality. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-arch-sec-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-arch-sec-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-arch-sec-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: <19971114181839.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-arch-sec-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-arch-sec-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971114181839.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Nov 17 13:57:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA15918 for ipsec-outgoing; Mon, 17 Nov 1997 13:53:36 -0500 (EST) Message-Id: <3.0.3.32.19971117135656.00bbc8c0@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 17 Nov 1997 13:56:56 -0500 To: Internet-Drafts@ietf.org From: Robert Moskowitz Subject: Re: I-D ACTION:draft-ietf-ipsec-arch-sec-02.txt Cc: ipsec@tis.com In-Reply-To: <199711171605.LAA15981@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 11:05 AM 11/17/97 -0500, Internet-Drafts@ietf.org wrote: >A Revised Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the IP Security Protocol Working Group of the IETF. > > Title : Security Architecture for the Internet Protocol > Author(s) : R. Atkinson Please re-issue this announcement, adding Steve Kent as an Author. > Filename : draft-ietf-ipsec-arch-sec-02.txt > Pages : 63 > Date : 14-Nov-97 > > This memo specifies the base architecture for IPsec compliant > systems. The goal of the architecture is to provide various security > services for traffic at the IP layer, in both the IPv4 and IPv6 > environments. This document describes the goals of such systems, > their components and how they fit together with each other and into > the IP environment. It also describes the security services offered > by the IPsec protocols, and how these services can be employed in the > IP environment. This document does not address all aspects of IPsec > architecture. Subsequent documents will address additional > architectural details of a more advanced nature, e.g., use of IPsec > in NAT environments and more complete support for IP multicast. The > following fundamental components of the IPsec security architecture > are discussed in terms of their underlying, required functionality. > > >Internet-Drafts are available by anonymous FTP. Login wih the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-ipsec-arch-sec-02.txt". >A URL for the Internet-Draft is: >ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-arch-sec-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-arch-sec-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. >Content-Type: text/plain >Content-ID: <19971114181839.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-ipsec-arch-sec-02.txt > > Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Tue Nov 18 09:36:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA25166 for ipsec-outgoing; Tue, 18 Nov 1997 09:25:43 -0500 (EST) Message-Id: <199711181436.JAA06002@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ipsec-doi-06.txt Date: Tue, 18 Nov 1997 09:36: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 IP Security Domain of Interpretation for ISAKMP Author(s) : D. Piper Filename : draft-ietf-ipsec-ipsec-doi-06.txt Pages : 26 Date : 17-Nov-97 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-06.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ipsec-doi-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-ipsec-doi-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: <19971117160837.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ipsec-doi-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ipsec-doi-06.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971117160837.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Nov 18 09:36:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA25268 for ipsec-outgoing; Tue, 18 Nov 1997 09:34:44 -0500 (EST) From: Vach Kompella To: , , , , Subject: Auto filter rule generation for Phase 2 tunnels Message-ID: <5040200007929916000002L062*@MHS> Date: Tue, 18 Nov 1997 09:55:12 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk >From what I understand, the typical implementation of Phase 2 tunnels involves creating filter rules that describe the P2 tunnels. While this is not necessary, the use of the filter rules makes it easy to quickly associate a packet with a tunnel using well-established techniques. Here is my question. Suppose a tunnel T1 is set up from subnet A inside one organization, through Firewall A, through the Internet, through Firewall B of another organization, to subnet B inside the second organization. Say this tunnel is from host A1 on subnet A to host B1 on subnet B. A filter rule can be set up for this tunnel, to admit packets from A1 to B1, via the tunnel T1. Now, suppose a second tunnel T2 is set up between these two subnets, admitting packets from *Subnet A* to *Subnet B*. Say T2 has different Security Parameters. Now what does the filter rule table look like? If you did this right, in this simple case, you'd like to keep Rule 1 before Rule 2. But you can see where this goes. The filter rules have at least two-tuples (src IP addr, dest IP addr), or more generally, ([src IP addr, netmask], [dest IP addr, netmask]). There isn't an obvious total ordering, since src netmasks have one ordering which may not match the destination netmask ordering. Now we could have a policy that says the filter rules stay in the order in which they were created, or we always sort only on the [destination IP addr, netmask], or whatever. However, if we don't have something that is common to all implementations, then A could set up 2 tunnels with B, and when they want to use the tunnels, it is possible that packets from tunnel 1 will match filter rule 2, and get associated with tunnel 2. Then the Security parameters would not match, and packets can get discarded, which will probably lead to much dissatisfaction all around. Of course, we don't really need filter rules. We can parse each packet on an individual basis, and match all the parameters (including Security Parameters) in the packet with a tunnel. In effect, you use the filter rule, find a match, get the Security Parameters of the associated tunnel, see if the Security Parameters match, and call it a filter rule mismatch if they don't. Then you go on to the next rule. This won't work with two tunnels that have the same Security Parameters, though, unless you proceed to the next level of authentication, and see if the authentication fails, call it a rule mismatch. That's going to be very expensive! You could have two tunnels with the same Security Parameters if the subnets they protect are not mergeable. E.g., if one tunnel is host to host, and the other is subnet to subnet, then they are mergeable. If one tunnel is from a subnet 4 bits wide to a subnet 8 bits wide, and the other from a subnet 5 bits wide to a subnet 7 bits wide, then by merging into one rule that is from subnet 5 bits wide to subnet 8 bits wide, we allow more hosts to use the tunnels than were originally allowed. Vach Kompella IBM Corp. Network Security Product Development kompella@us.ibm.com Ph.: (919) 254-7281 Fax: (919) 254-4239 From owner-ipsec Tue Nov 18 09:59:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA25490 for ipsec-outgoing; Tue, 18 Nov 1997 09:58:48 -0500 (EST) Message-Id: <199711181508.KAA07186@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-oakley-05.txt Date: Tue, 18 Nov 1997 10:08:58 -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 resolution of ISAKMP with Oakley Author(s) : D. Carrel, D. Harkins Filename : draft-ietf-ipsec-isakmp-oakley-05.txt Pages : 38 Date : 17-Nov-97 [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-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-oakley-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-ipsec-isakmp-oakley-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: <19971117180015.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-oakley-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-oakley-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971117180015.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Nov 18 10:31:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA25763 for ipsec-outgoing; Tue, 18 Nov 1997 10:30:48 -0500 (EST) Message-Id: <199711181541.KAA08138@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-arch-sec-02.txt Date: Tue, 18 Nov 1997 10:41:04 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart Note: This announcement is being re-sent with a correction made. A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Security Architecture for the Internet Protocol Author(s) : S. Kent, R. Atkinson Filename : draft-ietf-ipsec-arch-sec-02.txt Pages : 63 Date : 14-Nov-97 This memo specifies the base architecture for IPsec compliant systems. The goal of the architecture is to provide various security services for traffic at the IP layer, in both the IPv4 and IPv6 environments. This document describes the goals of such systems, their components and how they fit together with each other and into the IP environment. It also describes the security services offered by the IPsec protocols, and how these services can be employed in the IP environment. This document does not address all aspects of IPsec architecture. Subsequent documents will address additional architectural details of a more advanced nature, e.g., use of IPsec in NAT environments and more complete support for IP multicast. The following fundamental components of the IPsec security architecture are discussed in terms of their underlying, required functionality. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-arch-sec-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-arch-sec-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-arch-sec-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: <19971114181839.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-arch-sec-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-arch-sec-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971114181839.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Nov 18 10:34:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA25804 for ipsec-outgoing; Tue, 18 Nov 1997 10:33:47 -0500 (EST) Message-Id: <199711181538.KAA02672@morden.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: Auto filter rule generation for Phase 2 tunnels In-reply-to: Your message of "Tue, 18 Nov 1997 09:55:12 EST." <5040200007929916000002L062*@MHS> Date: Tue, 18 Nov 1997 10:38:45 -0500 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I don't know what a "Phase 2" tunnel is, but I think I understand your description. A diagram would help me a lot. Maybe I can counter with what I think is a similar example? I asked a couple of people some questions about the following scenario during the ANX interop, and got some interesting answers. net 1.2/16 ************ net 2.3.4/24 \ / R---Gw1======Gw2----R / \ net 1.2.3/24 ********** net 2.3/16 [ - unprotected physical link. = protected physical link. * logical (protected) link/tunnel. Assume two tunnels between Gw1 and Gw2: 1. 1.2/16 <-> 2.3.4/24 with parameter set 1 (e.g. 3DES+SHA1-96) 2. 1.2.3/24 <-> 2.3/16 with parameter set 2 (e.g. RC4-40+MD5-96) Assume data flow between 1.2.3.1 and 2.3.4.4. If one sorts the filters by "source" prefix length, then packets flow with parameters set 2 in the -> direction, and parameter set 1 in the <- direction. If one sorts the filters by "destination" prefix length, the packets flow with parameters set 1 in the -> direction, and parameter set 2 in the <- direction. The other alternative is not to sort, so it winds up as some function of what order the rules were loaded. A final sort is to sort by strength of algorithm first, and source/destination later. That may result in non-optimal usage if the user really wanted to use a faster, weaker algorithm in some cases. The correct answer is that this situation is ambiguous. The correct solution is to recognize the ambiguity in the UI and do: 3. 1.2.3/24 <-> 2.3.4/24 with parameter set 3 ] Where's the sun? Oh there you are. Aren't you late today? | one quark [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON | two quark [ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | red q blue q[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNHG2fsmxxiPyUBAxAQErpwMAiXIDQ6NfS4NsvNWK+S5OwuR+8lQTD2bu QzMXwCN2+kX0uVwvbyqFpPAOLxDn3vVlE7O9ao4VQ1detZ1ndrUZRlbVfe7SQ3FB xWLiMRb054Qt8avXB6zIcusxktsBxCWZ =pkxH -----END PGP SIGNATURE----- From owner-ipsec Tue Nov 18 11:51:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA26220 for ipsec-outgoing; Tue, 18 Nov 1997 11:48:46 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <5040200007929916000002L062*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Nov 1997 11:58:51 -0500 To: Vach Kompella From: Stephen Kent Subject: Re: Auto filter rule generation for Phase 2 tunnels Cc: Sender: owner-ipsec@ex.tis.com Precedence: bulk Vach, This question si addressed in the IPsec security architectrure document, a revised verison of which has just been posted as an I-D. The solution proposed there (as in the prevuious version distributed on 7/30/97) is that the set of security policy rules (filters) MUST be ordered. As you note, there is no obvious canonical ordering, especially when one adds the other selector types defined in the architecture document. It is important that both ends know what traffic is being matched to which rules, since there is also a desire to check the source address(and maybe other selector info) upon receipt, to prevent spoofing after SA establishment. Steve From owner-ipsec Tue Nov 18 16:21:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA28169 for ipsec-outgoing; Tue, 18 Nov 1997 16:18:49 -0500 (EST) Message-Id: <3.0.3.32.19971118162816.009361b0@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 18 Nov 1997 16:28:16 -0500 To: ipsec@tis.com From: Robert Moskowitz Subject: draft-ietf-ipsec-arch-sec-02.txt and last call In-Reply-To: <199711181541.KAA08138@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I really hate last minute things, but I need to point out to all of you that we only have until the 21st 5pm to get anymore drafts in. This does not give Karen and Steve much time, or all of us for that matter. So PLEASE read the draft tonight! Look at it carefully and get your comments off to Karen. We will see what we can do to incorporate any REASONABLE corrections. If there are any burning issues, email me directly. Ted has to dash out of the country for a few days, so I am holding the bag for the rest of the week, so to speak. It would be real significant if we can go to DC with all of these documents having completed last call and ready to submit as RFCs. Then we can start collecting the next round of work items; sigh. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Tue Nov 18 17:51:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA28596 for ipsec-outgoing; Tue, 18 Nov 1997 17:49:49 -0500 (EST) From: "Alexei V. Vopilov" To: "Vach Kompella" , Subject: Re: Auto filter rule generation for Phase 2 tunnels Date: Wed, 19 Nov 1997 01:58:39 +0300 Message-ID: <01bcf475$82752ec0$e2253ac3@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 RAA28593 Sender: owner-ipsec@ex.tis.com Precedence: bulk Vach, look at the comments inserted into original message. -----Original Message----- From: Vach Kompella To: danmcd@Eng.Sun.Com ; rpereira@TimeStep.com ; naganand@BayNetworks.COM ; rob.glenn@nist.gov ; ipsec@tis.com Date: 18 ÎÏÑÂÒÑ 1997 Ç. 20:27 Subject: Auto filter rule generation for Phase 2 tunnels [deleted stuff ...] :Suppose a tunnel T1 is set up from subnet A inside one organization, through :Firewall A, through the Internet, through Firewall B of another organization, :to subnet B inside the second organization. Say this tunnel is from host A1 on :subnet A to host B1 on subnet B. A filter rule can be set up for this tunnel, :to admit packets from A1 to B1, via the tunnel T1. Now, suppose a second :tunnel T2 is set up between these two subnets, admitting packets from *Subnet :A* to *Subnet B*. Say T2 has different Security Parameters. Now what does the :filter rule table look like? If you did this right, in this simple case, you'd :like to keep Rule 1 before Rule 2. ^^^^^^^^^^^^^^^ After a tunnel has been set up, the incoming packets (to the end-point of tunnel) get associated with that tunnel based on SPI + tunnel address values found in ESP/AH headers. After stripping out ESP/AH headers you have all information to check the packet parameters against the policy applied for particular SA. For a packet possibly entering a tunnel there is no SPI value available from the packet itself, since it is not yet converted into IPsec format. But, once you have taken the right decision to map the first packet of a network connection to particular SA, consequent traffic can be filtered much easier. Just apply hash function over packet headers' fields and get the index into SAs database. : :But you can see where this goes. The filter rules have at least two-tuples :(src IP addr, dest IP addr), or more generally, ([src IP addr, netmask], [dest :IP addr, netmask]). There isn't an obvious total ordering, since src netmasks :have one ordering which may not match the destination netmask ordering. ^^^^^^^^^^^^^^ Consider ports-range as part of a high-level rule to make your life even more difficult ;-) : :Now we could have a policy that says the filter rules stay in the order in :which they were created, or we always sort only on the [destination IP addr, :netmask], or whatever. However, if we don't have something that is common to :all implementations, then A could set up 2 tunnels with B, and when they want :to use the tunnels, it is possible that packets from tunnel 1 will match filter :rule 2, and get associated with tunnel 2. Then the Security parameters would :not match, and packets can get discarded, which will probably lead to much :dissatisfaction all around. ^^^^^^^^^^^^ To solve _this_ problem you should tune you implementaion to employ variable netmasks when discriminating security policy against source/destination IP addresses from the network packet. It means you should look even on a stand-alone address as on subnet 0 bits wide. Your target is to find the least enclosing registered subnet for IP address being checked. Thus you will find the _object_ an IP address belongs to. I can provide with number of algorithms to do that. In turn, any brand IP routing software also does this job. :Of course, we don't really need filter rules. We can parse each packet on an :individual basis, and match all the parameters (including Security Parameters) :in the packet with a tunnel. In effect, you use the filter rule, find a match, :get the Security Parameters of the associated tunnel, see if the Security :Parameters match, and call it a filter rule mismatch if they don't. Then you :go on to the next rule. ^^^^^^^^^^^^^ For IPsec formatted ( read incoming) packet, if you have found that SPI matches to the one from a 'rule', but security parameters do not - drop the packet. For a plain IP (read outgoing) packet you have nothing of security parameters in the packet itself to perform _your_ checking! : :This won't work with two tunnels that have the same Security Parameters, :though, unless you proceed to the next level of authentication, and see if the :authentication fails, call it a rule mismatch. That's going to be very :expensive! You could have two tunnels with the same Security Parameters ^^^^^^^^^^^ Do you mean 'the same SPIs' here? - if yes, it gonna be the same tunnel! :if the subnets they protect are not mergeable. E.g., if one tunnel is host to host, :and the other is subnet to subnet, then they are mergeable. If one tunnel is :from a subnet 4 bits wide to a subnet 8 bits wide, and the other from a subnet :5 bits wide to a subnet 7 bits wide, then by merging into one rule that is from :subnet 5 bits wide to subnet 8 bits wide, we allow more hosts to use the :tunnels than were originally allowed. ^^^^^^^^^^^ As Michael Richardson wrote there should be a way to distinguish traffic of 4 bits <-> 7 bits wide subnets from both registered tunnels! Well, this is interesting problem. Probably the following would work: 1. Since a tunnel is negotiated _before_ the using both parties become aware of subnets on it ends. In your case, the following subnets are registered to start play: 4,5 on the one end and 8,7 on the other. 2. Assume, two tunnels (SAs) has been registered, namely 4-8 and 5-7 3. Now, if a packet is going from 4 to 7 it must be discarded at the tunnel start until corresponded SA (4-7) will be explicitly negotiated. The explanation follows. 4. By using discriminating search an implementation at the tunnel start might find the rule 4-8 as seemingly matching to correct parameters for a packet from 4 to 7. However, since the remote player 7 is known as a separate entity and it's subnet has not been registered to play with 4 the packet must be discarded. The rule 5-7 will fail for 4-7 tunnel because 4 does not even fit in 5. Summarizing above list an implmentation should work with network objects rather than with addresses and the thesis would be: "The players must be known before a game starts!" The proposed scheme will work while all assigned subnets are known to policy checking engine. Suppose, again in your case, the 5-7 tunnel is just deleted along with information about subnets 5 and 7. Then traffic 5-7 will be covered by the remaining rule for 4-8 tunnel that might be not good for you... sometime, right? : :Vach Kompella :IBM Corp. :Network Security Product Development :kompella@us.ibm.com :Ph.: (919) 254-7281 :Fax: (919) 254-4239 Hope this help. --- Alexei V. Vopilov (alx@elnet.msk.ru), +7(095)5367694 Software Architecture&Development Consultant. --- From owner-ipsec Wed Nov 19 03:45:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA01453 for ipsec-outgoing; Wed, 19 Nov 1997 03:42:52 -0500 (EST) Message-Id: <2.2.32.19971119085138.006c41a4@pita.cisco.com> X-Sender: shacham@pita.cisco.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Nov 1997 10:51:38 +0200 To: ipsec@tis.com From: Avram Shacham Subject: modifications in draft-ietf-ippcp-protocol-02.txt Sender: owner-ipsec@ex.tis.com Precedence: bulk Following the recent IPPCP WG mailing-list discussions, I modified the IP Payload Compression Protocol document to include the requested clarifications. The new document is titled . A summary of the changes is attached. Please, e-mail me directly requests for the full text of the document. The plan is to submit the new draft prior to the 11-21 deadline. Looking forward to your prompt comments, avram Summary of the changes from : a) 2.1. Compressed Payload Paragraph 4 - The compression algorithm is responsible to provide a compressed payload in whole octet units. Paragraph 5 - Refering to "The original content of the Next Header (IPv6) or protocol (IPv4) field...", instead of using only "Next Header field". b) 2.2. Anti-Expansion Policy Paragraph 4 - The compressibility test is "algorithm dependent", a phrase more accurate than "implementation dependent." c) 3.1. IPv4 Header Modifications Explicit reference to Header Checksum. d) 3.3. IPComp Header Structure Clarifications of CPI characteristics and usage: Compression Parameter Index (CPI) 16-bit index. The CPI is stored in network order. The values 0-63 are defined by IANA and are used for manual setup, which requires no additional information. The values 64-61439 are negotiated between the two nodes in definition of an IPComp Association, as defined in section 4. The values 61440-65535 are for private use among mutually consenting parties. Both nodes participating can select a CPI value independently of each other and there is no relationships between the two separately chosen CPIs. The outbound IPComp header MUST use the CPI value chosen by the decompressing node. The CPI in combination with the destination IP address uniquely identifies the compression algorithm characteristics for the datagram. e) 5. Security Considerations Paragraph 1 - Modified "...transport header fields..." to "...transport layer header fields..." f) Several typos were corrected. === end of summary === From owner-ipsec Wed Nov 19 06:36:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA02401 for ipsec-outgoing; Wed, 19 Nov 1997 06:34:53 -0500 (EST) Message-Id: <199711191146.GAA04599@morden.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: Auto filter rule generation for Phase 2 tunnels In-reply-to: Your message of "Tue, 18 Nov 1997 11:58:51 EST." Date: Wed, 19 Nov 1997 06:46:04 -0500 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Stephen" == Stephen Kent writes: Stephen> just been posted as an I-D. The solution proposed there Stephen> (as in the prevuious version distributed on 7/30/97) is Stephen> that the set of security policy rules (filters) MUST be Stephen> ordered. As you note, there is no obvious canonical Stephen> ordering, especially when one adds the other selector Stephen> types defined in the architecture document. It is I just read that section last night again. Is there any point in talking about an ordering if there is no canonical order? In general, I feel that the architecture document has gone beyond being a functional specification and gone into being a design specificiation. I've been told by some that this is a trend in IETF standards, and isn't something I should worry about. I am pleased in general, with the document, and particularly the ICMP sections. ] ON HUMILITY: to err is human. To moo, bovine. | SSH IPsec [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |international[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNHLRdcmxxiPyUBAxAQFT0QL9FibZcVi7zS2IfgdKPmwDTggLIUBfciX4 KqUGtivpeJXhtgMWf+bHrGNKEalzK8RIrvi4/mmTAnq0FXBvtC5da5cLG3aG4EEe D/E6kPtCOhRLmq6ndVY6W3aaaadTMIV5 =UhJ9 -----END PGP SIGNATURE----- From owner-ipsec Wed Nov 19 07:32:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA02745 for ipsec-outgoing; Wed, 19 Nov 1997 07:31:52 -0500 (EST) Date: Tue, 18 Nov 1997 16:27:08 -0800 From: Mohan.Parthasarathy@Eng.Sun.Com (Mohan Parthasarathy) Message-Id: <199711190027.QAA01295@ahiri.eng.sun.com> To: ipsec@tis.com Subject: Re: I-D ACTION:draft-ietf-ipsec-arch-sec-02.txt Cc: kent@bbn.com, rgm3@chrysler.com X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk I have a clarification to make regarding the ICMP PMTU calcualtion. I want to make sure that my understanding is right regarding this though it could be just some implementation details. In section 6.1.2.2 and section B.3.2, there is some discussion regarding PMTU calculation. >The calculation of PMTU from an ICMP PMTU has to take into account >the addition of any IPsec header by H1 -- AH and/or ESP transport, or >ESP or AH tunnel. Is this true in general or it discusses the specific case of security gateway example ? I understand that in the case of Security Gateway reporting the PMTU to the host, it should account for the additional IPSEC header that it would insert for that host. In the case of end-to-end host implementing IPSEC (integrated with IP) the host receiving the PMTU need not adjust for the IPSEC header and report the PMTU directly to the upper layers. Before even the datagram goes out, the MTU stored at the socket level should take care of the extra IPSEC headers. Is this right ? The document discusses the issues of authenticated and unauthenticated ICMP messages. But the IP datagram that is being returned (attached to the ICMP message) may not be the real one. Somebody can fake this one. Should this be mentioned somewhere so that the implementor can think of someway to handle this e.g logging the message etc.? -mohan From owner-ipsec Wed Nov 19 07:39:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA02821 for ipsec-outgoing; Wed, 19 Nov 1997 07:38:52 -0500 (EST) Message-ID: <3472BB62.C6A0C6F8@kk.ericsson.se> Date: Wed, 19 Nov 1997 11:11:46 +0100 From: ETX-DN-SL Christian Gehrmann Organization: Ericsson Telecom X-Mailer: Mozilla 4.03 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Ip-sec working group Subject: VPN:s Content-Type: multipart/mixed; boundary="------------BEC0C0D21FB529574F0D2493" Sender: owner-ipsec@ex.tis.com Precedence: bulk This is a multi-part message in MIME format. --------------BEC0C0D21FB529574F0D2493 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit What is the current status of VPN and IP-sec? The document gives more unsolved problems than solved ones? /C. Gehrmann --------------BEC0C0D21FB529574F0D2493 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Christian Gehrmann Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Christian Gehrmann n: Gehrmann;Christian org: Ericsson Telecom AB adr: Dialoggatan 1;;Kungens Kurva;Stockholm;;S-126 25 ;Sweden email;internet: etxcgeh@kk.ericsson.se title: Ph.D. tel;work: +46-8-71 95032 tel;fax: +46-8-71 96677 tel;home: +46-8-182971 x-mozilla-cpt: ;0 x-mozilla-html: TRUE version: 2.1 end: vcard --------------BEC0C0D21FB529574F0D2493-- From owner-ipsec Wed Nov 19 07:59:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA02985 for ipsec-outgoing; Wed, 19 Nov 1997 07:58:52 -0500 (EST) Message-Id: <199711191307.IAA04872@morden.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: I-D ACTION:draft-ietf-ipsec-arch-sec-02.txt In-reply-to: Your message of "Tue, 18 Nov 1997 16:27:08 PST." <199711190027.QAA01295@ahiri.eng.sun.com> Date: Wed, 19 Nov 1997 15:07:05 +0200 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Mohan" == Mohan Parthasarathy writes: Mohan> I have a clarification to make regarding the ICMP PMTU Mohan> calcualtion. I want to make sure that my understanding is Mohan> right regarding this though it could be just some Mohan> implementation details. Mohan> In section 6.1.2.2 and section B.3.2, there is some Mohan> discussion regarding PMTU calculation. >> The calculation of PMTU from an ICMP PMTU has to take into >> account the addition of any IPsec header by H1 -- AH and/or ESP >> transport, or ESP or AH tunnel. Mohan> Is this true in general or it discusses the specific case Mohan> of security gateway example ? Mohan> I understand that in the case of Security Gateway reporting Mohan> the PMTU to the host, it should account for the additional Mohan> IPSEC header that it would insert for that host. In the I believe that your understanding is correct. A host implementation will have already dealt with reducing the PMTU enough for the outgoing headers. The issue is for non-host (whether BITS, BITW, or gateway) implementations. ] ON HUMILITY: to err is human. To moo, bovine. | SSH IPsec [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |international[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNHLkdMmxxiPyUBAxAQGxhAL/d4wha9uOkfeGCEWUSi1xBx8zpQeIZpOV K/P912P04GmASfewY8N1pAGk9Rm1ngUVKv+jL0nK0ZmyQS1/18Urv1Kjxy3TMnFs NvtlVOQpicwZEvFkgbDVFGsAgmo6QFTR =nOb6 -----END PGP SIGNATURE----- From owner-ipsec Wed Nov 19 08:19:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA03180 for ipsec-outgoing; Wed, 19 Nov 1997 08:18:52 -0500 (EST) Message-Id: <199711191329.IAA16481@relay.hq.tis.com> Date: Wed, 19 Nov 97 8:19:46 EST From: Charles Lynn To: Michael Richardson cc: ipsec@tis.com Subject: Re: Auto filter rule generation for Phase 2 tunnels Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, Stephen> ... the set of security policy rules (filters) MUST be Stephen> ordered. As you note, there is no obvious canonical Stephen> ordering, especially when one adds the other selector Stephen> types defined in the architecture document. > Is there any point in talking about an ordering if there is no > canonical order? Yes, I think there is. The security policy has to be configured, and anything that will contribute to making the specification of that policy less error prone will increase the level of security being provided. The ordering can be used to reduce the complexity of the individual entries, making them easier to understand and thus conclude that they implement the desired policy. > In general, I feel that the architecture document has gone beyond > being a functional specification and gone into being a design > specification. IMHO, there are places where the document does not specify things completely enough (always good for ipsecond :-). On the other hand, I doubt that many of the folks who end up implementing the code will have the level of security expertise available in this group, so I do not think that giving a few hints and pointing out a few catch-22s is unreasonable. (Just because we're paranoid doesn't mean that the box we buy and install to protect our assets (and have no way of subjecting to a security vulnerability review), will protect us. :-) Charlie From owner-ipsec Wed Nov 19 08:26:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA03274 for ipsec-outgoing; Wed, 19 Nov 1997 08:25:53 -0500 (EST) Message-Id: <3.0.32.19971119083531.00740020@bl-mail1.corpeast.baynetworks.com> X-Sender: ndoraswa_pop@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 19 Nov 1997 08:35:31 -0500 To: ETX-DN-SL Christian Gehrmann , Ip-sec working group From: Naganand Doraswamy Subject: Re: VPN:s Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk There will be VPN BOF at this IETF where we hope to discuss some of these unsovled problems. --Naganand ----------------------------------------------------------------- Naganand Doraswamy (978)916-1323 (O) Bay Architecture Lab (978)670-8153 (Fax) 3 Federal St, Mail Stop BL3-04 Billerica, MA 01821 From owner-ipsec Wed Nov 19 09:00:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA03504 for ipsec-outgoing; Wed, 19 Nov 1997 08:58:53 -0500 (EST) Message-Id: <199711191342.IAA04950@morden.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: Auto filter rule generation for Phase 2 tunnels In-reply-to: Your message of "Wed, 19 Nov 1997 08:19:46 EST." <199711191345.IAA09037@lox.sandelman.ottawa.on.ca> Date: Wed, 19 Nov 1997 15:41:47 +0200 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Charles" == Charles Lynn writes: Charles> Yes, I think there is. The security policy has to be Charles> configured, and anything that will contribute to making Charles> the specification of that policy less error prone will Charles> increase the level of security being provided. The But, this is a requirements document on the protocol, not on the user interface. My understanding from this is that each "filter rule" (and remember: not all of us necessarily have filter "rules" at the low level. There are numerous techniques) should have a precedence that is user configurable. This is a very new requirement IMHO. >> In general, I feel that the architecture document has gone >> beyond being a functional specification and gone into being a >> design specification. Charles> IMHO, there are places where the document does not Charles> specify things completely enough (always good for Charles> ipsecond :-). On the other hand, I doubt that many of Charles> the folks who end up implementing the code will have the Charles> level of security expertise available in this group, so I Will there be faulty implementations of IPsec? Yes. And they won't be at the level of "bugs" but rather of "design flaws" --- as Marcus Leech might say: "this isn't rocket science, and I should know, I'm a rocket scientist. It is much harder." Charles> do not think that giving a few hints and pointing out a Charles> few catch-22s is unreasonable. (Just because we're Charles> paranoid doesn't mean that the box we buy and install to Charles> protect our assets (and have no way of subjecting to a Charles> security vulnerability review), will protect us. :-) Don't buy a box that you can't subject to a security vulnerability review. This is an ongoing discussion in the security community. It just doesn't matter what the specifications say: it still has to be reviewed. I am not opposed to this amount of content, I am just not certain that it belongs in the architecture document. I think a shorter base architecture document, and a BCP from IPsecond might be better. I am not convinced that we have the operational experience on the ICMP stuff to really understand what should be done, for instance. I am happy that some text has been written. I think that in ten years we will look back on this document and think "why were we that narrow minded?" --- there are, I think, a lot of advice that could be given to host IPsec implementors, but because the community is doing VPN first, we know those gotchas now, but the host stuff is unknown. The real question is: who is going to organize the end-of-the-IPsec-WG party? ] ON HUMILITY: to err is human. To moo, bovine. | SSH IPsec [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |international[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNHLshcmxxiPyUBAxAQFaEQMAkWABW0ytHd/B+dnhgbnmc2OYEn4H1kAO 7CbL/Fvtpk6qnyoY8Wdwhg/H/yxOqMrSFcObRcbpV4iqGRpEJvhkBfen6Hh7Am4H Hy1IC3CSmzkeoWCJtt3lCEHV6L5ghDhk =luF3 -----END PGP SIGNATURE----- From owner-ipsec Wed Nov 19 11:08:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA04470 for ipsec-outgoing; Wed, 19 Nov 1997 11:02:58 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199711191146.GAA04599@morden.sandelman.ottawa.on.ca> References: Your message of "Tue, 18 Nov 1997 11:58:51 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Nov 1997 11:11:15 -0500 To: Michael Richardson From: Stephen Kent Subject: Re: Auto filter rule generation for Phase 2 tunnels Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Mike, The arch doc tries to explain a (proposed) required interface functionality with the model. In that sense we were not trying to dictate any implementation approach, only to describe the required features. The document emphasizes that the model provided is only illustrative, not normative. The very recent discussion on this list about filters and tunnels at security gateways seems to support the notion that we need to have a model for how this will work, and the issues raised in these messages are addressed in the architecture document. It is precisely because there is no canonical ordering that we were motivated to propose a requirement for an administratively-defined (local) ordering on the SPD. This is exactly what one does in typical packet filtering firewalls and routers, and so the notion is not new to the IPsec environment. There seems to be some support for the notion of checking packets to ensure that they match SA parameters, e.g., to prevent spoofing, and that would seem to require consistent (ordered?) application of filters that is known by both ends of each SA. Steve P.S. Thanks for the positive feedback on the document in general. From owner-ipsec Wed Nov 19 11:31:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA04681 for ipsec-outgoing; Wed, 19 Nov 1997 11:30:59 -0500 (EST) Date: Wed, 19 Nov 1997 11:39:11 -0500 Message-Id: <199711191639.LAA18755@pobox.engeast.BayNetworks.COM> From: Indermohan Singh Monga To: rgm3@chrysler.com Cc: ipsec@tis.com Subject: Re: draft-ietf-ipsec-arch-sec-02.txt and last call In-Reply-To: <3.0.3.32.19971118162816.009361b0@pop3hub.is.chrysler.com> References: <199711181541.KAA08138@ietf.org> <3.0.3.32.19971118162816.009361b0@pop3hub.is.chrysler.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, I wanted to figure out what are the reasons for having the "discard" function as a part of the security policy configuration. This functionality is provided by the Firewall/traffic filters which already implement them pretty well. In the security architecture for IPSec shouldn't we restrict the context to when and how to perform security processing? On a multiport router being a security gateway, implementing a discard policy based on any of the REQUIRED selectors will be detrimental to the performance. Inder >>>>> Robert Moskowitz writes: RM> I really hate last minute things, but I need to point out to all of you RM> that we only have until the 21st 5pm to get anymore drafts in. This does RM> not give Karen and Steve much time, or all of us for that matter. RM> So PLEASE read the draft tonight! Look at it carefully and get your RM> comments off to Karen. We will see what we can do to incorporate any RM> REASONABLE corrections. RM> If there are any burning issues, email me directly. Ted has to dash out of RM> the country for a few days, so I am holding the bag for the rest of the RM> week, so to speak. RM> It would be real significant if we can go to DC with all of these documents RM> having completed last call and ready to submit as RFCs. Then we can start RM> collecting the next round of work items; sigh. RM> Robert Moskowitz RM> Chrysler Corporation RM> (810) 758-8212 From owner-ipsec Wed Nov 19 11:57:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA04874 for ipsec-outgoing; Wed, 19 Nov 1997 11:57:07 -0500 (EST) Message-Id: <199711191707.MAA00770@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-auth-hmac-ripemd-160-96-00.txt Date: Wed, 19 Nov 1997 12:07:43 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Use of HMAC-RIPEMD-160-96 within ESP and AH Author(s) : N. Provos Filename : draft-ietf-ipsec-auth-hmac-ripemd-160-96-00.txt Pages : 5 Date : 18-Nov-97 This draft describes the use of the HMAC algorithm [RFC-2104] in conjunction with the RIPEMD-160 algorithm [RIPEMD-160] as an authentication mechanism within the revised IPSEC Encapsulating Security Payload [ESP] and the revised IPSEC Authentication Header [AH]. HMAC with RIPEMD-160 provides data origin authentication and integrity protection. Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-auth-hmac-ripemd-160-96-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-auth-hmac-ripemd-160-96-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-auth-hmac-ripemd-160-96-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971119115212.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-auth-hmac-ripemd-160-96-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-auth-hmac-ripemd-160-96-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971119115212.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed Nov 19 11:57:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA04875 for ipsec-outgoing; Wed, 19 Nov 1997 11:57:07 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199711191639.LAA18755@pobox.engeast.BayNetworks.COM> References: <3.0.3.32.19971118162816.009361b0@pop3hub.is.chrysler.com> <199711181541.KAA08138@ietf.org> <3.0.3.32.19971118162816.009361b0@pop3hub.is.chrysler.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Nov 1997 12:00:58 -0500 To: Indermohan Singh Monga From: Stephen Kent Subject: Re: draft-ietf-ipsec-arch-sec-02.txt and last call Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Indermohan, The discard function is present because not every IPsec implementation would be part of a firewall, e.g., it could be a stand alone crypto device or a shim in a host stack, etc. Thus we added this option to provide a complete characterization of what to do with every outbound or inbound packet traversing the IPsec interface. Steve From owner-ipsec Wed Nov 19 12:23:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA05036 for ipsec-outgoing; Wed, 19 Nov 1997 12:21:04 -0500 (EST) Date: Wed, 19 Nov 1997 12:31:19 -0500 Message-Id: <199711191731.MAA25906@pobox.engeast.BayNetworks.COM> From: Indermohan Singh Monga To: Stephen Kent Cc: ipsec@tis.com Subject: Re: draft-ietf-ipsec-arch-sec-02.txt and last call In-Reply-To: References: <3.0.3.32.19971118162816.009361b0@pop3hub.is.chrysler.com> <199711181541.KAA08138@ietf.org> <199711191639.LAA18755@pobox.engeast.BayNetworks.COM> Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Steve, So does that mean having a "discard" action in the IPSec Security policy is a SHOULD and not a MUST? I might not want to provide the "discard" choice as an action for my IPSec policy, depending on presence of other subsystems to handle it. Would it make my IPSec implementation non-compliant? Could you clarify what this text encompasses? (pg 14, end of 3rd para.) However, this document does specify a standard set of SPD elements that all IPsec implementations MUST support. Are the actions : bypass, protect and discard, part of the SPD elements? Thanks, Indermohan >>>>> Stephen Kent writes: SK> Indermohan, SK> The discard function is present because not every IPsec SK> implementation would be part of a firewall, e.g., it could be a stand alone SK> crypto device or a shim in a host stack, etc. Thus we added this option to SK> provide a complete characterization of what to do with every outbound or SK> inbound packet traversing the IPsec interface. SK> Steve From owner-ipsec Wed Nov 19 15:46:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA06426 for ipsec-outgoing; Wed, 19 Nov 1997 15:43:10 -0500 (EST) From: brian_st.denis@csg.stercomm.com Message-Id: <9711198799.AA879970732@csg.stercomm.com> X-Mailer: ccMail Link to SMTP R6.01.01 Date: Wed, 19 Nov 97 14:17:05 -0600 To: Subject: finding docs Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Where can I find the latest Internet draft for SKIP? I did not find it on ds.internic.net under IDs. I assume it is an ID. Also, the ISAKMP ID references "[IPDOI]". I found the URL to draft-ietf-ipsec-ipsec-doi-05.txt on the ds.internic.net but I was unable to access the document. "File not found on this server." If there is a place that describes where drafts and other docs can be found and where and how references like [IPDOI] should be followed, that would be good information, too. Thanks in advance. Brian From owner-ipsec Wed Nov 19 17:32:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA07124 for ipsec-outgoing; Wed, 19 Nov 1997 17:31:36 -0500 (EST) Message-Id: <199711192242.WAA07045@orchard.arlington.ma.us> To: Indermohan Singh Monga cc: Stephen Kent , ipsec@tis.com Subject: Re: draft-ietf-ipsec-arch-sec-02.txt and last call In-reply-to: Your message of "Wed, 19 Nov 1997 12:31:19 -0500 ." <199711191731.MAA25906@pobox.engeast.BayNetworks.COM> Date: Wed, 19 Nov 1997 17:42:58 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk So does that mean having a "discard" action in the IPSec Security policy is a SHOULD and not a MUST? I might not want to provide the "discard" choice as an action for my IPSec policy, depending on presence of other subsystems to handle it. I don't understand why this is an issue. ipsec implementations have to be able to discard packets in the case where (for instance) the HMAC doesn't verify, so your ipsec code will be talking to whatever bit of your system does packet discards.. more generically, if your system has a sufficiently generic/flexible framework for selective packet discard, the ipsec policy code can merely reprogram that framework rather than implementing its own filtering.. - Bill From owner-ipsec Wed Nov 19 18:29:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA07380 for ipsec-outgoing; Wed, 19 Nov 1997 18:28:37 -0500 (EST) From: svakil@usr.com Mime-Version: 1.0 Date: Wed, 19 Nov 1997 17:29:58 -0600 Message-ID: <47389090.3000@usr.com> Subject: DH Group strengths To: ipsec@tis.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ipsec@ex.tis.com Precedence: bulk From the Oakley draft, Wellknown group Group Strength (bits) --------------- --------------------- 1 66 2 77 3 76 4 91 Am I correct in assuming that these are the maximum possible strengths of the groups, i.e. no matter what the size of the exponent, the group cannot provide better strength? If this is the case, then which one of the above groups can be used to derive a key for 3DES? Does the SKEYID computation described in the resolution draft add to the strength of the keymaterial? Also, if keys are to be generated for an authentication algorithm, and an encryption algorithm, is the key length for the authentication algorithm also a factor in selecting a DH group? If yes, how are the key requirements for the two algorithms combined in choosing a DH group? For example, if ESP is to use DES and HMAC-MD5, then 56 bits are required for DES and 128 bits for HMAC-MD5. Does this mean that the DH group should provide 56 + 128 = 184 bits of strength, or 128 bits or 56 bits or some combination of 56 and 128? Also, how would the length of the DH exponent be picked? Would it be 184 *2, or 56 *2, or 128 *2? Thanks, Sumit From owner-ipsec Wed Nov 19 19:34:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA07692 for ipsec-outgoing; Wed, 19 Nov 1997 19:33:38 -0500 (EST) Message-ID: <34738787.C2B494D9@sprynet.com> Date: Wed, 19 Nov 1997 16:42:48 -0800 From: Kelly McGrew Reply-To: kelly@mcgrew.net Organization: The McGrew Family X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: brian_st.denis@csg.stercomm.com CC: ipsec@tis.com Subject: Re: finding docs References: <9711198799.AA879970732@csg.stercomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Try: http://www.sun.com/security/skip/ since they are the folks that developed it. brian_st.denis@csg.stercomm.com wrote: > Where can I find the latest Internet draft for SKIP? I did not find > it on ds.internic.net under IDs. I assume it is an ID. > > Also, the ISAKMP ID references "[IPDOI]". I found the URL to > draft-ietf-ipsec-ipsec-doi-05.txt on the ds.internic.net but I was > unable to access the document. "File not found on this server." > > If there is a place that describes where drafts and other docs can be > found and where and how references like [IPDOI] should be followed, > that would be good information, too. > > Thanks in advance. > > Brian From owner-ipsec Wed Nov 19 20:26:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA07970 for ipsec-outgoing; Wed, 19 Nov 1997 20:25:37 -0500 (EST) Date: Thu, 20 Nov 97 01:22:13 GMT Standard Time From: Ran Atkinson Subject: Re: draft-ietf-ipsec-arch-sec-02.txt and last call To: Indermohan Singh Monga , Stephen Kent Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199711191731.MAA25906@pobox.engeast.BayNetworks.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Indermohan, THe document does not say which part of your implementation would do the discarding, just that it happens. I think you're reading the document too literally. On a more pragmatic note, if you don't include the discard feature in your implementation, I believe that you will sell significantly less product and have correspondingly less revenue/profit... A more profitable approach is to have a discard function, but add a system administrator knob for that function. If the default knob setting is discard, then you're compliant. Ran From owner-ipsec Thu Nov 20 02:34:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA09741 for ipsec-outgoing; Thu, 20 Nov 1997 02:31:37 -0500 (EST) Date: Thu, 20 Nov 1997 09:41:36 +0200 (EET) From: Markku-Juhani Saarinen To: svakil@usr.com cc: ipsec@tis.com, Mika Kojo Subject: Re: DH Group strengths [math] In-Reply-To: <47389090.3000@usr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Wed, 19 Nov 1997 svakil@usr.com wrote: > From the Oakley draft, > > Wellknown group Group Strength (bits) > --------------- --------------------- > > 1 66 > 2 77 > 3 76 > 4 91 > > Am I correct in assuming that these are the maximum possible strengths > of the groups, i.e. no matter what the size of the exponent, the group > cannot provide better strength? It is my understanding that "strength" is log2 of the expected number of steps required by the best known discrete logarithm algorithms. It would be silly to use an exponent that is strictly in the range [2, 2^strength]. That would make brute force search the fastest method for solving the Diffie-Hellman problem. Brute force search would take about the same number of steps as the DL algorithms, but the constant factor would be MUCH smaller: /* brute force DL for MODP groups with generator 2 */ a = 1; for (i = 0; a != x; i++) { a = a << 1; if (a >= p) a -= p; } printf("The discrete log of %d is %d!\n", x, i); (Even faster algorithms exist, but you should get the general idea from there. This problem is well suited for certain types of SIMD arrays.) The oakley draft recommends 180 bits of entropy (section 2.3.1.1, Exponent Advice). The exponent could be 180 bits long, or you might want to use longer exponents that are '0'-biased (zeros are 2-3 times cheaper than ones in classical modular exponentiation). In the secure shell drafts (SecSh WG) we recommend choosing a completely random exponent in the range [2, Ord(G)-1]. This is not quite as fast, but gives me a warm & fuzzy feeling. > If this is the case, then which one > of the above groups can be used to derive a key for 3DES? All of them. > Also, if keys are to be generated for an authentication algorithm, and > an encryption algorithm, is the key length for the authentication > algorithm also a factor in selecting a DH group? If yes, (..) No, I don't think so. - mj Markku-Juhani O. Saarinen , SSH Communications Security Ltd From owner-ipsec Thu Nov 20 03:28:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA10005 for ipsec-outgoing; Thu, 20 Nov 1997 03:28:38 -0500 (EST) Date: Thu, 20 Nov 1997 10:38:56 +0200 (EET) From: Markku-Juhani Saarinen To: svakil@usr.com cc: ipsec@tis.com, Mika Kojo Subject: Re: DH Group strengths [math] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk I wrote few minutes ago: > It would be silly to use an exponent that is strictly in the range > [2, 2^strength]. That would make brute force search the fastest method > for solving the Diffie-Hellman problem. I apologize for not thinking first.. Brute force search would not be the fastest algorithm; many discrete logarithm methods run faster if it known that the exponent is small. - mj Markku-Juhani O. Saarinen , SSH Communications Security Ltd From owner-ipsec Thu Nov 20 04:00:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA10127 for ipsec-outgoing; Thu, 20 Nov 1997 03:58:38 -0500 (EST) Message-Id: <199711200821.DAA07450@morden.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: draft-ietf-ipsec-arch-sec-02.txt and last call In-reply-to: Your message of "Thu, 20 Nov 1997 01:22:13 EST." Date: Thu, 20 Nov 1997 10:21:09 +0200 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Ran" == Ran Atkinson writes: Ran> THe document does not say which part of your implementation Ran> would do the discarding, just that it happens. I think Ran> you're reading the document too literally. But, if I'm supposed to use my judgement and put interpretation on the document, why have so much detail in the document? Either the document is prescriptive or not. I reread some portions with the word "discard" in them last night: For every IPsec implementation, there MUST be an administrative interface that allows a user or system administrator to manage the SPD. This interface must allow the user (or system administrator) to specify the security processing to be applied to each packet entering or exiting the system, on a packet by packet basis. (In a host IPsec implementation making use of a socket interface, the SPD may not need to be consulted on a per packet basis, but the effect is still the same.) The management interface for the SPD MUST allow creation of entries consistent with the selectors defined in Section 4.4.2, and MUST support ordering of these entries. If I take this prescriptively, then I must have a knob that let's me discard packets that meet any pattern based on the 'selectors' --- I can not have just a GUI that let's me draw coloured lines between nodes on the two internal networks to allow me to define the VPNs. Implicitely, I am saying "discard everything else" --- if I read the above paragraph literally, then I must offer the administrator the ability to discard any packet based on source, destination, protocol, or port. If I'm not supposed to read that paragraph literally, then why have it there? Finally, the requirement to put ordering on the "entries" in the "database" is a VERY NEW requirement. Why was it not brought up months and months ago? Many of us have done things like that, but we define things our own way, and we do not necessarily give the administrator the right to determine the order. Ran> On a more pragmatic note, if you don't include the discard Ran> feature in your implementation, I believe that you will sell Fine, but let me make the decision, okay? ] ON HUMILITY: to err is human. To moo, bovine. | SSH IPsec [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |international[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNHPy8MmxxiPyUBAxAQEeLwMAipdt4ERDUzTt6x3m4VXdmxSPuaRcSknQ bRMVu+1OO+HWxgn2w7DrDu9ixLI9758gCAT5XNOHpdo5TXGWmuew5fzAh4KNUVot AZ0W2gc3MBnyOjx486eAr5j+V3lCRbI+ =r6mY -----END PGP SIGNATURE----- From owner-ipsec Thu Nov 20 06:59:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA10982 for ipsec-outgoing; Thu, 20 Nov 1997 06:57:37 -0500 (EST) Message-Id: <199711201150.GAA07754@morden.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Questions about PFS and ISAKMP SAs Date: Thu, 20 Nov 1997 13:50:46 +0200 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Recap: To get PFS on IPsec SA's, one uses ephemeral DH exponents to rekey the IPsec keys periodically. Since we throw the DH exponents away, no knowledge of old keys is kept. The DH exponents are authenticated by virtual of being in a Phase I ISAKMP SA that was authenticated via one of the Phase I mechanisms (pre-shared, RSA, etc.) One can negotiate SA's for different end points on the same ISAKMP SA using proxy-IDxx's. Questions: 1. Is is reasonable to have multiple end points that need IPsec PFS using the same ISAKMP SA? Is PFS compatible in concept with sharing the ISAKMP SA? 2. Does PFS extend to the ISAKMP SA? If we should be throwing away the ISAKMP SA's keys, and doing new exponentiations (and new authentications, since we can't use old keys to derive new keys when we need PFS), then how often do we do this for the ISAKMP SA? In the absense of PFS for IPsec, we would use up the entropy of the original ISAKMP SA's DH pair. Since we use a different DH pair for IPsec, the only limit to the ISAKMP SA that we can see is the byte lifetime of the encryption algorithm. More important is probably the lifetime in seconds for a cracking attempt on that size of key. (i.e. change the key once an hour for DES) #2 really asks the question: how do we do PFS for identities? ] ON HUMILITY: to err is human. To moo, bovine. | SSH IPsec [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |international[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNHQkBsmxxiPyUBAxAQHWCwL/dhTZ/qb1HXtLNi0gv8aWf3sbyFxWHtNg c0mcyAmDN9ocSYOUUvVI+V/+9iaDAsB44/KJpsfn1aG/1HEUFlansCvGPdS/Mixo et/gaiqzThPz9Z/sK2eFyyEEa1v5j71+ =QiRP -----END PGP SIGNATURE----- From owner-ipsec Thu Nov 20 08:01:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA11585 for ipsec-outgoing; Thu, 20 Nov 1997 07:58:38 -0500 (EST) Message-Id: <199711201233.HAA07817@morden.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: Questions about PFS and ISAKMP SAs In-reply-to: Your message of "Thu, 20 Nov 1997 13:50:46 +0200." <199711201150.GAA07754@morden.sandelman.ottawa.on.ca> Date: Thu, 20 Nov 1997 14:33:10 +0200 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Michael" == Michael Richardson writes: Michael> In the absense of PFS for IPsec, we would use up the Michael> entropy of the original ISAKMP SA's DH pair. Since we use ^at which point, having used all the entropy in the original ISAKMP DH pair, we might simply do phase I again to get new a DH pair. This it not required, we could simply do a phase II exchange of a new group. ] ON HUMILITY: to err is human. To moo, bovine. | SSH IPsec [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |international[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNHQuAsmxxiPyUBAxAQHsFgL/T/4jsya+US3mDvrjvPWuu0fXoSghALXB iRMW68CB7soI4RixpQqlzUf0xy48OdUUlYl8V/cGpPvwGelbuXltp1W0y479qO3P SfdEEgXbzfotW7/UzTFzR2qP6cAn7PbF =2vp9 -----END PGP SIGNATURE----- From owner-ipsec Thu Nov 20 08:37:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA11803 for ipsec-outgoing; Thu, 20 Nov 1997 08:36:42 -0500 (EST) Date: Thu, 20 Nov 1997 15:55:12 +0200 (EET) From: Helger Lipmaa X-Sender: helger@keeks To: ipsec@tis.com Subject: Re: finding docs In-Reply-To: <34738787.C2B494D9@sprynet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Wed, 19 Nov 1997, Kelly McGrew wrote: > http://www.sun.com/security/skip/ or may be http://www.skip.org Helger From owner-ipsec Thu Nov 20 11:24:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA12825 for ipsec-outgoing; Thu, 20 Nov 1997 11:15:47 -0500 (EST) Date: Thu, 20 Nov 1997 11:21:05 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199711201621.LAA00600@earth.hpc.org> To: svakil@usr.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199711192349.QAA05202@baskerville.CS.Arizona.EDU> Subject: Re: DH Group strengths Sender: owner-ipsec@ex.tis.com Precedence: bulk > From the Oakley draft, > Wellknown group Group Strength (bits) > --------------- --------------------- > 1 66 > 2 77 > 3 76 > 4 91 > Am I correct in assuming that these are the maximum possible strengths > of the groups, i.e. no matter what the size of the exponent, the group > cannot provide better strength? Yes. Also note that these are estimates based on state of the art; they can only decrease over time. > If this is the case, then which one > of the above groups can be used to derive a key for 3DES? What actual strength do you want for 3DES? There's a sort of general consensus that 80-90 bits is sufficient for most purposes. > Does the > SKEYID computation described in the resolution draft add to the > strength of the keymaterial? No. > Also, if keys are to be generated for an authentication algorithm, and > an encryption algorithm, is the key length for the authentication > algorithm also a factor in selecting a DH group? No. The strength indicates how long it would take to derive the key by brute force, and this is basically the same as for encryption. >If yes, how are the > key requirements for the two algorithms combined in choosing a DH > group? For example, if ESP is to use DES and HMAC-MD5, then 56 bits > are required for DES and 128 bits for HMAC-MD5. Does this mean that > the DH group should provide 56 + 128 = 184 bits of strength, or 128 > bits or 56 bits or some combination of 56 and 128? Also, how would > the length of the DH exponent be picked? Would it be 184 *2, or 56 > *2, or 128 *2? As above, no, there's no need to combine the strengths. Also note that each bit of strength adds significant time to the DH computations, because the size of the integers increases. 200 bits of strength would be really, really slow (to use a common term of quantification). From owner-ipsec Thu Nov 20 11:26:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA12883 for ipsec-outgoing; Thu, 20 Nov 1997 11:23:45 -0500 (EST) From: Kai Martius Organization: Uniklinik TUD To: ipsec@tis.com Date: Thu, 20 Nov 1997 17:23:08 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Questions about PFS and ISAKMP SAs Reply-to: kai@imib.med.tu-dresden.de In-reply-to: <199711201150.GAA07754@morden.sandelman.ottawa.on.ca> X-mailer: Pegasus Mail for Windows (v2.54) Message-ID: <6AB77295EF0@fltserv.imib.med.tu-dresden.de> Sender: owner-ipsec@ex.tis.com Precedence: bulk Michael, > Questions: > > 1. Is is reasonable to have multiple end points that need IPsec PFS > using the same ISAKMP SA? Is PFS compatible in concept with > sharing the ISAKMP SA? > > 2. Does PFS extend to the ISAKMP SA? If we should be throwing away > the ISAKMP SA's keys, and doing new exponentiations (and new > authentications, since we can't use old keys to derive new keys when > we need PFS), then how often do we do this for the ISAKMP SA? 2 points: first I think this is a matter of trust in the systems that perform the proxy exchange. Because they know the symmetric key material at the end of a phase 2 exchange a malicious system could store it somewhere for "message recovery"... No PFS or something else would help there. second: assuming trusted ISAKMP servers use of DH exponents in phase II could significantly improve security: 1. If a PASSIVE attacker has cracked ISAKMP SA keys, he can't build the key to be exchanged in phase 2 (if he didn't breaked DH algorithm) because he only sees g^x and g^y, but can't derive g^xy. So for preventing passive attacks the lifetime of ISAKMP SA isn't very important. Other for the active attacker - under this circumstands he can insert own exponents, impersonate endpoints and, of course, by inserting the (own) exponents he can derive the key material. Same applies one level above - ISAKMP SA and keys to autheticated the DH exponents exchanged during ISAKMP SA setup. > In the absense of PFS for IPsec, we would use up the entropy of the > original ISAKMP SA's DH pair. Since we use a different DH pair for > IPsec, the only limit to the ISAKMP SA that we can see is the byte > lifetime of the encryption algorithm. More important is probably the > lifetime in seconds for a cracking attempt on that size of > key. (i.e. change the key once an hour for DES) > > #2 really asks the question: how do we do PFS for identities? Because some of the messages in phase 2 are not random it seems possible for me to collect enough such messages to start attacks against ISAKMP SA. But how much an attacker needs we should ask the cryptographers... However, if the ISAKMP SA keys are cracked - see above. Greetings Kai # Kai Martius # # Dpt. of Medical CS and Biometrics / Dresden University of Technology # # PGP Fingerprint: to be compared after downloading my key # # available at http://www.imib.med.tu-dresden.de/imib/personal/kai.html # From owner-ipsec Thu Nov 20 14:02:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA13881 for ipsec-outgoing; Thu, 20 Nov 1997 13:59:47 -0500 (EST) Date: Thu, 20 Nov 1997 11:05:37 -0800 From: Teodora.Ngo@Eng.Sun.Com (Teodora Ngo) Message-Id: <199711201905.LAA07079@gracepark.Eng.Sun.COM> To: brian_st.denis@csg.stercomm.com, ipsec@tis.com Subject: Re: finding docs Cc: Teodora.Ngo@Eng.Sun.Com X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk >From: Helger Lipmaa > On Wed, 19 Nov 1997, Kelly McGrew wrote: > > > http://www.sun.com/security/skip/ > > or may be http://www.skip.org The drafts are accessible from http://skip.incog.com. http://www.sun.com/security/skip/ has a link to this URL, click on "Additional SKIP information". -Teodora From owner-ipsec Thu Nov 20 17:03:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA14863 for ipsec-outgoing; Thu, 20 Nov 1997 17:00:35 -0500 (EST) Message-Id: <3474B4D5.2213C754@zk3.dec.com> Date: Thu, 20 Nov 1997 17:08:21 -0500 From: "Eric L. Wong" X-Mailer: Mozilla 4.03 [en] (Win95; I) Mime-Version: 1.0 To: will@austin.ibm.com Cc: ipsec@ex.tis.com Subject: Re: More Proxy ID questions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I have similar concerns and wonder if you have received any responses that you can share. > I've been watching the discussion about Phase II Proxy IDs with interest > and have a couple of questions regarding the processing of these IDs. As a > preface to my questions, my understanding of the uses of Proxy IDs is 1; to > specify the selector(s) that the Initiator and Responder will use to > associate particular IP packets to the tunnel utilizing the SA(s) > negotiated in Phase II. And 2; to determine the appropriate Security > Policy for use in negotiation. > > What does it mean when the Initiator sends a IDui, IDur and the Responder > doesn't send any IDs? Does this imply that the Responder will be using the > vaules in the ID payloads sent by the Initiator as selectors for that > particular SA? > My guess is the other end has accepted the IDs and will be using them. > What should happen when the Initiator sends a IDui, IDur and the Responder > sends IDui, IDur that differ from the Initiator's IDs? Is this an error? > Also, can IDui be differ from IDur? E.g. IDui (ID_USER_FQDN) - userA@test.com and UDur (ID_FQDN) - hostB.test.com > Also, in our implementation, if the selector IP addresses are different > from the IP addresses associated with the Phase II (IPSec) SA then tunnel > mode must be used so that the system that receives a IPSec packet can > locate the correct SA. You mean when IDui/IDur is of ID_IPVx_ADDR type and is differ from the isakmp host address, then setup tunnel mode SA. > If this is universally true across the various > implementations then shouldn't the draft-ietf-ipsec-isakmp-oakley specify > that the Encapsulation Mode MUST be tunnel? My concern is that if this > isn't specified this could be a source of numerous tunnel configuration > errors. > > -- > Will Fiveash > IBM AIX System Development Internet: will@austin.ibm.com > 11400 Burnet Road, Bld.905/9551 VNET: FIVEASH AT AUSTIN > Austin, TX 78758-3493 Phone:(512) 838-7904(off)/3509(fax), T/L 678-7904 From owner-ipsec Thu Nov 20 17:06:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA14932 for ipsec-outgoing; Thu, 20 Nov 1997 17:05:24 -0500 (EST) Message-Id: <3.0.3.32.19971120170412.00966a20@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 20 Nov 1997 17:04:12 -0500 To: ipsec@tis.com From: Robert Moskowitz Subject: Pencils up Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Ted and I agreed on the following before he left for Germany, and that I would send this note around this time..... At least as far IETF DC is concerned we are done with ID changes. Ted did resolve the replay question, and Karen still has to publish a version of ESP/AH that aligns with this. Other that than we are done for now. If there are no major issues voiced to me before 5pm friday (hmm, I am actually off line at 2:30, will check sat night), the last call on all of the main documents are done and they are going to the IESG. Thank you everyone. This is just the next step in the standards process. Over the next 6 months we will collect a number of things, like additional ISAKMP payloads or clear ways to state things like DISCARD that we can add as we go from Proposed to Draft standard. ONWARD! Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Thu Nov 20 20:13:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA15872 for ipsec-outgoing; Thu, 20 Nov 1997 20:11:29 -0500 (EST) Message-ID: From: Robert Friend To: "'ipsec@tis.com'" Subject: RE: modifications in draft-ietf-ippcp-protocol-02.txt Date: Thu, 20 Nov 1997 17:24:24 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi All, There's a companion document to Avrum's which defines the algorithm for the IPPCP protocol. It's called . Following the recent IPPCP WG mailing-list discussions, I also modified the LZS Payload Compression Protocol document to include the requested clarifications. The new document is titled . I realize the 11-21-97 date is tommorrow, however, any feedback would be appreciated. A text copy of the -02 document is below. Looking forward to any comments, _____________________________________________________________ Robert C. Friend Hi/fn Applications Engineering 5973 Avenida Encinas, Suite 110 voice: (760) 827-4542 Carlsbad, CA 92008 FAX: (760) 827-4577 email: rfriend@hifn.com I made the following changes to the draft-ietf-ippcp-lzs-01.txt (except #8 below): 1) Abstract section: removed: This document describes a IP compression method based on the LZS ^^ 2) Section 1.2 Background of LZS Compression Changed from: Starting with a sliding window compression history, similar to [LZ1], Hi/fn developed a new, enhanced compression algorithm identified as LZS. The LZS algorithm is optimized to compress all file types as ^^^^^^^^^^^^^^ To: The LZS algorithm is a general purpose lossless compression algorithm for use with a wide variety of data types. Its encoding method is very efficient, providing compression for strings as short as two octets in length. 3) Section 1.2 Background of LZS Compression Replaced: A typical compression ratio is 2:1. With a reference to the table in the appendix (Section 7.). 4) Section 2.2 Anti-expansion of Payload Data Replaced: If the size of a compressed IP datagram, including whatever overhead ^^^^^^^^^^^^^^^^^ With: If the size of a compressed IP datagram, including the Next Header, Flags, and CPI fields, is not smaller than the size of the original IP datagram,...." 5) Section 2.4 Compression Encoding Format Added text to explicitly state that the compressed payload is prepended with the IPComp header. 6) Section 2.5 Padding Added the following statement to specify compliance with the requirement: "The size of a compressed payload MUST be in whole octet units." 7) Section 5. References Removed the following references: DOI, ESP, ISAKMP, RFC-1700, RFC1883, and Thayer 8) I did not modify Section 4. Security Considerations _____________________________________________________________ Robert C. Friend Hi/fn Applications Engineering 5973 Avenida Encinas, Suite 110 voice: (760) 827-4542 Carlsbad, CA 92008 FAX: (760) 827-4577 email: rfriend@hifn.com >-----Original Message----- >From: Avram Shacham [SMTP:shacham@cisco.com] >Sent: Wednesday, November 19, 1997 12:52 AM >To: ipsec@tis.com >Subject: modifications in draft-ietf-ippcp-protocol-02.txt > >Following the recent IPPCP WG mailing-list discussions, I modified the IP >Payload Compression Protocol document to include the requested >clarifications. The new document is titled >. > >A summary of the changes is attached. Please, e-mail me directly requests >for the full text of the document. The plan is to submit the new draft prior >to the 11-21 deadline. > >Looking forward to your prompt comments, >avram > >Summary of the changes from : > >a) 2.1. Compressed Payload >Paragraph 4 - The compression algorithm is responsible to provide a >compressed payload in whole octet units. >Paragraph 5 - Refering to "The original content of the Next Header (IPv6) or >protocol (IPv4) field...", instead of using only "Next Header field". > >b) 2.2. Anti-Expansion Policy >Paragraph 4 - The compressibility test is "algorithm dependent", a phrase >more accurate than "implementation dependent." > >c) 3.1. IPv4 Header Modifications >Explicit reference to Header Checksum. > >d) 3.3. IPComp Header Structure >Clarifications of CPI characteristics and usage: > > Compression Parameter Index (CPI) > > 16-bit index. The CPI is stored in network order. The values > 0-63 are defined by IANA and are used for manual setup, which > requires no additional information. The values 64-61439 are > negotiated between the two nodes in definition of an IPComp > Association, as defined in section 4. The values 61440-65535 > are for private use among mutually consenting parties. Both > nodes participating can select a CPI value independently of each > other and there is no relationships between the two separately > chosen CPIs. The outbound IPComp header MUST use the CPI value > chosen by the decompressing node. The CPI in combination with > the destination IP address uniquely identifies the compression > algorithm characteristics for the datagram. > >e) 5. Security Considerations >Paragraph 1 - Modified "...transport header fields..." to "...transport >layer header fields..." > >f) Several typos were corrected. > >=== end of summary === > > >Internet Draft R. Friend >Expires in six months R. Monsour > Hi/fn, Inc. > November 18, 1997 > > > > IP Payload Compression Using LZS > > > > >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 draft documents are valid for a maximum of six > months and may be updated, replaced, or obsolete by other documents > at any time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > To learn the current status of any Internet-Draft, please check the > "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow > Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), > munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or > ftp.isi.edu (US West Coast). > > Distribution of this memo is unlimited. > > It is intended that a future version of this draft be submitted to > the IESG for publication as an Informational RFC. > >Abstract > > This document describes a compression method based on the LZS > compression algorithm. This document defines the application of the > LZS algorithm to the IP Payload Compression Protocol [IPCOMP]. > [IPCOMP] defines a method for applying lossless compression to the > payloads of Internet Protocol datagrams. > >Acknowledgments > > The LZS details presented here are similar to those in PPP LZS-DCP > Compression Protocol (LZS-DCP), [RFC-1967]. > > The author wishes to thank the participants of the IPPCP working > group mailing list whose discussion is currently active and is > working to generate the protocol specification for integrating > compression with IP. > > > >Friend, Monsour [Page 1] >Internet Draft draft-ietf-ippcp-lzs-01.txt November 18, 1997 > > >Table of Contents > > 1. Introduction...................................................2 > 1.1 General....................................................2 > 1.2 Background of LZS Compression..............................2 > 1.3 Licensing..................................................3 > 1.4 Specification of Requirements..............................3 > 2. Compression Process............................................3 > 2.1 Compression History........................................3 > 2.2 Anti-expansion of Payload Data.............................3 > 2.3 Format of Compressed Datagram Payload......................3 > 2.4 Compression Encoding Format................................4 > 2.5 Padding....................................................5 > 3. Decompression Process..........................................5 > 4. Security Considerations........................................5 > 5. References.....................................................5 > 6. Authors Addresses..............................................7 > 7. Appendix: Compression Efficiency versus Datagram Size..........7 > > > >1. Introduction > > >1.1 General > > This document is a submission to the IETF IP Payload Compression > Protocol (IPPCP) Working Group. Comments are solicited and should be > addressed to the working group mailing list (ippcp@external.cisco.com) > or to the editor. > > This document specifies the application of LZS compression, a lossless > compression algorithm, to IP datagram payloads. This document is to > be used in conjunction with the IP Payload Compression Protocol > [IPCOMP]. This specification assumes a thorough understanding of > the IPComp protocol. > >1.2 Background of LZS Compression > > Starting with a sliding window compression history, similar to [LZ1], > Hi/fn developed a new, enhanced compression algorithm identified as > LZS. The LZS algorithm is a general purpose lossless compression > algorithm for use with a wide variety of data types. Its encoding > method is very efficient, providing compression for strings as short > as two octets in length. > > The LZS algorithm uses a sliding window of 2,048 bytes. During > compression, redundant sequences of data are replaced with tokens that > represent those sequences. During decompression, the original > sequences are substituted for the tokens in such a way that the > original data is exactly recovered. LZS differs from lossy compression > algorithms, such as those often used for video compression, that do > not exactly reproduce the original data. > >Friend, Monsour [Page 2] >Internet Draft draft-ietf-ippcp-lzs-01.txt November 18, 1997 > > > The details of LZS compression can be found in [ANSI94]. > > The efficiency of the LZS algorithm depends on the degree of > redundancy in the original data. A table of compression ratios for > the [Calgary] Corpus file set is provided in the appendix in > Section 7. > >1.3 Licensing > > Hi/fn, Inc. holds patents on the LZS algorithm. Licenses for a > reference implementation are available for use in IPPCP, IPSec, TLS > and PPP applications at no cost. Source and object licenses are > available on a non-discriminatory basis. Hardware implementations are > also available. For more information, contact Hi/fn at the address > listed with the authors' addresses. > >1.4 Specification of Requirements > > 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]. > >2. Compression Process > > >2.1 Compression History > > The sender MUST reset the compression history prior to processing each > datagram's payload. This ensures that each datagram's payload can be > decompressed independently of any other, as is needed when datagrams > are received out of order. > > The sender MUST flush the compressor each time it transmits a > compressed datagram. Flushing means that all data going into the > compressor is included in the output, i.e., no data is held back in > the hope of achieving better compression. Flushing is necessary to > prevent a datagram's data from spilling over into a later datagram. > >2.2 Anti-expansion of Payload Data > > The maximum expansion produced by the LZS algorithm is 12.5%. > > If the size of a compressed IP datagram, including the Next Header, > Flags, and CPI fields, is not smaller than the size of the original > IP datagram, the IP datagram MUST be sent in the original non- > compressed form, as described in [IPCOMP]. > >2.3 Format of Compressed Datagram Payload > > The following is an example datagram that results when using LZS as > the compression algorithm for the IP Payload Control Protocol. Note > that the IP header has been omitted for clarity. > > >Friend, Monsour [Page 3] >Internet Draft draft-ietf-ippcp-lzs-01.txt November 18, 1997 > > 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 | Flags | Compression Parameter Index | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ Payload Data (variable) ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >The Next Header, Flags, Compression Parameter Index fields are all described >in [IPCOMP]. > >2.4 Compression Encoding Format > > The input to the payload compression algorithm is an IP datagram > payload. The output of the algorithm is a new (and hopefully smaller) > payload. The output payload contains the input payload's data in > either compressed or uncompressed format. The input and output > payloads are each an integral number of bytes in length. > > If the uncompressed form is used, the output payload is identical to > the input payload and the IPComp header is omitted. If the > compressed form is used, the output payload is prepended with the > IPComp header and encoded as defined in [ANSI94], which is repeated > here for informational purposes ONLY. > := [] > := 0 | 1 > := (8-bit byte) > := > > := 1 | (7-bit offset) > 0 (11-bit offset) > := 110000000 > > := 1 | 0 > > := > 00 = 2 1111 0110 = 14 > 01 = 3 1111 0111 = 15 > 10 = 4 1111 1000 = 16 > 1100 = 5 1111 1001 = 17 > 1101 = 6 1111 1010 = 18 > 1110 = 7 1111 1011 = 19 > 1111 0000 = 8 1111 1100 = 20 > 1111 0001 = 9 1111 1101 = 21 > 1111 0010 = 10 1111 1110 = 22 > 1111 0011 = 11 1111 1111 0000 = 23 > 1111 0100 = 12 1111 1111 0001 = 24 > 1111 0101 = 13 ... > > > > >Friend, Monsour [Page 4] >Internet Draft draft-ietf-ippcp-lzs-01.txt November 18, 1997 > > >2.5 Padding > > A datagram payload compressed using LZS always ends with the last > compressed data byte (also known as the ), which is used > to disambiguate padding. This allows trailing bits as well as bytes > to be considered padding. > > The size of a compressed payload MUST be in whole octet units. > >3. Decompression Process > > If the received datagram is compressed, the receiver MUST reset the > decompression history prior to processing the datagram. This ensures > that each datagram can be decompressed independently of any other, as > is needed when datagrams are received out of order. Following the > reset of the decompression history, the receiver decompresses the > Payload Data field according to the encoding specified in section 3.2 > of [ANSI94]. > > If the received datagram is not compressed, the receiver needs to > perform no decompression processing and the Payload Data field of the > datagram is ready for processing by the next protocol layer. > >4. Security Considerations > > IP payload compression potentially reduces the security of the > Internet, similar to the effects of IP encapsulation [RFC-2003]. For > example, IPComp makes it difficult for border routers to filter > datagrams based on header fields. In particular, the original value > of the Protocol field in the IP header is not located in its normal > positions within the datagram, and any transport-layer header fields > within the datagram, such as port numbers, are neither located in > their normal positions within the datagram nor presented in their > original values after compression. A filtering border router can > filter the datagram only if it shares the IPComp Association used for > the compression. To allow this sort of compression in environments in > which all packets need to be filtered (or at least accounted for), a > mechanism must be in place for the receiving node to securely > communicate the IPComp Association to the border router. This might, > more rarely, also apply to the IPComp Association used for outgoing > datagrams. > > When IPComp is used in the context of IPSec, it is not believed to > have an effect on the underlying security functionality provide by > the IPSec protocol; i.e., the use of compression is not known to > degrade or alter the nature of the underlying security architecture > or the encryption technologies used to implement it. > >5. References > > [AH] Kent, S. and Atkinson, R., "IP Authentication Header", draft- > > > >Friend, Monsour [Page 5] >Internet Draft draft-ietf-ippcp-lzs-01.txt November 18, 1997 > > > ietf-ipsec-auth-header-01.txt, Work in Progress, July 1997. > [ANSI94] American National Standards Institute, Inc., "Data > Compression Method for Information Systems," ANSI X3.241-1994, August > 1994. > > [Calgary] Text Compression Corpus, University of Calgary, available > at ftp://ftp.cpsc.ucalgary.ca/pub/projects/text.compression.corpus. > > [IPCOMP] Shacham, A., "IP Payload Compression Protocol (IPComp)", > draft-ietf-ippcp-protocol-01.txt, Work in Progress, October 1997. > > [LZ1] Lempel, A. and Ziv, J., "A Universal Algorithm for Sequential > Data Compression", IEEE Transactions On Information Theory, Vol. IT- > 23, No. 3, May 1977. > > [RFC-1962] Rand, D., "The PPP Compression Control Protocol (CCP)", > RFC-1962, June 1996. > > [RFC-1967] K. Schneider, R. Friend, "PPP LZS-DCP Compression Protocol > (LZS-DCP)", RFC-1967, August, 1996. > > [RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, > October 1996. > > [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", RFC 2119, March 1997. > >6. Authors Addresses > > Robert Friend > Hi/fn Inc. > 5973 Avenida Encinas > Suite 110 > Carlsbad, CA 92008 > Email: rfriend@hifn.com > > Robert Monsour > Hi/fn Inc. > 2105 Hamilton Avenue > Suite 230 > San Jose, CA 95125 > Email: rmonsour@hifn.com > > > > > > > > > > > > >Friend, Monsour [Page 6] >Internet Draft draft-ietf-ippcp-lzs-01.txt November 18, 1997 > > >7. Appendix: Compression Efficiency versus Datagram Size > > The following table offers some guidance on the compression > efficiency that can be achieved as a function of datagram size. > Each entry in the table shows the compression ratio that was > achieved when LZS was applied to a test file using datagrams of a > specified size. > > The test file was the University of Calgary Text Compression Corpus > [Calgary]. The Calgary Corpus consists of 18 files with a total > size (all files) of 3.278MB. > > Datagram size,| > bytes | 64 128 256 512 1024 2048 4096 8192 16384 > --------------|---------------------------------------------------- > Compression |1.18 1.28 1.43 1.58 1.74 1.91 2.04 2.11 2.14 > ratio | > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Friend, Monsour [Page 7] From owner-ipsec Thu Nov 20 23:52:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA16944 for ipsec-outgoing; Thu, 20 Nov 1997 23:50:29 -0500 (EST) Message-Id: <199711210502.AAA05409@relay.rv.tis.com> Date: Thu, 20 Nov 97 23:58:37 EST From: Karen Seo To: ipsec@tis.com Subject: IPsec AH and ESP specs Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, We just sent the IPsec AH and ESP drafts to the IETF secretariat. Karen From owner-ipsec Fri Nov 21 06:01:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA18748 for ipsec-outgoing; Fri, 21 Nov 1997 05:57:30 -0500 (EST) Message-Id: <199711211048.FAA09823@morden.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: Questions about PFS and ISAKMP SAs In-reply-to: Your message of "Thu, 20 Nov 1997 17:23:08 +0100." <6AB77295EF0@fltserv.imib.med.tu-dresden.de> Date: Fri, 21 Nov 1997 12:48:26 +0200 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- [Yes, Kai, I still owe you a reply from September :-)] >>>>> "Kai" == Kai Martius writes: Kai> Michael, >> Questions: >> >> 1. Is is reasonable to have multiple end points that need IPsec >> PFS using the same ISAKMP SA? Is PFS compatible in concept with >> sharing the ISAKMP SA? >> >> 2. Does PFS extend to the ISAKMP SA? If we should be throwing >> away the ISAKMP SA's keys, and doing new exponentiations (and >> new authentications, since we can't use old keys to derive new >> keys when we need PFS), then how often do we do this for the >> ISAKMP SA? Kai> 2 points: Kai> first I think this is a matter of trust in the systems that Kai> perform the proxy exchange. Because they know the symmetric Kai> key material at the end of a phase 2 exchange a malicious Kai> system could store it somewhere for "message recovery"... No Kai> PFS or something else would help there. Agreed. The point being that one end or the other end may get compromised, and/or the ISAKMP SA key may be brute force attacked. The Phase II identities would then be available for a potentially very long period of time. That may provide enough information in of itself to constitute an attack. Kai> second: assuming trusted ISAKMP servers use of DH exponents Kai> in phase II could significantly improve security: 1. If a Kai> PASSIVE attacker has cracked ISAKMP SA keys, he can't build Kai> the key to be exchanged in phase 2 (if he didn't breaked DH Kai> algorithm) because he only sees g^x and g^y, but can't derive Understood. Question #2 relates to PFS of identities. In the absense of PFS for IPSEC keys, one tends to get PFS for identities, because the DH pair runs out of entropy, and one does a new phase I exchange. isakmp-oakley answers my #1 above in section 10: 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. [which goes to show, that one should pretend to have not read any drafts, and try and re-read everything as if one has never read the draft before..] Perhaps, I should be asking: given that PFS of keying material requires that one generate new keys at relatively frequent intervals, it is desirable to get as many keys per DH exponent as possible. Perhaps, one needn't delete the ISAKMP SA, but simply rekey it? ] ON HUMILITY: to err is human. To moo, bovine. | SSH IPsec [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |international[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNHVm2cmxxiPyUBAxAQEimAL8Cvq6w4Z/2FCez9mfKrD4E8y/wzPqr72M rUuJiuTJMzgwys3+NLF/dryC5/F8Rv0omzGa5/wMjp/cRlVPVin/n+3XvreKdZSq REz8JAPCkijH7P9Id8uAUbPSB7BguSpo =QvoQ -----END PGP SIGNATURE----- From owner-ipsec Fri Nov 21 09:56:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA20620 for ipsec-outgoing; Fri, 21 Nov 1997 09:54:38 -0500 (EST) Message-Id: <199711211454.JAA14688@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-02.txt Date: Fri, 21 Nov 1997 09:54:36 -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-02.txt Pages : 8 Date : 20-Nov-97 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-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ippcp-protocol-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-ippcp-protocol-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: <19971120154515.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippcp-protocol-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippcp-protocol-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971120154515.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Fri Nov 21 11:06:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA21040 for ipsec-outgoing; Fri, 21 Nov 1997 11:04:29 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199711200821.DAA07450@morden.sandelman.ottawa.on.ca> References: Your message of "Thu, 20 Nov 1997 01:22:13 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Nov 1997 11:09:53 -0500 To: Michael Richardson From: Stephen Kent Subject: Re: draft-ietf-ipsec-arch-sec-02.txt and last call Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Mike, Having watched the reverse chronological Seinfield episode last night, I'll respond to your final observation first; the ordering requirement for SPD entries is not new. It was present in the 7/30 version of the security architecture document as well as the current version. If an administrator cannot determine the order for SPD entries, then it will not be possible to express some policies, because of overlaps in selectors and an inability to impose a canonical ordering on the selectors. Hence the motivation for that requirement. As for the question of the level of administrative control required by the arch doc, you are right that it requires the ability to specify packet processing, incluidng discard, at the granularity of ports, etc. For example, a user of a security gateway might want to allow SMTP traffic through (w/o IPsec processing) if addressed to a mail server behind the gateway, but require IPsec for other traffic to that or other hosts behind the gateway. That level of control will be available only if port-level SAs are supported. The question is whether the WG wants compliant implementations to offer only a subset of possible, reasonable policies. Unfortunately, this is an interoperability issue, not just a local matter, in that both ends of an SA need to be able to offer the same granularity of selection. Hence the inclusion in this document. Ultimately, the WG must decide what set of policies are of sufficiently general interest to warrent mandatory inclusion. We did receive some private feedback on the 7/30 version of the document and made changes to reflect those comments. Other than your recent comments, we have received almost no feedback on this version, and the SPD requirements have not changed substantively sibce then. (The main change to that portion of the document was to remove the notion of the SAM, an eficiency hack that was not essential to explaining the administrative interface and one that also had some technical problems!) Steve From owner-ipsec Fri Nov 21 11:58:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA21361 for ipsec-outgoing; Fri, 21 Nov 1997 11:55:31 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199711191731.MAA25906@pobox.engeast.BayNetworks.COM> References: <3.0.3.32.19971118162816.009361b0@pop3hub.is.chrysler.com> <199711181541.KAA08138@ietf.org> <199711191639.LAA18755@pobox.engeast.BayNetworks.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Nov 1997 11:54:44 -0500 To: Indermohan Singh Monga From: Stephen Kent Subject: Re: draft-ietf-ipsec-arch-sec-02.txt and last call Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Indermohan, Your intuition is correct. The intent of the text is that a compliant implementation MUST support the discard fucntion, along with bypass and IPsec processing. If IPsec is part of a box that also implements a firewall function, then the line between the two may be blurred and provision of the discard function elsewhere in the box would seem reasonable. However, for a stand alone implementation, the discard function is important, e.g., it can prevent traffic from reaching the firewall or host and thus may provide a higher level of assurance that would be available from the devicve behind the IPsec implementation. Steve From owner-ipsec Fri Nov 21 12:44:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA21697 for ipsec-outgoing; Fri, 21 Nov 1997 12:43:29 -0500 (EST) Message-Id: <199711211731.MAA07264@ghostwheel.ncsl.nist.gov> Date: Fri, 21 Nov 1997 12:31:29 -0500 (EST) To: ipsec@tis.com From: rob.glenn@nist.gov Subject: new draft-ietf-ipsec-doc-roadmap-02.txt posted X-Mailer: Ishmail 1.3.2-970722-linux MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk A revised version of the Document Roadmap draft has been submitted. The changes were very minor since we received very few comments during WG last call (and they were editorial). Here is a summary: 1. Changed reference to key length to key attributes in section 3, paragraph 2. 2. Clarified some text in section 4. 3. Cleaned up and brought up-to-date the references section. 4. Referenced RFC-2202 as an example test vector document. 5. Referenced Architecture document as providing guidance on how to "slice and dice" key material (it used to reference ESP). draft-ietf-ipsec-doc-roadmap-02.txt should appear at your favorite I-D site shortly. Rob G. From owner-ipsec Fri Nov 21 13:22:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA21887 for ipsec-outgoing; Fri, 21 Nov 1997 13:21:29 -0500 (EST) From: Cheryl Madson Message-Id: <199711211832.KAA07956@trix.cisco.com> Subject: IPSEC SA doc comments To: ipsec@tis.com Date: Fri, 21 Nov 1997 10:32:17 -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 I haven't been able to read this as thoroughly as I would have liked; in spite of the saying, time has done nothing to make certain that everything doesn't happen at once (well, sleep isn't happening too much, so hopefully this is somewhat coherent). The cross-checking between documents that I had hoped to do didn't happen [apart from what I can reconstruct from memory or my interpretation of things]; sigh. 1. Is ippcp a WG yet? 2. Section 4.2, last paragraph. To me, the SA granularity plays a big part in the traffic flow confidentiality. A granularity of a single session, even running in tunnel mode, isn't as useful (traffic flow confidentiality-wise) as a single tunnel securing possibly multiple streams. In the mobile user case, the only thing that is really hidden is the identities, but probably not much in terms of "what is going on" ("the SYN packet is happening here"). 3. Section 4.3. In the discussion of iterated tunnelling, something should be said about what to do w.r.t. ISAKMP packets. In the case of H1 -- SG1====SG2, where H1 has a pipe with SG2, and those packets are subsequently reencapsulted in SG1, do the H1-SG2 ISAKMP packets get stuffed in the tunnel? The informal poll at the Detroit bakeoff said "yes". But this hasn't really been put down anywhere. But, if the "iterated nesting" occurs between the same systems, what then? [It may pan out just fine, but this thought just crossed my mind while typing this; we need to make certain if we do such stuffing that we cover the various scenarios.] 4. page 14, last full paragraph. Last sentence, starting with "For each selector...". I'm not understanding scenario (a). 5. I'm not comfortable with the statement that an SA can be used in multiple SA bundles. I just tried to write something here, but I'm having a hard time describing it. It may simply be because my mental model of an "SA bundle" has been what has resulted from a single ISAKMP negotiation, which differs from the definition used here. I need to go back and convince myself that I do or don't have an issue here. 6. For various reasons, the DOI does not match the SA document in terms of what can be used as SA selectors. If I can't negotiate it in an ISAKMP exchange, I can't consider using it as an SA selector (which is different from saying what kinds of selection criteria I will use in referencing my SPD). The DOI does not support ranges of anything except IP addresses, and it does not support lists of anything. Putting down these selectors as a MUST requirement is going to collide with a document that now has completed last call. [I mentioned this as an issue in Munich, but it didn't get resolved.] 7. Related to (6): I can see where ranges and lists can be nice things; I've wished for them myself for ports, for example. However, since the ISAKMP exchange is effectively one where the responder can't refine the settings given by the initiator (except for selecting one transform proposal from the list), if the responder does accept part of the specified range/list, but not all of it, the responder is forced to reject the whole request. There is no mechanism for the responder to say "yes, but for only a subset of the requested identities". This problem already occurs when using subnets, but somehow in my mind it could be worse in the case of ranges (especially if what the initiator requests and what the responder accepts partially overlap). While on the general subject, I've always thought that "negative entries" could be a nice idea (specify a range, and then punch a hole in it, e.g. "everything here except SMTP traffic"). Still, the massive complexity of such a thing would be too horrific. The dirty secret in effect is that the sender may send traffic through the pipe that he thinks is allowed/accepted by the receiver, to (possibly) discover that the receiver may drop it on the floor because it was that SMTP traffic... [In this case, the sender isn't the initiator of the original ISAKMP negotiation.] I don't see a good resolution to such a thing (apart from some sort of separate tunnel establishment protocol), except by making it quite clear in the document that such things can happen. 8. Page 17. I don't understand having "IPSEC protocol" as a separate SA selector field (separate from "protocol". 9. The DOI also doesn't specify TOS. 10. I jotted down a note about "accepting finer-grained requests in SAs". I think it had to do with the SPD search to find the appropriate SA, where once there is a "hit" in the SPD, that the SADB search needs to find the finest-grained SA entry that covers the traffic. And also that as a responder I'll accept something that falls within the range of a particular SPD entry. My SPD may say "subnet A to subnet B", but I may have an SA from "host A.1 to host B.2", and another one from "host A.1 to host B.3". It's as if the SPD entry pointed to a small tree of SA entries. I wrote down this note, but I didn't try to go back and see if this was described anywhere... 11. Page 23. To support the following: IP(dest=B, src=A) + AH + IP(dest=B, src=A) + ESP + transport data will require two ISAKMP negotiations, one for the tunnel mode part (SA selectors = A/B, prot = AH), and one for the transport mode part (SA selectors = A/B, prot = whatever except AH). That isn't a problem (I don't think), just an observation. For one, I don't think (and any ISAKMP geeks can correct me on this, but the current resolution document still looks that way), a single SA negotiation only includes a single pair of identifiers (SA selectors as it were). For another, you may want the outer tunnel to support multiple transport sessions. 12. Page 31. If a single ISAKMP negotiation results in a pair of SAs (AH+ESP) per direction, I would want to make certain that if SAs (AH:300 + ESP:410) were established together, that they both exist, in that order, in the received packets. I won't allow AH:300 + ESP:500 for example, even if ESP:500 exists and is from the same source as 410. 13. ICMP processing: I assume we're talking about errors, and not about things such as echo/reply. 14. Don't subject the router-generated ICMP message to source address checks? Huh? 15. Propogation of PMTU, page 33, last line of second-to-last bullet. In reading the last line, it seems to me that the behavior is beyond that required by a tunnel. Why should the "immediate return of a path MTU message" be a MUST? [I don't have the relevent RFC handy, so I can't check this out myself.] 16. Page 35, first full paragraph. What's the general opinion been of using the behavior described in RFC1191 as opposed to what's been described in RFC2003? [I'm talking about the issue of whether or not to forward the packet through the tunnel anyhow if it's too big.] The poll I did on the anx-sec list seemed to run off on a tangent here. 17. Michael Richardson had brought up the question: "if an intermediate system receives a PMTU message not targeted toward it, but where forwarding would stuff it into an IPSEC tunnel, should that message be forwarded?" [Michael can correct me if I'm misquoting him ;-).] Anyhow, has there been some resolution to this scenario? 18. Go through the References and see if they're still being used in the document. I was a bit suprised to still see a reference to [Hugh96] for example. Also, make certain they still exist (in the case of I-Ds). - C From owner-ipsec Fri Nov 21 14:22:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA22160 for ipsec-outgoing; Fri, 21 Nov 1997 14:20:17 -0500 (EST) From: Cheryl Madson Message-Id: <199711211930.LAA11795@trix.cisco.com> Subject: new DES cipher draft To: ipsec@tis.com Date: Fri, 21 Nov 1997 11:30:11 -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 I just submitted draft-ietf-ipsec-ciph-des-explicit-iv-01.txt. Change summary: 1. There were several places with "get more info" or "TBD". Filled in the details (weak key check failure causes IPSEC to request a new SA, padding will be as specified in ESP document) or removed them. [There are no recommended key lifetimes, for example.] 2. There was a reference to a document which may or may not be published as an RFC; I did not get information from the author as to its state, so I removed it as a reference. - C From owner-ipsec Fri Nov 21 16:55:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA23092 for ipsec-outgoing; Fri, 21 Nov 1997 16:52:17 -0500 (EST) Message-Id: <3.0.1.32.19971121140014.0273eed8@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 21 Nov 1997 14:00:14 -0800 To: Cheryl Madson From: Bob Monsour Subject: Re: IPSEC SA doc comments Cc: ipsec@tis.com, cmadson@cisco.com (Cheryl Madson) In-Reply-To: <199711211832.KAA07956@trix.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:32 AM 11/21/97 -0800, Cheryl Madson wrote: [snip] >1. Is ippcp a WG yet? IPPCP is a WG and we held our first meeting in Munich. Several drafts of the protocol spec have been submitted and reviewed and the current protocol draft (draft-ietf-ippcp-protocol-02.txt) is in WG last call as we speak. Regards, -Bob ---------------------------------------------------------------- Bob Monsour Hi/fn Inc. rmonsour@hifn.com 2105 Hamilton Avenue 408-558-8065 Suite 230 408-558-8074 fax San Jose, CA 95125 ---------------------------------------------------------------- From owner-ipsec Tue Nov 25 10:20:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA17876 for ipsec-outgoing; Tue, 25 Nov 1997 10:10:35 -0500 (EST) Date: Tue, 25 Nov 1997 11:15:25 -0300 From: Gordon Oliver Subject: IPSEC SA scenario comment/question. To: ipsec@tis.com Message-Id: X-Mailer: TkMail 4.0beta9 Sender: owner-ipsec@ex.tis.com Precedence: bulk Given the Scenario H1 ---> SG1 ---> SG2, where H1 is communicating directly with SG2 (e.g. remote administration of the SG2 firewall, from within a protected domain). In this case it is possible, according to the SA document, to have SG1 create a tunnel of fragments to SG2. This implies that SG2 has to "double process" the packets (i.e. process the tunnel between SG1 and SG2, queue fragment for integration, process for any SA's between H1 and SG2). should this scenario be supported? It seems a useful scenario, especially for an AH header from the host (authenticate the admin), and an ESP tunnel in the internet (hide the data from outsiders). -- --------------------------------------------------------------- Gordon Oliver (gordo@telsur.cl) Independent Consultant ... Available for consulting on Linux ... From owner-ipsec Tue Nov 25 17:57:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA20656 for ipsec-outgoing; Tue, 25 Nov 1997 17:55:00 -0500 (EST) Message-ID: From: "Boyter, Brian A." To: "'ipsec@tis.com'" Subject: US Air Force IPSEC Requirements Date: Tue, 25 Nov 1997 17:03:03 -0600 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk First, I would like to introduce myself... My name is Brian Boyter, I'm a Senior Consulting Engineer with the Computer Sciences Corp, and I am under contract to the US Air Force Information Warfare Center in San Antonio, Texas, working on USAF computer security... The USAF is evaluating the use of IPSEC products to help secure its unclassified networks... These unclas networks are used to communicate with contractors, and to process financial, logistic, personnel, and medical data... The IPSEC would be used to protect the data from unauthorized viewing and to protect the networks and computers from hackers... Our goal is to eventually IPSEC encrypt all unclassified computer communications end-to-end... The USAF recently completed a hasty evaluation of several IPSEC products... Most products would work fine for a small organization, but do not scale to an enterprise the size of the USAF (500,000 computers)... Here is a short list of basic USAF requirements which we found lacking in the current IPSEC products: 1. The Department of Defense will soon deploy a Public Key Infrastructure (PKI)... The IPSEC products need to use this existing PKI (not require a separate keying product)... 2. The USAF uses HP OpenView as its standard SNMP management product... Error logging and other IPSEC status information needs to interoperate with OpenView... 3. The USAF needs to be able to manage the IPSEC security policy sanely... An example of a USAF IPSEC security policy might be: "all USAF computers can talk to all other USAF computers using DES, all other computers it talks in-the-clear"... It will not be possible to manage 500,000 different rule sets... The security policy must be made simple... We need the X.500 equivalent of *.mil, *.af.mil, *.lackland.af.mil, and *.hospital.*.af.mil so that we can generate rule sets using these wild cards... I don't think rules based on IP addresses will work either... I'm not including interoperability in the above list because the ANX has done a good job of making that requirement visible.... What I'm trying to point out is two things: 1. The IPSEC products need to re-use as much of our existing infrastructure as possible (for example PKI, SNMP, etc)... If the USAF were a small company that didn't have a large infrastructure investment already, it wouldn't be an issue... But if each IPSEC product requires a management console at each air force base, then that can add up to millions of dollars, thousands of man hours, training costs, etc... 2. I'm also trying to point out that there is no standard (that I can find) for representing, storing, or disseminating the security policy.... Although these are Air Force requirements, I'm sure the same requirements will exist for any large enterprise contemplating the use of IPSEC products... I plan to be at the IETF meeting in December and will be glad to speak to anyone about these issues... Perhaps an IPSEC security policy BOF could even be arranged??? Thanks, Brian Boyter boyter@afiwc01.af.mil (210)977-3113 From owner-ipsec Tue Nov 25 19:21:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA21042 for ipsec-outgoing; Tue, 25 Nov 1997 19:17:41 -0500 (EST) Message-ID: <0171F2F8F9E5D011A4D10060B03CFB44064F58@scc-server3.semaphorecom.com> From: Brian Leu To: kent@bbn.com Cc: ipsec@tis.com Subject: RE: draft-ietf-ipsec-arch-sec-02.txt and last call Date: Tue, 25 Nov 1997 16:36:25 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen, I have a question on the third paragraph of page 14, "The SPD contains an ordered list of policy entries." Does this imply that the SPD entry ordering defined by the administrator through the administrative interface is the sequence used in searching for the right SPD entry ? Let me give an example here. If a firewall has the SPD entries defined as the following: 1. Host A -> Subnet B, discard 2. Subnet A -> Host B, bypass 3. Host A -> Host B, IPSEC ESP 3DES-CBC w/ HMAC MD5 (Assuming each host is in its respective subnet, i.e., Host A in Subnet A.) If implementation is IPSEC compliant then all traffic from host A to host B will be discarded (matching the first entry). Right ? If an implementation can ensure that the search will always produce a consistent and predictable result without imposing the canonical ordering of the SPD entries then is it IPSEC compliant ? For example, if my search is based on the explicitness of the selectors and always locates the entry that has the most explicit selectors first, then is it IPSEC compliant ? (A host is considered more explicit than a subnet and a subnet is more explicit than a wild card.) In the example above, the search will locate the third entry as matching instead. It seems to me that if imposing the canonical ordering on the SPD entries then for every packet there is an overhead which on the average is proportional (linearly) to the number of entries in SPD because the search is sequential. -Brian -----Original Message----- From: Stephen Kent [SMTP:kent@bbn.com] Sent: Friday, November 21, 1997 8:10 AM To: Michael Richardson Cc: ipsec@tis.com Subject: Re: draft-ietf-ipsec-arch-sec-02.txt and last call Mike, Having watched the reverse chronological Seinfield episode last night, I'll respond to your final observation first; the ordering requirement for SPD entries is not new. It was present in the 7/30 version of the security architecture document as well as the current version. If an administrator cannot determine the order for SPD entries, then it will not be possible to express some policies, because of overlaps in selectors and an inability to impose a canonical ordering on the selectors. Hence the motivation for that requirement. As for the question of the level of administrative control required by the arch doc, you are right that it requires the ability to specify packet processing, incluidng discard, at the granularity of ports, etc. For example, a user of a security gateway might want to allow SMTP traffic through (w/o IPsec processing) if addressed to a mail server behind the gateway, but require IPsec for other traffic to that or other hosts behind the gateway. That level of control will be available only if port-level SAs are supported. The question is whether the WG wants compliant implementations to offer only a subset of possible, reasonable policies. Unfortunately, this is an interoperability issue, not just a local matter, in that both ends of an SA need to be able to offer the same granularity of selection. Hence the inclusion in this document. Ultimately, the WG must decide what set of policies are of sufficiently general interest to warrent mandatory inclusion. We did receive some private feedback on the 7/30 version of the document and made changes to reflect those comments. Other than your recent comments, we have received almost no feedback on this version, and the SPD requirements have not changed substantively sibce then. (The main change to that portion of the document was to remove the notion of the SAM, an eficiency hack that was not essential to explaining the administrative interface and one that also had some technical problems!) Steve From owner-ipsec Wed Nov 26 01:39:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA22855 for ipsec-outgoing; Wed, 26 Nov 1997 01:35:42 -0500 (EST) Message-Id: <199711260648.IAA22586@morden.sandelman.ottawa.on.ca> To: Brian Leu CC: ipsec@tis.com Subject: Re: draft-ietf-ipsec-arch-sec-02.txt and last call In-reply-to: Your message of "Tue, 25 Nov 1997 16:36:25 PST." <0171F2F8F9E5D011A4D10060B03CFB44064F58@scc-server3.semaphorecom.com> Date: Wed, 26 Nov 1997 08:47:44 +0200 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Brian" == Brian Leu writes: Brian> It seems to me that if imposing the canonical ordering on the SPD Brian> entries then for every packet there is an overhead which on the average Brian> is proportional (linearly) to the number of entries in SPD because the Brian> search is sequential. Exactly. This was my (unstated) thinking behind an objection to the explicit SPD ordering. It is just isn't computationally efficient at times. This remains my major objection to most of the firewall performance testing that has been done: they have not measured performance as a function of rule complexity. This is where is really counts. ] ON HUMILITY: to err is human. To moo, bovine. | SSH IPsec [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |international[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNHvGDcmxxiPyUBAxAQE5AgMAolfZ4tthozcWWsmS+jIqwqEoLgyI267D uGXs1J+cSTZLdWT2p+p9lbFt69EpocbLUgvXVqrqTD3DFkpI4mL0ThRb5UztSsuW vKjU0GDQbVC8h97LQfEk+zAcvlIMiFCu =XD07 -----END PGP SIGNATURE----- From owner-ipsec Wed Nov 26 08:39:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA24948 for ipsec-outgoing; Wed, 26 Nov 1997 08:37:39 -0500 (EST) Message-Id: <199711261348.IAA14176@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-auth-header-03.txt Date: Wed, 26 Nov 1997 08:48:10 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IP Authentication Header Author(s) : S. Kent, R. Atkinson Filename : draft-ietf-ipsec-auth-header-03.txt Pages : 23 Date : 24-Nov-97 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 wih 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-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-auth-header-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-auth-header-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: <19971124174102.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-auth-header-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-auth-header-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971124174102.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed Nov 26 09:05:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA25161 for ipsec-outgoing; Wed, 26 Nov 1997 09:04:42 -0500 (EST) Message-Id: <199711261414.JAA14714@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipsec@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-ipsec-esp-v2-02.txt Date: Wed, 26 Nov 1997 09:14:40 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IP Encapsulating Security Payload (ESP) Author(s) : S. Kent, R. Atkinson Filename : draft-ietf-ipsec-esp-v2-02.txt Pages : 21 Date : 24-Nov-97 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 wih 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-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-esp-v2-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-esp-v2-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: <19971124174331.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-v2-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-v2-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971124174331.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed Nov 26 09:42:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA25331 for ipsec-outgoing; Wed, 26 Nov 1997 09:40:41 -0500 (EST) Message-Id: <3.0.3.32.19971126094719.00bac900@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 26 Nov 1997 09:47:19 -0500 To: "Boyter, Brian A." , "'ipsec@tis.com'" From: Robert Moskowitz Subject: Re: US Air Force IPSEC Requirements In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 05:03 PM 11/25/97 -0600, Boyter, Brian A. wrote: >First, I would like to introduce myself... Hello Brian, glad to see you go 'public' :) >The USAF recently completed a hasty evaluation of several >IPSEC products... Most products would work fine for a >small organization, but do not scale to an enterprise the size >of the USAF (500,000 computers)... This is definitely on my agenda also. >1. The Department of Defense will soon deploy a Public >Key Infrastructure (PKI)... The IPSEC products need to >use this existing PKI (not require a separate keying product)... I do not understand this one. Granted there is no interoperability in CA products yet, so IPsec vendors have to pick and choose their product interop based on market demand. I am testing with cross-certified CAs. This is more of a PKIXs issue than an IPsec issue. BTW, our PKIs will have to cross-ceritify and we will have to work out the trust model (many of my suppliers are your suppliers...). >2. The USAF uses HP OpenView as its standard SNMP >management product... Error logging and other IPSEC status >information needs to interoperate with OpenView... There is growing discussion on MIBs for firewalls, security tunnels and other thingees. This will be discussed at DC to decide what direction to take. >3. The USAF needs to be able to manage the IPSEC security >policy sanely... An example of a USAF IPSEC security policy >might be: "all USAF computers can talk to all other USAF >computers using DES, all other computers it talks in-the-clear"... >It will not be possible to manage 500,000 different rule sets... >The security policy must be made simple... We need the X.500 >equivalent >of *.mil, *.af.mil, *.lackland.af.mil, and *.hospital.*.af.mil so >that >we can generate rule sets using these wild cards... I don't think >rules based on IP addresses will work either... This should be easy for those products that allow for trust rules based on certificate content. For me it might be *.anx.* ;) >I'm not including interoperability in the above list because the ANX >has done a good job of making that requirement visible.... thank you. More to do... >But if each IPSEC >product >requires a management console at each air force base, then that can >add up to millions of dollars, thousands of man hours, training costs, >etc... But you will need a secure protocol for the management. SNMP does not seem to fit that target. Perhaps SNMP in an IPsec tunnel :) >2. I'm also trying to point out that there is no standard (that I can >find) for >representing, storing, or disseminating the security policy.... Do we have a model for security policy, or rather models? One idea I am playing with is to right the security policy in PolicyMaker and put it in a certificate from the policy server.... >Although these are Air Force requirements, I'm sure the same >requirements will exist for any large enterprise contemplating the >use >of IPSEC products... I hear these things over and over again. >I plan to be at the IETF meeting in December and will be glad to >speak to anyone about these issues... Perhaps an IPSEC security >policy BOF could even be arranged??? More likely night get togethers. But policy is one of the items on for discussion for IPsecond at the workgroup session. BTW>>>>>> I have been in discussion with NCSA on developing a rigorous certification program for IPsec products. More on this soon..... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Wed Nov 26 09:44:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA25384 for ipsec-outgoing; Wed, 26 Nov 1997 09:44:43 -0500 (EST) X-Mailer: exmh version 1.6.6 3/24/96 To: ipsec@tis.com Subject: Info on ANX interoperability workshops X-face: /.djtld]hG%u(62*;}o.4wE~ef{DUV!fcj6cSMV|td_JjPQi/6[R?LXx.*3tD,AGS*nn.D^ 3=W.BbTm+C:mt!\ILPi&zXu~S9Dqc>`n3?-1M2*~Ssf_y/f@;_nW\\BbVhMY|Q4-9Y~?Pkn$U\fs(5 X]0v~-PyO<m5C/u%5Fz"OI@ X-url: http://www.cs.ucl.ac.uk/staff/p.oechslin Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Nov 1997 14:54:42 +0000 Message-ID: <16010.880556082@cs.ucl.ac.uk> From: Philippe OECHSLIN Sender: owner-ipsec@ex.tis.com Precedence: bulk I have seen ANX interoperability workshops mentioned in this list. Can anybody give me a pointer about the who/what/where/how often of these workshops? cheers, Philippe -- Philippe Oechslin mailto:P.Oechslin@cs.ucl.ac.uk Department of Computer Science Phone: +44 171 380 72 96 University College of London fax: +44 171 387 13 97 Gower Street, London WC1E 6BT http://www.cs.ucl.ac.uk/staff/p.oechslin From owner-ipsec Wed Nov 26 10:30:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA25638 for ipsec-outgoing; Wed, 26 Nov 1997 10:26:44 -0500 (EST) Message-Id: <3.0.3.32.19971126102602.00bac280@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 26 Nov 1997 10:26:02 -0500 To: Philippe OECHSLIN , ipsec@tis.com From: Robert Moskowitz Subject: Re: Info on ANX interoperability workshops In-Reply-To: <16010.880556082@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 02:54 PM 11/26/97 +0000, Philippe OECHSLIN wrote: > >I have seen ANX interoperability workshops mentioned in this list. Can anybody >give me a pointer about the who/what/where/how often of these workshops? There are still 2 vendors, whose test information is not correct. Give us until monday, and we should have it squared away.... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Wed Nov 26 10:41:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA25699 for ipsec-outgoing; Wed, 26 Nov 1997 10:40:49 -0500 (EST) Message-ID: From: "Boyter, Brian A." To: "'rgm3@chrysler.com'" Cc: "'ipsec@tis.com'" Subject: IPSEC Security Policy Management Date: Wed, 26 Nov 1997 09:50:38 -0600 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id KAA25696 Sender: owner-ipsec@ex.tis.com Precedence: bulk Robert... Good to hear from you.... I had an amazing response to my email.... It was overwhelming... Sadly, most of the respondents did not post their replies on the ipsec mail list... (You were an exception)... I'm not sure where this should go... I've never been to an IETF meeting... Is there an opportunity to discuss this requirement??? Should an IPSEC secpol subgroup be created??? > One idea I am playing with is to right the security policy in PolicyMaker Ø and put it in a certificate from the policy server.... Interesting idea... Is this the AT&T PolicyMaker??? >From the Air Force's standpoint, we are in favor of almost any method of creating + storing + disseminating policy - we just want all of the vendor products to use the same standard.... What about using the attribute certificate (http://lists.w3.org/Archives/Public/ietf-tls/msg02442.html) (http://lists.w3.org/Archives/Public/ietf-tls/msg00796.html)???? Isn't this the "standard" for SSL security policy???? Brian Boyter CSC (210)977-3113 From owner-ipsec Wed Nov 26 10:51:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA25752 for ipsec-outgoing; Wed, 26 Nov 1997 10:50:51 -0500 (EST) Message-ID: <347C4787.5482@fet.com> Date: Wed, 26 Nov 1997 08:00:07 -0800 From: "Scott G. Kelly" Organization: Furukawa Electric Technologies, Inc. X-Mailer: Mozilla 3.03 (Win95; U) MIME-Version: 1.0 To: ipsec@tis.com Subject: Re: draft-ietf-ipsec-arch-sec-02.txt and last call References: <199711260648.IAA22586@morden.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Michael Richardson wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > "Brian" == Brian Leu writes: > Brian> It seems to me that if imposing the canonical ordering on the SPD > Brian> entries then for every packet there is an overhead which on the average > Brian> is proportional (linearly) to the number of entries in SPD because the > Brian> search is sequential. > > Exactly. > This was my (unstated) thinking behind an objection to the explicit > SPD ordering. It is just isn't computationally efficient at times. I disagree with the argument against canonical ordering. First, a logical ordering does not necessarily reflect the physical ordering. There are a number of creative approaches to indexing selectors which are explored in database texts. A simple hashing mechanism has better than linear performance. Second, we might apply a variation of Occam's razor here: when selecting administrative mechanisms, always take the simplest path, especially in matters critical to system function (e.g. security). This (hopefully) will preclude introduction of errors resulting from poorly understood complexities of interaction. Regarding the search overhead, there simply does not seem to be any way to completely avoid it... hence, we must balance this overhead with other concerns. I think the ordering does that nicely, especially if you are clever about indexing into the db. From owner-ipsec Wed Nov 26 11:13:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA25962 for ipsec-outgoing; Wed, 26 Nov 1997 11:12:53 -0500 (EST) Message-Id: <3.0.3.32.19971126112011.00beb100@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 26 Nov 1997 11:20:11 -0500 To: "Boyter, Brian A." From: Robert Moskowitz Subject: Re: IPSEC Security Policy Management Cc: "'ipsec@tis.com'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id LAA25959 Sender: owner-ipsec@ex.tis.com Precedence: bulk At 09:50 AM 11/26/97 -0600, Boyter, Brian A. wrote: > >I've never been to an IETF meeting... Hey we all have to start sometime. Only about 30 people can claim they were there in the BEGINNING at SDSC... >Is there an opportunity to discuss this >requirement??? Should an IPSEC secpol >subgroup be created??? Ted and I are working on finishing the agenda for the IPsec session. This will be on there somehow, but lots of things happen in the hall and the terminal room. >> One idea I am playing with is to right the security policy in PolicyMaker >Ø and put it in a certificate from the policy server.... > >Interesting idea... Is this the AT&T PolicyMaker??? Yes, I am quite intrigue with it. I would send you the URL, but I am having trouble checking what I thought it was :( >From the Air Force's standpoint, we are in favor of almost >any method of creating + storing + disseminating policy - >we just want all of the vendor products to use the same >standard.... > >What about using the attribute certificate >(http://lists.w3.org/Archives/Public/ietf-tls/msg02442.html) >(http://lists.w3.org/Archives/Public/ietf-tls/msg00796.html)???? >Isn't this the "standard" for SSL security policy???? I have trouble with the direction of attribute certificates. I will be spending time at DC trying to scope this out, but I have management scaling problems in a distributed responsibility model like I need here (you might not, as the USAF is basically one command structure). Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Wed Nov 26 11:50:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA26243 for ipsec-outgoing; Wed, 26 Nov 1997 11:48:54 -0500 (EST) Message-Id: <3.0.3.32.19971126115801.00c51160@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 26 Nov 1997 11:58:01 -0500 To: "Boyter, Brian A." From: Robert Moskowitz Subject: Re: IPSEC Security Policy Management Cc: "'ipsec@tis.com'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id LAA26240 Sender: owner-ipsec@ex.tis.com Precedence: bulk At 09:50 AM 11/26/97 -0600, Boyter, Brian A. wrote: > >> One idea I am playing with is to right the security policy in PolicyMaker >Ø and put it in a certificate from the policy server.... > >Interesting idea... Is this the AT&T PolicyMaker??? The URL for it is: ftp://ftp.research.att.com/dist/mab/policymaker.ps I've been told by Bellovin that Matt has gotten the AT&T lawyers working with him on this one and the technology is now usable. I do not see the actual statement there on Matt's distribution list, just his old statement that it is in the works. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Wed Nov 26 13:35:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA26988 for ipsec-outgoing; Wed, 26 Nov 1997 13:33:10 -0500 (EST) Message-ID: <347C6D4D.9F1F9DF1@tiac.net> Date: Wed, 26 Nov 1997 13:41:17 -0500 From: Michael Giniger X-Mailer: Mozilla 4.01 [en] (Win95; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: ISAKMP gateway function X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi I've read through ISAKMPv8 and I was wondering if anyone could answer a question for me. Does ISAKMP/OAKLEY support the use of a gateway host that negotiates IPSEC SAs on behalf of other end systems. For example gateway host A negotiates an ISAKMP SA (phase 1) with host Z. Then can host A negotiate IPSEC SAs on behalf of end systems C, D, and E. Host A would then have to provide C, D, and E with the requisite keying material, etc. Is this supported by ISAKMP and if so how is this done? If not, then does this mean that any end system that wants to have an IPSEC SA with another end system must negotiate directly with that end system? Every end system would then have to store and run a copy of ISAKMP. I appreciate any information you can provide Sincerely Michael Giniger From owner-ipsec Wed Nov 26 19:25:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA28854 for ipsec-outgoing; Wed, 26 Nov 1997 19:21:58 -0500 (EST) From: Tim Bass (IETF) Message-Id: <199711270032.TAA16025@linux.silkroad.com> Subject: Re: US Air Force IPSEC Requirements To: boyter@afiwc01.af.mil (Boyter, Brian A.) Date: Wed, 26 Nov 1997 19:32:48 -0500 (EST) Cc: ipsec@tis.com In-Reply-To: from "Boyter, Brian A." at Nov 25, 97 05:03:03 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Brian, A few comments on your posting. First, There are many folks in AF doing work with IP based security products. AF IWC in Texas primary mission is to do active pentration testing and intruder monitoring and response. Overall AF policy for the use of IPSEC or any global architectural issues are developed in AF/SC, at the directorate level with guidance from AFCA (the Air Force Communications Agency), the Major Commands, (MAJOMs), etc. This is not a function, or mission, centered at AF IWC. Your post is misleading to readers not familiar with AF. Based on my (extensive) knowledge of unclassified networking in AF (i built the first network control center, NCC, for AF in 1993) it would be prudent on your part not to state you are working on behalf of USAF or have a full understanding of USAF requirements in IETF WGs or publically, unless CSC (your employer) is directly under contract to represent itself as a spokesperson (organization) for AF. I will be happy to refer you to the appropriate AF personnel that can channel your excellent questions to folks in AF that can help. However, it is prudent for you not to discuss AF requirements directly in IETF. Best Regards, Tim Bass (not representing AF nor my present employer). Brian> First, I would like to introduce myself... Brian> My name is Brian Boyter, I'm a Senior Consulting Brian> Engineer with the Computer Sciences Corp, and I Brian> am under contract to the US Air Force Information Brian> Warfare Center in San Antonio, Texas, working on Brian> USAF computer security... Brian> The USAF is evaluating the use of IPSEC products Brian> to help secure its unclassified networks... deleted ....